トレーニング
モジュール
Microsoft Power Platform のためのチーム開発の導入 - Training
Microsoft Power Platform のチーム開発プロセスについて説明します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
注意
この記事は、読者が基本的なシナリオでの Code First Migrations の使用方法を理解していると想定しています。 それ以外の方は、先に「Code First Migrations」をお読みください。
チーム環境における問題は、主として、2 人の開発者がローカル コード ベース内に移行を生成した場合に、複数の移行をマージすることに関連しています。 これらを解決する手順はかなり単純ですが、移行のしくみについて十分に理解している必要があります。 最後までスキップすることなく、時間をかけて記事全体を読み、確実に成功するようにしてください。
複数の開発者によって生成された移行のマージを管理する方法について詳しく説明する前に、成功を収めるための準備となる一般的なガイドラインをいくつか紹介します。
移行では、__MigrationsHistory テーブルを使用して、データベースに適用された移行の内容が格納されます。 複数の開発者が、同じデータベースをターゲットにしている (したがって __MigrationsHistory テーブルを共有している) ときに異なる移行を生成している場合、移行は非常に混乱したものになります。
もちろん、移行を生成していないチーム メンバーがいる場合、彼らに中央の開発データベースを共有させても問題はありません。
肝心なことは、チーム環境において自動移行は、当初は良好に見えますが、実際にはうまくいかないという点です。 その理由を知りたければ、読み進めてください。そうでなければ、次のセクションに進むことができます。
自動移行を使用すると、コード ファイルを生成する (コードベースの移行) ことなく、現在のモデルと一致するようにデータベース スキーマを更新できます。 チーム環境において自動移行がまったく適切に機能するのは、使用したことがあるのは自動移行だけで、コードベースの移行をまったく生成したことがない場合のみです。 問題は、自動移行は限定的であり、プロパティや列の名前変更、別のテーブルへのデータの移動など、いくつかの操作は処理されないことです。これらのシナリオを処理するために、自動移行によって処理される、複数の変更の間に混じり合ったコードベースの移行 (とスキャフォールディング コードの編集) が生成される結果に終わります。 これにより、2 人の開発者が移行をチェックインするときに、変更をマージすることがほとんど不可能になります。
チーム環境で正しく移行を使用するための鍵は、モデルの変更を検出するために、モデルに関する情報が移行によってどのように追跡され、使用されるかを基礎から理解することです。
プロジェクトに最初の移行を追加するときには、パッケージ マネージャー コンソールで、Add-Migration First のような何かを実行します。 このコマンドによって実行されるステップの概要を、下の図に示します。
現在のモデルは、お使いのコードから計算されます (1)。 次に model differ によって、必要なデータベース オブジェクトが計算されます (2)。これが最初の移行であるため、モデル差分計算ツールでは、比較のために単に空のモデルが使用されます。 必要な変更がコード ジェネレーターに渡されて、移行コードが作成されます (3)。それが次に、お使いの Visual Studio ソリューションに追加されます (4)。
メイン コード ファイルに格納されている実際の移行コードに加えて、移行によって追加の分離コード ファイルもいくつか生成されます。 これらのファイルは、移行によって使用されるメタデータであり、開発者が編集する必要があるものではありません。 これらのファイルの 1 つは、移行が生成された時点のモデルのスナップショットが含まれるリソース ファイル (.resx) です。 これがどのように使用されるかについては、次のステップで確認します。
この時点で、開発者はおそらく、データベースに変更を適用するために Update-Database を実行し、その後、アプリケーションの他の領域の実装に取り掛かります。
後になって、開発者はモデルに何らかの変更を加えます。この例では、Blog に Url プロパティを追加します。 次に、対応するデータベースの変更を適用するために、Add-Migration AddUrl などのコマンドを発行して移行をスキャフォールディングします。 このコマンドによって実行されるステップの概要を、下の図に示します。
前回と同じように、現在のモデルはコードから計算されます (1)。 ただし今回は、既存の移行が存在しているため、最新の移行から以前のモデルが取得されます (2)。 これら 2 つのモデルは、必要なデータベース変更を見つけるために差分が計算され (3)、その後、前のようにプロセスが完了します。
プロジェクトにさらに移行が追加される場合は、この同じプロセスが使用されます。
なぜ EF にモデルのスナップショットが関わっているか、不思議に思うかも知れません。データベースを調べるだけではいけないのでしょうか。 そう思う場合は、読み進めてください。 関心がなければ、このセクションをスキップできます。
EF でスナップショットのモデルが保持される理由はいくつかあります。
前のセクションで説明したワークフローが適切に機能するのは、1 人の開発者がアプリケーションに対する作業を行っている場合です。 あなたが、モデルに変更を加える唯一の開発者であるチーム環境でも、それは適切に機能します。 このシナリオでは、あなたはモデルの変更を行い、移行を生成して、それらをソース管理に送信できます。 他の開発者は、変更を同期し、Update-Database を実行してスキーマの変更が適用されるようにできます。
同時に EF モデルに変更を加えてソース管理への送信を行う開発者が複数いると、問題が起き始めます。 EF に用意されていないのは、ある開発者によるローカルの移行を、最後の同期以後に別の開発者がソース管理に送信した移行とマージするための優れた方法です。
まず、このようなマージ競合の具体的な例を見てみましょう。 前に確認した例を使用して説明を続けます。 開始点として、前のセクションで取り上げた変更が、元の開発者によってチェックインされたとします。 コード ベースに変更を加える 2 人の開発者を追跡してゆきます。
いくつかの変更を通じて、EF モデルと移行を追跡します。 開始点については、次の図に示すように、両方の開発者がソース管理リポジトリに同期しています。
ここで開発者 1 と開発者 2 が、自分のローカル コード ベースの EF モデルにいくつかの変更を加えています。 開発者 1 は、Blog に Rating プロパティを追加して、変更をデータベースに適用するための AddRating 移行を生成しています。 開発者 2 は、Blog に Readers プロパティを追加して、対応する AddReaders 移行を生成しています。 どちらの開発者も Update-Database を実行し、変更を自分のローカル データベースに適用した後、アプリケーションの開発を続けています。
注意
移行にはタイムスタンプでプレフィックスが付けられるため、この図は、開発者 2 からの AddReaders 移行は、開発者 1 からの AddRating 移行の後に行われたことを示しています。 最初に移行を生成したのが開発者 1 であるか 2 であるかは、チームでの作業に関する問題や、次のセクションで説明する移行マージ用のプロセスに関する問題に違いを生じさせません。
開発者 1 にとっては、たまたま最初に変更を送信したので運がいい日です。 リポジトリを同期して以来、他のどの開発者もチェックインしていないため、マージを実行せずに自分の変更を送信するだけで済みます。
ここで、開発者 2 が送信する順番です。 彼はそれほど幸運ではありません。 同期以降に他の開発者が変更を送信したため、変更をプルしてマージする必要があります。 ソース管理システムではおそらく、コード レベルでの変更は非常に単純であるため、それらを自動的にマージできます。 次の図に、同期後の開発者 2 のローカル リポジトリの状態を示します。
この段階で、開発者 2 は Update-Database を実行できます。これにより、新しい AddRating 移行 (開発者 2 のデータベースには適用されていない) が検出され、それが適用されます。 これで Blogs テーブルに Rating 列が追加され、データベースがモデルと同期した状態になります。
しかし、いくつか問題があります。
移行のしくみを理解しているならば、マージを手動で処理することはそれほど困難ではないというのが良いニュースです。 では、このセクションまで前方をスキップした場合は、 残念ですが、前に戻り、まず記事の残りの部分を読む必要があります。
2 つのオプションがあります。より簡単なのは、正しい現在のモデルを持つ空の移行を、スナップショットとして生成することです。 2 つ目のオプションは、正しいモデルのスナップショットを用意するため、最後の移行に含まれるスナップショットを更新することです。 2 つ目のオプションは少し難しく、どのシナリオでも使用できるわけではありませんが、別の移行を追加する必要はないため、よりすっきりとしています。
このオプションでは、最新の移行に、正しいモデルのスナップショットが格納されるようにすることだけを目的に、空の移行を生成します。
このオプションは、最後の移行をどの開発者が生成したかに関係なく使用できます。 見てきた例では、開発者 2 が、マージの管理を行っていて、たまたま最後の移行を生成しました。 ただし、開発者 1 が最後の移行を生成した場合に、これらの同じ手順を使用できます。 ここでは簡潔さを保つため 2 つの移行で確認してきましたが、この手順は、多数の移行が関係している場合にも適用されます。
ソース管理から同期する必要がある変更が存在すると気付いた時点から、このアプローチのために以下のプロセスを利用できます。
次に、このアプローチを使用した後の、開発者 2 のローカル コード ベースの状態を示します。
このオプションはオプション 1 とよく似ていますが、追加の空の移行がなくなります。現実を直視しましょう。ソリューションにコード ファイルを追加したい開発者はいないのです。
このアプローチを実行できるのは、最新の移行がローカル コード ベースにのみ存在していて、ソース管理にはまだ送信されていない場合 (たとえば、マージを行うユーザーによって最後の移行が生成された場合) だけです。 他の開発者が既に、開発データベースに適用した可能性がある移行や、さらに悪いことに、実稼働データベースに適用した可能性がある移行のメタデータを編集すると、予期しない副作用が発生する場合があります。 このプロセス中には、ローカル データベースで最後の移行をロールバックして、更新されたメタデータをそれに再適用することになります。
最後の移行が存在する必要があるのはローカル コード ベース内だけですが、それを進める移行の数や順序に制限はありません。 ここでは簡潔さを保つため 2 つの移行で確認してきましたが、複数の異なる開発者からの移行が複数存在する場合があり、同じ手順が当てはまります。
ソース管理から同期する必要がある変更が存在すると気付いた時点から、このアプローチのために以下のプロセスを利用できます。
次に、このアプローチを使用した後の、開発者 2 のローカル コード ベースの状態を示します。
チーム環境で Code First Migrations を使用する際にはいくつかの課題があります。 ただしこれらの課題は、移行のしくみに関する基本的な理解と、マージ競合を解決するためのいくつかの簡単なアプローチによって簡単に克服できます。
根本的な問題は、最新の移行に正しくないメタデータが格納されていることです。 これにより、Code First では、現在のモデルとデータベース スキーマが一致しないと誤って検出され、次の移行で正しくないコードがスキャフォールディングされます。 この状況は、正しいモデルを含む空の移行を生成するか、最新の移行の中のメタデータを更新することによって克服できます。
.NET に関するフィードバック
.NET はオープンソース プロジェクトです。 フィードバックを提供するにはリンクを選択します。
トレーニング
モジュール
Microsoft Power Platform のためのチーム開発の導入 - Training
Microsoft Power Platform のチーム開発プロセスについて説明します。