次の方法で共有

ソリューション ファイルを使用したソース コントロール

  • [アーティクル]

SolutionPackager ツールは、ソース コントロール システムで使用できます。 ソリューション .zip ファイルがフォルダーに解凍された後、ファイルをソース 管理 システムに追加して送信します。 これらのファイルは他のコンピューター上で同期し、新しい一意のソリューション .zip ファイルにまとめることができます。

ソース コントロール内の抽出したコンポーネント ファイルを使用するときの重要な点は、すべてのファイルをソース コントロールに追加すると不要な重複が生じる可能性があることです。 ソリューション コンポーネント ファイル リファレンス を参照して、どのファイルが各コンポーネント用に生成され、どのファイルがソース コントロールの使用に推奨されているか確認してください。

ソリューションのためにさらにカスタマイズと変更が必要な場合、開発者は、既存の手法を使用してコンポーネントを編集またはカスタマイズし、再度エクスポートして .zip ファイルを作成し、圧縮されたソリューションを同じフォルダーに解凍します。

重要

カスタマイズ ファイルを編集するときに記載されているセクションを除いて、抽出されたコンポーネント ファイルと .zip ファイルの手動編集はサポートされていません。

SolutionPackager ツールがコンポーネント ファイルを解凍するとき、ファイルの内容が一致する場合は同じ名前の既存のコンポーネント ファイルが上書きされることはありません。 また、ツールはコンポーネント ファイルの読み取り専用属性に従い、書き込みしなかった特定のファイルについてコンソール ウィンドウ上に警告を示します。 これにより、ユーザーはソース コントロールから、変更する最小のファイル セットを確認できます。 /clobber パラメーターは上書きに使用でき、読み取り専用ファイルの書き込みまたは削除が生じます。 /allowWrite パラメーターを使用すると、実際にファイルの書き込みまたは削除をせずに、解凍操作により生じる影響を評価できます。 /allowWrite パラメーターは詳細なロギングと共に使用すると効果的です。

ソース コントロールから最小ファイル セット確認されて解凍操作が終了した後、開発者は変更済みファイルを、他の種類のソース ファイルでするような仕方で、ソース コントロールに戻す場合があります。

チーム開発

同じソリューション コンポーネントで複数の開発者が作業するとき、2 つの開発者が 1 つのファイルを変更する場合に競合が発生する場合があります。 個々のコンポーネントまたはサブコンポーネントを異なるファイルに分解することで、この発生を最小限にできます。 以下の例を考慮してください。

  1. 開発者 A、B 両方が同じソリューションで作業します。

  2. 独立したコンピューターで、両者ともにソース コントロールからソリューションの最新ソースを取得し、圧縮し、アンマネージド ソリューションの .zip ファイルを別々の Microsoft Dataverse 組織にインポートします。

  3. 開発者は A は "アクティブな取引先担当者" のシステム ビュー、および取引先担当者のエンティティ用メイン フォームをカスタマイズします。

  4. 開発者は B は取引先企業のエンティティ用メイン フォームをカスタマイズし、取引先担当者の検索ダイアログ ビューを変更します。

  5. 両方の開発者がアンマネージド ソリューションの .zip ファイルをエクスポートして解凍します。

    1. 開発者 A は、取引先担当者のメイン フォームの 1 つのファイルを確認し、"アクティブな取引先担当者" のビューの 1 つのファイルを確認します。

    2. 開発者 B は、取引先企業のメイン フォームの 1 つのファイルを確認し、"取引先担当者の検索ダイアログ ビュー" の 1 つのファイルを確認する必要があります。

  6. それぞれの変更が別のファイルに影響するため、両方の開発者が、任意の順番で送信する場合があります。

  7. 両方の提出が完了した後、彼らは手順 2 を繰り返し、自分たちの独立した組織で変更を続けることができます。 それぞれが両方の変更を持ち、自分の作業は上書きしません。

