スキーマファーストの設計では、ApexSQL Diffを使用します（RedGateの製品と非常によく似ており、おそらく少し安価です）。優れたサードパーティツールは、VSデータベースプロジェクトよりもはるかに使いやすく、スクリプトアプリケーションツールで簡単に適用できます。 RoundHousEのように。
Model Firstアプローチで使用すると、投稿で説明されているように、Model‑Schema‑Diff‑Schema‑Modelのサイクルを使用したSchemaFirstアプローチに従うことができます。合理化されたプロセスを作成するために、以下のこれらのガイドライン/注記を検討してください。スキーマ差分アプローチは、面倒な、遅い、または過度に手動である必要はありません。
データベーススキーマの現在のバージョンは、一連のデータベースパッチ（またはDDL / DMLスクリプト）を適用することによって取得されます。
ツール（RoundHousEを使用）は、必要に応じてスクリプトを自動的に適用します。どのスクリプトが適用されたかを知るための情報を記録します。同じスクリプトを適用することはべき等です。
ローカルデータベースに対して行われた差分。このローカルデータベースは、以前のすべての変更スクリプトから自動化された方法で構築できます。このlatest-localは、常に最新のモデル変更の差分ターゲットです。
リモート/ライブデータベースがdiffターゲットとして使用されることはありません。同じスクリプトを後でテスト（そしてライブ）データベースに適用できます。すべてが同じ方法で行われるため、このプロセスはすべてのデータベースで繰り返すことができます。
唯一の「問題」は、よく考えられていない更新が、新しい制限/制約の下で無効なデータにつながる可能性があることです。もちろん、これはライブデータベースにプッシュする前に、簡単に識別、修正、および再差分できました。
diffがソース管理にコミットされたら、ブランチに適用する必要があります。以前にコミットした変更スクリプトを「元に戻す」には、逆のアクションを適用して新しい差分を作成する必要があります。暗黙のダウンバージョンはありません。
統合する必要のあるスキーマロックとして効果的に機能する[Hg]モデルブランチがあります。これは弱点と見なすことができますが、小規模チームの開発ではうまく機能しています。
Huagati DBML / EDMXのようなツールを使用して、スキーマをモデルに同期し直します。これは、開発時に非常に役立ちます。この小さな宝石は本当にそれ自体の代償を払っており、サイクルの一部です。これを使用すると、「モデルに更新」したり、SSMS（またはその他）でスキーマを変更してから元に戻したりすることも簡単にできます。
コードファーストの移行は「OK」です（そして間違いなく何もしないよりはましです！）が、さまざまなsys情報を公開していないため、Azure SQL（別名SQLデータベース）が高度な差分ツールでサポートされていないため、私はそれらを使用しています。（diffは通常どおりローカルで実行できますが、ApexSQLDiffはAzureSQLと常に相性が良いとは限らないDDL/ DMLを生成します-さらに、少し異なるアプローチを学ぶチャンスです:-)
PowerPackを介したCodeFirst移行のいくつかの利点：DDL / DMLに制限される代わりにC＃で更新タスクを実行でき（便利な場合があります）、自動ダウングレード（使用には疑問があります）、サードパーティを購入する必要はありませんツール（高価になる可能性があります）、Azure SQLへの統合/展開が容易、特定のデータベースベンダーとの結びつきが少ない（理論上）など。
コードファーストの移行（およびそのような自動化）は、絶対に恐ろしいドロップアンドリクリエイトアプローチと比較して良い一歩ですが、開発時には専用のSQLツールを使用することをお勧めします。