5
開発者がデータベースの変更をフォローするための「ベストプラクティス」タイプのプロセスはありますか？
DBの変更を開発環境からQA、実稼働環境に移行する良い方法は何ですか？現在、私たちは： SQLファイルの変更をスクリプト化し、TFS作業項目に添付します。 作品は査読済みです 作業のテストの準備が整うと、QAでSQLが実行されます。 作業はQAテスト済み 作業の準備が整ったら、SQLを運用データベースで実行します。 これに関する問題は、それが非常に手作業であるということです。開発者がSQLを添付することを覚えている開発者、または開発者が忘れた場合にそれをキャッチするピアレビューアーに依存します。場合によっては、問題を発見したテスターまたはQAデプロイヤーになることがあります。 2番目の問題は、2つの別々のタスクが同じデータベースオブジェクトを変更する場合、変更を手動で調整する必要が生じる場合があることです。これは単なる方法かもしれませんが、これらの問題または何かに「フラグを立てる」自動化された方法があるべきであるように見えます。 私たちのセットアップ：開発ショップには、DBの経験が豊富な開発者がたくさんいます。私たちのプロジェクトは非常にDB指向です。私たちは主に.NETおよびMS SQLショップです。現在、作業を追跡するためにMS TFS作業項目を使用しています。これは、変更セットを作業項目にリンクし、QAおよび実稼働環境に移行するときに含める必要がある変更を正確に見つけることができるため、コードの変更に便利です。現在DBプロジェクトを使用していませんが、将来的にはそれに切り替える可能性があります（おそらくそれは答えの一部です）。 私はソース管理システムに非常に慣れており、私のためにこのようなことをやっていて、SQLにも同じことをしたいと思っています。