私のチームは、データベースの移行を管理するために dbdeploy を評価しています。私が理解しているように、移行を使用するには、少しプロセスの規律が必要です。つまり、すべての変更に対して移行を記述し、本番環境に移行するには、ローカルから開発、テスト、本番に移行する必要があります。
場合によっては、本番 DBA チームが本番環境に直接スキーマの変更を加えることがあります。データベースの現在の開発バージョンに対して変更を加えるために新しい移行を作成する場合、その移行は、移行が本番環境にデプロイされるまで、変更が既に含まれているスキーマに対してテストされることはありません。これは私に関係があります。
もう 1 つのオプションは、ベースライン スキーマを直接変更してから、すべての環境 (ローカル、開発、テスト、ステージ) でデータベースを再構築することです。新しいスキーマによって 1 つまたは複数の移行が中断される可能性があるため、このアプローチには懸念があります。
現在、人々はこのシナリオをどのように処理していますか?
運用データベースのコピーをテスト サーバーに夜間に復元します。
これは次に役立ちます：
開発/テスト データベースなどは再構築しませんが、仲間のプロジェクトのいくつかは再構築します。ただし、データベースはスキーマやコードではなく、データでもあるため、その利点についてはよくわかりません。準拠した .net アプリとは異なります。
私のショップでは、製品 DBA が承認なしに製品 DB に変更を加えると (どんな変更も) 解雇されます。そして、それは起こりました。
DBA が本番 DB で変更できる唯一のことは、あちこちにインデックスを追加し、いくつかの sproc を微調整することだと思います - すべてパフォーマンスのために。DB に対する他のすべての変更は、一般的に言えば、DB スキーマをアプリケーションと互換性がなくなる可能性があります。
これを念頭に置いて、実際にバージョン管理する必要があるのは sproc だけであり、それらをソース管理にチェックインするのは DBA の責任です。インデックスはより揮発性が高く、実際には移行スクリプトに含まれない場合があります。
本番スキーマの DB の変更が時々発生する必要があることは理解できます。ただし、これらを文書化し、できるだけ早く開発チームに連絡することが非常に重要です。影響を受けるユースケース/機能と考えられるバグ追跡の問題に関するコメントとともに実行されたSQLを含むプレーンテキストで十分です
ライブ DB を時々開発に戻し、それ (スキーマ) を開発者が持っているものと比較することも良い考えです。