2011-06-21 6 views
7

データベースを変更するたびに、これらの変更をチーム(およびサーバー)の他のデータベースにどのように適用しますか?チーム内でSQL変更をどのように共有しますか?

現在、changes.sqlという名前のファイルを使用しています。ここでは、すべての変更をISOの日付コメントで区切っています。

良い方法がありますか?

答えて

2

あなたのアプローチの拡張バージョンを使用します。

各リリースには、リリースに含まれるすべてのスクリプトが含まれているデータベースアップグレードフォルダがあります。フォルダには、実行すべきすべてのスクリプトへの擬似リンクを含む1つのインデックスファイルがあります。

現在の本番データベースのコピーを復元するために毎晩実行されるクルーズコントロールジョブがあり、インデックスファイルで定義されたスクリプトを実行することにより、現在のリリースのアップグレードスクリプトが実行されます。現在のリリースのアップグレードフォルダに何かをチェックするたびに実行されるCIジョブもあります。

スクリプトの実行を明示的に再実行する必要があります。たとえば、スクリプトを削除または作成する前に、スクリプトの存在を確認する必要があります。

+0

変更ファイルにINSERT INTOが含まれている場合は、まずその存在をチェックしますか? SELECT ...どこに?チェックする識別子がない場合はどうなりますか? – Tower

+0

私はそれが本当にあなたが挿入しているものに依存していると思います。ユニークなインデックス制約のために失敗するのですか、そうであれば、悪いデータが作成されますか?一貫性を確保したいので、私たちの挿入物は通常IF [NOT] EXISTS(SELECT 1 FROM x WHERE ...)で囲まれています。WHERE句にはいくつかのフィールドが含まれていることがあります。挿入する場合、それらが何であるかを知っている必要があります。ほとんどのエンティティは自然なキーを持っています。 –

1

http://dbmaintain.org/overview.htmlをご覧ください - データベースの更新を管理するための非常に強力なツールです。基本的には、いくつかのSQLスクリプトを正しい順序で実行することによって動作します。すでに実行されたスクリプトを記憶しています。実行されたスクリプトが変更された場合は、エラーをプロダクションモードで報告するか、データベースをクリアしてすべてのスクリプトを再度実行します(テストモードで)。あまりにも良いチュートリアルがあります。

編集:また、SQLスクリプト(リリース別)をグループ化することもできます。ここでの大きな利点は、単体テスト、テスト環境、連続的な統合、近い稼働環境および本番環境で同じテストを使用できることです。

0

私の現在の仕事ではありませんが、以前はVisual Studio 2010でdatabase projectを使用していましたが、その後SVNに公開されました。開発から品質管理、ステージング、および生産に変更をプッシュするソフトウェア自動化ではなく、SOPがありました。

私が協力してくれたチームは、DB設計と.NET開発を担当する小規模の開発者でした。

0

また、データベースでバージョンコントロールを使用することを検討する必要があります。一例はLiquibaseです。バージョン管理を使用すると、テーブル構造に対するすべての変更をコメントすることができます。したがって、changes.sqlファイルは必要ありません。

0

データベースコマンドを実行するC#クラスを作成するための移行ツール(他の代替方法もあります)を使用します。移行は、プログラムまたは統合テストの各呼び出し時、および各展開上のサーバーでローカルに実行されます。移行フレームワークは、どの移行が適用されたかを自動的に追跡します。もちろん、移行はバージョン管理リポジトリの一部です。

関連する問題