18

私は最近それを試してみました (SQL 2008 バージョン)。唯一の問題は、最初にすべてのデータを消去せずにデータベース構造を更新するほどウィザードが賢くないことです。これが、これらのプロジェクトが実際に使用されていない理由ですか?

実際、それらを使用している、または言及している人を見たことがありません。また、明示的に検索しない限り、ブログやフォーラムで見られるものは何もありません。

彼らの何が問題なのですか？

4

5 に答える 5

9

Visual Studio Database Edition の一部であるデータベース プロジェクトを使用しています。これは素晴らしいツールです。基本的に、作成スクリプトでスキーマ全体を定義し、それをソース管理にチェックインします。次に、差分スクリプトを生成するためのツールが組み込まれていますが、データは削除されません。

また、データ比較ツールも備えているため、データベース間でデータを比較し、データベースを同じにするスクリプトを生成できます。

最近の GDR リリースには、いくつかの興味深い機能が追加されています。組み込みの展開方法を使用すると、実行時にターゲットデータベースを分析して違いのみを適用する展開パッケージを生成できるように思えます。

Team Studio - Team Suite または Development エディションをお持ちの場合は、Database Edition を使用できます。

試してみてください。データベース開発における大きな進化です

于 2009-03-16T14:16:28.890 に答える
8

Glennularと同様に、スキーマとs'procのバージョン管理にこれらを使用しています。

かなり高度なバージョン管理構造がありますが（CI、開発者への自動デプロイメント、ステージングと製品化へのシングルクリックデプロイメント）。その構造にはDBプロジェクトは含まれていません。私たちはまだそれを信用していません。

更新:(宇宙空間用）

会社の機能領域（販売、マーケティングなど）ごとに個別のTFSプロジェクトがあります。各TFSプロジェクト内には、MainフォルダーとProductionフォルダーがあります。また、データベースプロジェクトを含むTFSプロジェクトと、Common Assembly /VisualStudioプロジェクトを含むTFSプロジェクトがあります。

リリース時に、メインからプロダクションに分岐します。動きが速すぎて対処できないため、ステージングブランチはありません。正誤を問わず、私たちの生産性は、週に行う本番レベルのリリースの数によって部分的に測定されます。バグ修正、新機能など。

CIはメインブランチに設定されているため、チェックインするたびにビルドサーバーがDEV環境にデプロイされます。次に、ユニットテストとWebテストが実行され、正常に完了すると、ビルド品質が自動的に「開発」に設定されます。誰かがビルド品質を「ステージング中」に変更すると、以前の「ステージング中」ビルドが「拒否」に設定され、正しいサーバーを指すように構成ファイルを更新しながら、そのビルドがステージングサーバーにプッシュされます。（これにはTFS DeployerおよびPowerShellスクリプトを使用しました）。

QAは、ステージングサーバーのテストを行います。彼らが満足したら、制作チームはビルド品質を「本番」に変更します。これにより、ビルドが本番エリアに送信され、本番エリアが手動で正しい場所にコピーされます。完了すると、本番環境は開発者に通知し、開発者はそのバージョンを本番環境フォルダーに分岐します。QAにも通知され、すべてが実際に期待どおりに機能していることを確認するために、一連の本番テストを実行します。

展開されているすべてのチェックインを把握できるように、本番リリース間にどのような変更が存在するかを示すレポートが設定されています。これにより、データベースの変更など、その他の潜在的に破損するコードなど、不明なものがポップアップするのを防ぎます。

さらに、私たちのBAは、Team System Web Accessを介して作業項目を追跡しており、それらの項目がいつ生産されているかを知っています。

DBAはDatabaseEdition（GDR）を使用していますが、自動展開の制御レベルには感心していません。Rosarioが製品ラインにより良い展開制御をもたらすことを望んでいます。それまでは、TFSDeployerとPowerShellがあります。

于 2009-03-16T14:40:09.397 に答える
1

データベースプロジェクトを使用して、SQLスクリプトのバージョン管理を提供します。VisualStudio環境を使用してSQLを編集することも好きです。一部の新しい開発者にとっては、クエリアナライザよりも少し使いやすいです。

于 2009-03-16T14:41:47.830 に答える
1

私はいくつかの有料プロジェクトでそれらを使用しましたが、素晴らしいツールだと思います。そうは言っても、私はいくつかの問題を見てきました。

  1. db プロジェクト フォルダー内の .dat ファイルがデータベースの一時インスタンスと同期しなくなると、スキーマ比較の結果が不正確になります。これがどのように発生するかわからない場合は、スキーマを注意深く比較して確認し、問題が疑わしい場合は (ソリューションを閉じた後に) .dat ファイルを吹き飛ばしてください。

  2. 20以上のデータベースがあり、それらが相互に参照し、循環参照を使用している場合...それは痛いでしょう。そのシナリオに合わせて拡張する方法がわかりません。GDR 2 は、いくつかの約束を提供するようです。

于 2009-05-27T20:31:33.327 に答える