前の例では、別々のファイルに変更がある場合にのみ成功します。 独立したカスタマイズが単一ファイル内の変更を要求することは避けられません。 上の例に基づき、開発者 B が "アクティブな取引先担当者" のビューをカスタマイズし、開発者 A もそれをカスタマイズする場合を考慮します。 この新しい例では、イベントの順序が重要になります。 この窮地の折り合いをつける正しいプロセスを、完全に書き出すと、以下のようになります。

  1. 開発者 A、B 両方が同じソリューションで作業します。

  2. 独立したコンピューターで、両者ともにソース コントロールからソリューションの最新ソースを取得し、圧縮し、アンマネージド ソリューションの .zip ファイルを別々の組織にインポートします。

  3. 開発者は A は "アクティブな取引先担当者" のシステム ビュー、および取引先担当者のエンティティ用メイン フォームをカスタマイズします。

  4. 開発者は B は取引先企業のエンティティ用メイン フォームをカスタマイズし、"アクティブな取引先担当者" を変更します。

  5. 両方の開発者がアンマネージド ソリューションの . .zip ファイルをエクスポートして展開します。

    1. 開発者 A は、取引先担当者のメイン フォームの 1 つのファイルを確認し、"アクティブな取引先担当者" のビューの 1 つのファイルを確認します。

    2. 開発者 B は、取引先企業のメイン フォームの 1 つのファイルを確認し、"アクティブな取引先担当者" のビューの 1 つのファイルを確認する必要があります。

  6. 開発者 A が最初に準備ができます。

    1. 開発者 A がソース コントロールに送信する前に、最新のリソースを入手して、先着のチェックインが自分の変更と競合しないことを確認します。

    2. 競合がないため、開発者 A は送信できます。

  7. 開発者 B は開発者 A に続いて準備ができます。

    1. 開発者 B は送信する前に最新のリソースを入手して、先着のチェックインが自分の変更と競合しないことを確認します。

    2. 開発者 B が最後最新のリソースを取得してから "アクティブな取引先担当者" のファイルが変更されたため、競合があります。

    3. 開発者 B は競合に対処する必要があります。 使用中のリソースのコントロール ボックスの機能がこの処理を助けることができます。それ以外の場合、次の選択がすべて実行可能です。

      1. 開発者 B は、ソースのコントロール履歴で、可能な場合、開発者 A が既に行った変更を確認できます。 直接のコミュニケーションを通し、それぞれの変更について話し合うことができます。 次に、開発者 B のみが、同意済みの解決法で自分の組織を更新する必要があります。 開発者 B は不整合なファイルをエクスポート、解凍、および上書きし、送信します。

      2. ソース コントロールがこの開発者のローカル ファイルを上書きすることを許可します。 開発者 B はソリューションを圧縮し、自分の組織にインポートし、ビューの状態を評価して必要に応じて再カスタマイズします。 次に、開発者 B は不整合なファイルをエクスポート、解凍、そして上書きできます。

      3. 事前の変更が不要とみなされる場合、開発者 B はファイルのコピーをソース コントロールのバージョンに上書きし、送信します。

共有組織または個別の組織で作業する場合のいずれにおいても、Dataverse ソリューションのチーム開発では、共通ソリューションの作業で他者の作業に注意する必要があります。 SolutionPackager ツールを使用してもこの必要が完全になくなることはありませんが、不整合ではない変更をソース コントロール レベルで簡単にマージし、不整合が発生する場所のコンポーネントを、事前に明確に強調表示します。

次のセクションは、チームで開発するときにソース コントロールで SolutionPackager ツールを効果的に使用する、一般的なプロセスです。 共有組織でのエクスポートと解凍には、エクスポートを実行する開発者による変更だけでなく、当然ながらソリューション内のすべての変更が含まれますが、上記の作業は独立した組織または共有開発組織で共通です。 同様に、ソリューション .zip ファイルをインポートするとき、すべてのコンポーネントを上書きする自然な動作が発生します。

ソリューションの作成

以下の手順は、最初にソリューションを作成する際に使用する典型的な手順を示します。

  1. 制限のない組織で、Dataverse サーバーのソリューションを作成し、コンポーネントを必要に応じて追加または作成します。

  2. チェックインする準備ができたら、以下を実行します。

    1. アンマネージド ソリューションをエクスポートします。

    2. SolutionPackager ツールを使用し、ソリューションをコンポーネント ファイルに解凍します。

    3. これらの解凍済みコンポーネント ファイルから、必要なファイルをソース コントロールに追加します。

    4. これらの変更をソース コントロールに送信します。

ソリューションの変更

以下の手順は、既存のソリューションを修正する際に使用する典型的な手順を示します。

  1. 同期するか、最新のソリューション コンポーネント ファイル ソースを入手します。

  2. SolutionPackager ツールを使用して、コンポーネント ファイルをアンマネージド ソリューションの .zip ファイルに圧縮します。

  3. 組織にアンマネージド ソリューション ファイルをインポートします。

  4. 必要に応じてソリューションをカスタマイズして編集します。

  5. ソース コントロールに変更の確認をする準備ができたら、以下を実行します。

    1. アンマネージド ソリューションをエクスポートします。

    2. SolutionPackager ツールを使用し、エクスポートされたソリューションをコンポーネント ファイルに解凍します。

    3. 同期するか、最新のソースをソース コントロールから入手します。

    4. 競合が存在する場合は調整します。

    5. 変更をソース コントロールに送信します。

    開発組織でそれ以上のカスタマイズが発生する前に、手順 2 および 3 を実行する必要があります。 手順 5 では、手順 b を手順 c の前に終了する必要があります。

関連項目

ソリューション コンポーネント ファイル リファレンス (SolutionPackager)
ソリューションパッケージツール