チーム環境での移行

チーム環境で移行を操作する場合、複数の開発者が同じ時間に移行を追加すると、さまざまな問題が発生する可能性があります。移行は単なる SQL スクリプトではなく、その移行時のモデルのスナップショットも含まれる点に注意してください。

たとえば、開発者 A と B の両方が同時に作業ブランチを作成し、ブランチで移行を生成するとします。 開発者 A がブランチをマージした後、開発者 B が同じ操作を行うと、最新の移行 (開発者 B) には、開発者 A の移行からの変更を含まないコンテキスト スナップショットが作成されます。 これにより、後の移行でさまざまな形式の破損が発生する可能性があります。

その結果、事前に調整し、可能な場合は複数のブランチでの移行で同時に作業しないようにすることを強くお勧めします。

移行は順序付けられたシーケンスを形成します。 各移行のデザイナー メタデータは、シーケンス内のその時点のモデルを表し、移行が削除されるときに使用されます。 ファイルの並べ替えや名前変更によって並列移行を解決しないでください。後の移行には、他のブランチの変更を含まないメタデータが含まれます。

分岐した移行ツリーの検出

EF 11 以降、モデル スナップショットは最新の移行の ID を記録します。 つまり、2 人の開発者がそれぞれ別々のブランチに移行を作成した場合、これらのブランチをマージすると、両方のブランチが最新の移行 ID を変更するため、モデル スナップショット ファイルでソース管理の競合が発生します。 この競合は重要なシグナルです。移行ツリーが分岐したことを示し、続行する前にそのうちの 1 つを破棄する必要があります。

これを解決するには、 次の「異なる移行ツリーを解決する 」の手順に従います。マージを中止し、移行を削除し (モデルの変更を保持する)、チームメイトの変更をマージしてから、移行を再追加します。

EF Core 10 以前では、モデル スナップショットに最新の移行 ID が記録されないため、ソース管理システムは、この競合を報告せずにスナップショットをマージできます。 移行ツリーはまだ分岐しており、同じワークフローを使用して解決する必要があります。

分岐した移行ツリーの解決

ブランチを統合する際に、移行ツリーの分岐が検出された場合は、移行を再実行して解決します。 次の手順に従います。

1. マージを中止し、マージの前に作業ディレクトリに戻ります。
2. 移行を削除しますが、モデルを生成した変更は保持します。 ソース管理を使用して、生成された移行ファイルのみを削除し、移行前スナップショットを復元できます。
3. チームメイトの変更を作業ディレクトリにマージします。
4. マージされたモデル スナップショットに基づいて移行を再追加します。

これを行った後、移行は、他のブランチに追加されたすべての移行に基づいて正常に行われ、そのコンテキスト スナップショットには以前のすべての変更が含まれます。 移行をチームの残りの部分と安全に共有できるようになりました。

並列移行が既に無効なシーケンスにマージされた後は、 dotnet ef migrations remove (または Remove-Migration) を実行しないでください。 このコマンドは、前の移行のデザイナー メタデータによって表されるモデルを復元します。このメタデータには、他のブランチの変更が含まれていない可能性があります。 ソース管理を使用して一貫性のあるマージ前の状態に戻り、上記の手順に従います。

ソース管理で移行の変更を元に戻す

ソース管理のコミットを元に戻しても、データベースは変更されません。 移行コードを削除する前に、次のいずれかの方法を選択します。

• 移行が共有データベースに適用されていない場合は、移行を削除してから、モデルの変更を元に戻します。
• 移行が適用されている場合は、移行コードがまだ使用可能な状態でデータベースを以前の移行に移行するか、新しい修正移行をデプロイします。 ロールバックを通じて、アプリケーションとデータベースのデプロイに互換性を保ちます。

共有データベースにまだ記録されている移行ソースは削除しないでください。 コードが既に元に戻されている場合は、移行を含むコミットをチェックアウトまたは復元してロールバックを生成してテストし、一貫性のある移行シーケンスをコミットします。