EF移行で運用データベースを更新しても大丈夫ですか？
このブログ投稿 によると、EF Migrationsを使用しているほとんどの企業は、EF Migrationsで本番データベースのデータベーススキーマを更新していないと思われます。代わりに、ブログ投稿の著者は、展開プロセスの一部としてスキーマ更新スクリプトを使用することを推奨しています。
スキーマ更新スクリプトを数年間使用してきましたが、それらが機能している間、次の理由で将来EF移行を使用することを計画していました。
- 迅速な展開、ダウンタイムの削減
- より簡単な展開手順
- T-SQLを使用した場合よりもはるかに簡単に既存のデータを移行できます
- 適用されるのを待っている変更のよりわかりやすい構文（従来の環境でのクリーンなC＃構文を使用したDbMigrationクラスと不格好なT-SQL移行スクリプト）。
- 新しいソフトウェアバージョンの展開が失敗した場合、古いdbスキーマへの簡単で高速なダウングレードパスがあります。
EFを使用して運用DBを移行することを禁止すると考えられる理由の1つは、DBスキーマが開発者ではなくDBAによってのみ変更された場合です。ただし、私はDBAと開発者の両方であるため、私の場合はこれは重要ではありません。
それでは、EFを使用して本番データベースを更新するリスクは何ですか？
編集：solomon8718がすでに提案したように、私は常に本番データベースの新しいコピーをステージングサーバーにプルし、本番サーバーに適用する前にステージングサーバーに適用されるEF移行をテストします。 IMOこれは、EF移行を使用しているかどうかに関係なく、運用システムのスキーマ更新に不可欠です。
まあ、とにかく答えてみます。いいえ、実稼働環境でCode First Migrationsを使用しない理由はありません。結局のところ、この使いやすいシステムのすべてを理解できない場合のポイントは何ですか？
私がそれで見た最大の問題は、あなたがすでに指摘したように、あなたがどんなシステムでも持つことができるすべての問題です。チーム全体（該当する場合はDBAを含む）が参加している限り、移行を通じてEFがスキーマを管理できるようにすることはそれほど複雑ではないため、従来のスクリプトベースの管理よりもエラーが発生しにくいと思います。実稼働システムで移行を実行する前にバックアップを作成しますが、それでもあなたはそれを行います。
DBAがVisual Studioからの移行を実行できないということは何もありません。データベースレベルの特権でアクセスをロックダウンすることができ、実際の操作を実行する前に（必要に応じて_-Script_を使用して有用なSQLエクスポート形式で）移行を確認できます。その後、それらはまだ制御されていますが、コードファーストの移行を使用できます。地獄、彼らはそれを好きになるかもしれません！
更新：SPROCとTVFが作成されたので、移行でも同様に処理しますが、実際にはDbMigration.Sql()でUp()呼び出しを使用してストレートSQLステートメントで実行されます。 Down()のそれらの逆（単純なSPROCにCreateStoredProcedureとDropStoredProcedureを使用することもできますが、SQLで本体自体を定義する必要があると思います）。それは警告だと言えると思います。包括的なデータベース全体を純粋にC＃で記述する方法はまだありません。ただし、canスキーマ全体を管理するSQLスクリプトを含む移行を使用します。このプロセスから得られた利点の1つは、単純な_String.Format_を使用したスキーマオブジェクト名（たとえば、本番と開発用の異なるサーバー名）にC＃構成ファイルを使用し、構成ファイル自体のXML変換を組み合わせて使用できることです。
はい、正当な理由がありますnot Code First Migrationsなどの自動化されたシステムを使用して、productionデータベースを変更します。しかし、いつものように、ルールには例外があります。
言及されている理由の1つは、アクセス許可です。これは、組織の変更管理規則とセキュリティポリシーに直接関連しています。
もう1つの理由は、移行ツール自体に対する信頼レベルです。ツールにバグがないことを確認していますか？ツールが途中で失敗するとどうなりますか？最新のバックアップと、必要に応じてロールバックするプロセスがあると確信していますか？
変更スクリプトは、予期しないまたは非効率的なスクリプトを実行する場合があります。生成されたSQLが一時テーブルにデータをコピーし、元のテーブルを削除し、誤って（または意図的に）列の表示順序を変更した場合に新しい列を追加するなどのために元の表を再作成した場合、または、テーブルの名前を変更したとき。何百万ものレコードが関係している場合、これは深刻なパフォーマンス問題を引き起こす可能性があります。
私の推薦：
実稼働スキーマをミラーリングするステージングデータベースがある場合、移行ツールを使用して、そのシステムに対して変更スクリプトを生成します。通常、実行前にステージデータベースを新しい運用コピーから復元します。次に、変更スクリプトを手動で調べて問題を確認します。その後、ステージデータベースに対してスクリプトを実行して、適切に実行され、予想されるすべての変更が行われたことを確認します。これで、スクリプトが本番環境で実行しても安全であり、予想される変更を実行できることが確実になりました。このプロセスは、上記の3つの問題すべてに対処します。
私が見つけたもう1つの警告：同じデータコンテキストを使用する複数のWebサイトがある場合、それらすべてが同時に更新されることを確認する必要があります。そうしないと、Webサイト間で絶えずデータベースが更新/ダウングレードされる可能性があります。それ以外は、私にとってはうまくいきました。
編集：本番環境でEF Migrationsを使用し始めてから1年後の私自身の視点：
EF Migrationsは、実稼働で使用する場合でも、実際にはかなりクールです。ただし、
- ステージングシステムで移行をテストします。統合テストを実行する前に、CIサーバー上でずっと上下に移行して、すべての移行をテストします。
- 移行を自動的にトリガーするのではなく、管理者が起動するバッチファイルを使用します。これは、SSMSで移行のためにSQLを手動で実行するのと本質的に同じです。
私はいくつかのプロジェクトの本番環境で使用しています。一度コツをつかめば大丈夫だと思う。
開発中は自動移行をオンにできますが、最後にパッケージマネージャーコンソールからライブデータベースに直接接続して移行を生成できます。すべての変更に対して1回の移行が行われます。
ただし、常に-scriptでupdate-databaseオプションを常に使用し、SQLを自分で起動してください。
また、web deployのupdate dbオプションを使用しないことをお勧めします。この方法では、エラー時に既にどのくらいの移行が実行されたかを知る方法はありません。私はそれで数回問題に遭遇しました。したがって、SQLを取得して手動で起動するのが最善です。