継続的インテグレーションのためにコード ファーストの移行を完全に自動化できるかどうか疑問に思っていました。
現在、継続的インテグレーションは単にコードの変更を更新するだけですが、移行を手動で生成し、継続的インテグレーション サーバーでデータベースを更新します。
移行を生成してデータベースを自動的に更新することは、信頼できるか、可能か、推奨されますか?
例えば：
プロパティ userId と username を持つユーザーがいます。次に、プロパティ age をコードに追加します。現在のシナリオでは、この変更をキャプチャする移行を作成してから、変更をバージョン管理にチェックインする必要があります。継続的インテグレーションはこの変更を検出し、新しいバージョンをデプロイします。データベースを手動で更新する必要があります（自動化する必要があります）。
プロパティ age をコードに追加するだけで、継続的インテグレーションによってこの移行が生成されるように、移行の生成もスキップできますか。これが推奨されるかどうかはわかりません。
答えはイエスですが、あなたが説明している方法とはまったく異なります。
移行を手動で生成する必要があります。すべての移行を自動的に作成できるわけではありません。その場合、生成された移行を手動で変更する必要があります。列の分割、特定の種類のデータ型の変更など。
その後、CI サーバーは migrate.exe を利用して、データベースをモデルと同期させることができます。注意が必要なのは、ダウングレードにつながる移行の処理です。したがって、v1 から v2 への移行は簡単ですが、v2 アセンブリのみが v1 に「戻る」方法を知っているため、v2 から v1 への移行はより複雑になります。
最終的に、移行をインテリジェントに実行し、移行に使用するモデル (コンテキスト) アセンブリを自動的に決定するカスタム ツールを作成しました。ここでそれを行う方法のアイデアを得ることができます: EF Code First Migrations to Deploy Older Version
最終結果は、モデルの変更/移行をチェックインし、自分の ci/cd パイプラインの一部であるすべての環境にデータベースの変更が自動的にデプロイされることを知ることができます - はい、それには絶対に本番環境が含まれます。
継続的インテグレーションの一部は、テストに合格しない場合に悪い変更をロールバックする可能性もあります。
これらは、実装する前に考えるべき質問の一部です。