2

SSDT のドキュメントでは、この主題の直接的な扱いを見つけることができないようです。基本的に、生のSQLファイルをソース管理のフォルダーにチェックインすることで歴史的に管理されてきたデータベースがあり、SSDTを採用しようとしています。本番データベース、QA データベース、および共有開発データベースがあります。

最初のステップは、「Create new project」ワークフローを使用し、プロジェクトがビルドされるように古い/古いオブジェクトをクリーンアップし、次にスキーマ比較を使用して変更を dev/qa にプッシュし、最終的に本番環境にプッシュすることであると思われました。 DB。

ただし、DAC フレームワークに関する他のドキュメントを読むと、これは「データ層アプリケーションの登録」ワークフローを通じて行われるべきであるように見えますが、これが正しいかどうか、正しい場合はそれをどのようにプロセスに組み込むかは不明です。

このプロセスは非常に単純に思えるので、今までに多くの人が実行したはずです。MSDN ドキュメントなどのページを見逃したのでしょうか。どんな助けでも感謝します。

4

2 に答える 2

1

通常は、データベース プロジェクトをターゲットに公開するだけです。データ層アプリケーションとして登録することを選択できますが、誰かが途中でプロジェクト以外の変更を行った場合に問題が発生します。

私たちのプロセス: 1. 既存のデータベースからプロジェクトを作成します (開始点) 2. プロジェクトをクリーンアップします 3. プロジェクトをビルドします 4. すべてがクリーンになるまで、ステップ 2 と 3 を繰り返します。:) 5. 対象とする環境ごとに「公開プロファイル」を作成します。6. スクリプトを生成するか、データベースを更新することにより、データベースを公開します。

私のブログには、私たちが使用するプロセスの概要をまとめた一連の記事があり、役立つ可能性があります。ここで見つけることができます: http://schottsql.blogspot.com/search/label/SSDT

間違いなくスキーマ比較ルートを使用できますが、データの変更を処理するためのデプロイ前およびデプロイ後のスクリプトの機能を利用できなくなります。

于 2013-08-05T19:08:15.190 に答える