database - TFS を使用したデータベースの変更管理と構築プロセス

Question

データベースの管理に Team Foundation Server を使用している人はいますか? 現在、サブバージョンを使用しています。チームは、TFS でビルド プロセスを作成するのは難しいと不満を漏らしており、それを敬遠しています。

良い指針、記事、経験はありますか?

Answer 1

DB の変更管理は、そもそもバージョン管理システムを持っている限り、バージョン管理システムの選択とはあまり関係ありません。もちろん、MS の変更管理ツールを使用している場合は、それらが TFS およびその他の MS 開発者スタックに対して十分にテストされていることを確信できます。これは、DBPro を使用する場合でも、従来の VS の「データベース プロジェクト」や SQL Management Studio の簡素化されたプロジェクト/ソリューション バインディングで見られる、はるかに古い/安っぽい統合形式を使用する場合でも当てはまります。しかし、Subversion で DBPro を使用したり、TFS で Red Gate を使用したりできない理由はありません。

ビルド生成についても同様です。CC.NET 対 Team Build、NAnt 対 MSBuild など...公式の MS ツールは、競合他社とほぼ同等である傾向があります。DB 展開プロセスについて詳しく説明していませんが、MSBuild でスクリプトを作成するのが、現在使用しているものよりもはるかに難しいとは思いません。スタックのさまざまなポイントでさまざまなツールセットを選択することも難しくありません。Red Gate のコマンド ライン デプロイを使用する CC.NET 駆動の MSBuild ベースのビルド、またはその他の組み合わせを使用できます。MS の世界に固執することによって提供される緊密な統合は、どのツールの癖よりもはるかに優れていると思いますが、選択の余地はあります。

要点を説明しましょう。あなたの主な問題は技術的なものではなく、そもそも DBA に実際にバージョン管理を採用させることだと思われます。「開発」環境と「製品」環境が、繰り返し可能なビルド プロセスの結果によって排他的に定義された汎用マシンではなく、独自の生命体である場合、私の本では実際にはバージョン管理を使用していません。クライアント開発者が社内のさまざまなマシンの DLL をときどき手作業で微調整し、同期が難しすぎると不満を漏らしたと想像してみてください。あなたは彼が狂っていたと思うでしょう。

それを超えて、最も重要な投資は、DB に対して直接何も行われない場所に到達することです (%programfiles% をいじる以上)。ソース リポジトリにない場合は、存在しません。

どうやってそこにたどり着くかはそれほど重要ではないと思います。すべての CREATE と ALTER をメモ帳に書き込んで、コマンド ラインからチェックインし、「ビルド プロセス」を 2 行のシェル スクリプトにして、デプロイ スクリプトが認識している既知のファイルに連結することができます。 . または、DBPro のような凝ったツールを使用して、インテリセンス / ユニット テスト / オフライン モデリングなどで生産性を高めることもできます。後者の方向に向かう大きな理由があります (特に、宣言型プログラミングが一般的に努力すべきものであると信じている場合)。しかし、私は最初のステップが最大であると本当に信じています。

Answer 2

データベース エディションでは TFS を使用します。

データベース作成スクリプトには、Dev データを DB にロードするポスト スクリプトがあります。

DEV 環境への定期的なデプロイを行います。すべての開発者は SQL をローカルにインストールしており、独自の Get Latest と Deploy を行っています。

単体テスト環境では、ログイン、データベース (OLTP および OLAP)、レプリケーション、ETL パッケージ、SQL ジョブなどはすべて個別の場所にデプロイされ、すべてがシードされます。

開発者は、単体テストへの展開が機能しないため、外部で変更を加えたりチェックインしたりしません。

Answer 3

TFS と共に Visual Studio 2008 Team Suite を使用しています。比較的簡単にデータベースを TFS にインポートできました。しかし、ほとんどのチーム (DBA を含む) が、SQL のオブジェクトを変更するときに TFS を更新するのを忘れていることがわかりました。

あらゆる種類のビルド プロセスは、DB Pro に依存して、開発環境とターゲット環境の間で異なるスクリプトを生成します。私たちの開発環境は本番環境と完全に一致していないため、これには問題があることがわかりました。パーミッションは確かに異なり、変更が開発/QA で適用されたが、本番環境に移行されなかった (ただし、元に戻されなかった) というケースが他にも多数あります。DB Pro の他の多くの変更から自分の変更を分離しようとするのは、UI によって最終的なスクリプトからオブジェクトが除外されるため、困難です (したがって、2 つのオブジェクトを変更し、他の 1000 個のオブジェクトが異なる場合は、他の 1000 個のオブジェクトのチェックを外す必要があります)。また、スキーマ比較の設定は、ツール -> で行うことが多いです。

このツールには可能性があると思いますが、TFS で動作するように既存の手順とシステムを適応させる必要があることは確かです。さらに、100% 最新でなくても、データベース オブジェクトをバージョン管理することは非常に重要です。

Answer 4

このスタック オーバーフローの質問には、これに関するより多くの意見があり ます。 Visual Studio Team System Database Edition (GDR) の本当の利点は何ですか? （理由はわかりませんが、検索の結果、代わりにこの質問にたどり着きました。これについて意見を見つけるのに苦労しました。このリンクが他の人が同じ検索を実行するのに役立つことを願っています。）