継続的統合によるRedgate SQLソース管理の設定方法

Question

私の質問は次のとおりです。 開発チームのSQL変更管理に最適な設定は何ですか？

私たちのチームは4人の開発者で構成され、それぞれに独自のデータベースのコピーがあります。 SQL /アプリケーションをTFSサーバーに変更する際に、ビルドエラーが他の開発者に伝播しないようにしたいと考えています。したがって、我々はこれを支援するために継続的な統合を実装しようとしています。

考えてみましょう 1.SQLとアプリケーションコードの変更はTFSに委ねられています。 2.セントラルデータベースがSQLアップデートを取得し、アプリケーションをビルドします。 3.単体テストはビルドサーバー上で実行されます。 4.これらの手順のいずれかが失敗すると、チェックインは拒否され、データベースはコミット前の状態にロールバックされます。

これを実装するためにRedgate SQLソースコードを設定する最良の方法は何ですか？

Answer 1

Database Projectを使用できます。データベーススキーマ全体とストアドプロシージャを含めることができます。ビルド中に、ストアドプロシージャがスキーマと一致することを確認します。

ゲーテッドチェックインオプションをビルド定義で有効にすると、サブミットされた変更がマージされ、正常にビルドされた場合にのみチェックインが許可されます。

データベースに書き込まれるデータは、テスト方法に基づいています。テストが失敗した場合にデータを削除する方法を設定したり、実際のデータベースに書き込むべきではありません。代わりに、データベースクラスをモックする必要があります。この方法では、実際にはデータベースに接続して変更する必要がないため、クリーンアップは不要です。

あなたが記事の下に参照することができます詳細については

：あなたはSQLソースコントロールを使用する場合、これはあなたの要件に基づいて、

• How To Unit Test – Interacting with the Database
• Database cleanup after Junit tests

Answer 2

可能な設定を検討する。各現像機用

：

• は、開発モデルとして専用データベースを用いSQL Source Control
• Link each developer database to your TFS repositoryをインストールします。
• SQL Serverのビルドサーバー上で

のためのユニットテストを書くため

より簡単に設定SQL TestをあなたのSQLを記述することSQL Promptをインストールします。

• はRedgate DLM Automationをインストールします（単純化するAdd-Onsがありますセットアップ）
• Validate build taskを構成してスキーマを検証するデータベースを確認することは、最初から正常にビルドすることが可能で
• 設定SQLを実行するためのTest build taskは、アプリケーションユニットを実行します
• SQLの更新を使用して中央のデータベースを更新するために
• 設定Sync build taskをテストし、テストが失敗した場合
• をテスト最後のチェックインを元に戻すカスタムスクリプトを実行し、同期ビルドタスクを再度使用してデータベースの変更をロールバックし、新しいビルドを開始することができます。あなたはRedgate DLM Automation PowerShell cmdletsを使ってそれを行うことができます。

最後のステップはトリッキーです。私は、単一の中央データベースに頼るのではなく、ブランチを使用することを正直に好んでお勧めします。このようにして、各開発者は完全に独立して作業することができ、作業が各ブランチで検証されている場合にのみ、マスターブランチの新しい変更をマージすることができます。

さらに展開したい場合は、Redgate DLM Automation Deploymentを使用してリリースデータベースパッケージを作成し、データベースの変更をビルドサーバーから直接プロダクションに、またはOctopus Deployなどのリリースツールを使用して展開できます。

最後に、マイグレーション先のデータベース変更のアプローチを検討している場合は特にRedgate ReadyRollをご覧ください。

ご覧のとおり、Redgateツールを使用してデータベースの変更を管理するさまざまな方法があります。それらを設定する最良の方法はありません。常に解決する必要のある特定の要件と問題によって異なります。

これが役に立ちます。