2009-08-24 6 views

答えて

6

DB変更管理は、最初にバージョン管理システムを持っている限り、バージョン管理システムの選択にあまり関係しません。もちろん、MSからの変更管理ツールを使用している場合は、TFSやその他のMS開発者スタックとのテストが非常にうまくいっていることが分かります。これは、古典的なVS「データベースプロジェクト」やSQL Management Studioのプロジェクト/ソリューションバインドを取り除いたDBProや古くてクレイパーな統合を使用しても当てはまります。しかし、SubversionでDBProを使うことはできませんし、TFSでRed Gateを使うこともできません。

同じビルド生成になります。 CC.NET対チームビルド、NAnt対MSビルドなど...公式のMSツールは、大まかに競争相手と同じ傾向があります。あなたはあなたのDBの展開プロセスを詳細には記述していませんが、MSBuildでスクリプトを作成するのは、あなたが今使っているものよりもずっと難しいかもしれません。また、スタック内のさまざまな場所で異なるツールセットを選択することも難しくありません.Red Gateのコマンドラインデプロイメントやその他の組み合わせを使用するCC.NETドライブMSBuildベースのビルドを使用できます。私は、MSの世界にこだわることによって提供される緊密な統合が、いずれかのツールのクォークをはるかに上回っていると考えるようになりましたが、そこには選択肢があります。

私の主な問題は技術的なものではないようですが、実際にDBAにバージョン管理を実際に採用させるように聞こえます。あなたの "dev"環境と "prod"環境が、再現可能なビルドプロセスの結果によってと排他的に定義された汎用マシンではなく、独自の実体である場合、私の本ではバージョンコントロールを実際に使用していません。クライアントの開発者が会社周辺のさまざまなマシンでDLLを手作業で微調整して、時には同期が難しいと訴えた場合を想像してください。彼は狂ったと思うだろう。

これ以外にも、最も重要な投資は、DBに直接何も行われていない場所(%programfiles%で掘り下げたもの以上)に到達することです。ソースリポジトリになければ、存在しません。

私はあなたがそこにいかに得ることが重要であるとは思わない。すべてのCREATEとALTERをメモ帳に書き込んで、コマンドラインからチェックインし、 "ビルドプロセス"を2行のシェルスクリプトにして、展開スクリプトが見ていることがわかっている有名なファイルに連結することができます。または、DBProのような派手なツールを使用して、インテリセンス/ユニットテスト/オフラインモデリングなどの生産性を向上させることができます。後者の方向に向ける大きな理由があります(特にdeclarative programmingが一般的に努力するものだと思う)私は本当に最初のステップが最大だと信じています。

1

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

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

私は、このツールには潜在的な可能性があると思いますが、私たちは確かに既存の手順とシステムをTFSと連携させる必要があります。さらに、データベースオブジェクトをバージョン管理することは、100%最新ではない場合でも、非常に重要です。

+0

DB開発者がチェックインすることを確認したら、差分などを行う必要はありませんか? –

+0

おそらく、あなたはソース管理のデータベースのバージョン間で違いがあるかもしれません。したがって、すべての環境が一致し、すべての変更が適切にチェックインされている場合は、本番環境にあるソース管理のバージョンと、リリースするバージョンの違いを適用するためのスクリプトを生成することができます。 – Mayo

1

TFSはデータベース版で使用します。

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

私たちはDEV環境に定期的にデプロイします。すべての開発者はSQLをローカルにインストールしており、最新のものを入手して展開します。

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

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

0

あり、このスタックオーバーフローの問題になっているこの上のはるか意見です。 What are the real benefits of Visual Studio Team System Database Edition (GDR)? (私はなぜ知らないが、私の検索ではなく、この質問に私をもたらした、と私はこの意見を見つける多くのトラブルがありましたこのリンクは、他の人が同じ検索を実行するのに役立ちます。

関連する問題