Solution Packager ツールは、ソース コントロール システムで使用できます。 ソリューションの .zip ファイルをフォルダに解凍した後、ソース管理システムにファイルを追加して送信します。 これらのファイルは他のコンピューター上で同期し、新しい一意のソリューション .zip ファイルにまとめることができます。
ソース コントロール内の抽出したコンポーネント ファイルを使用するときの重要な点は、すべてのファイルをソース コントロールに追加すると不要な重複が生じる可能性があることです。 ソリューション コンポーネント ファイル リファレンス をご参照いただき、どのファイルが各コンポーネント用に生成され、どのファイルがソース コントロールの使用に推奨されているかをご確認ください。
ソリューションのためにさらにカスタマイズと変更が必要な場合、開発者は、既存の手法を使用してコンポーネントを編集またはカスタマイズし、再度エクスポートして .zip ファイルを作成し、圧縮されたソリューションを同じフォルダーに解凍します。
重要
カスタマイズ ファイルを編集するときに記載されているセクションを除いて、抽出されたコンポーネント ファイルと .zip ファイルの手動編集はサポートされていません。
Solution Packager ツールがコンポーネント ファイルを抽出する際、ファイルの内容が同一であれば、同じ名前の既存のコンポーネント ファイルを上書きすることはありません。 また、ツールはコンポーネント ファイルの読み取り専用属性に従い、書き込みしなかった特定のファイルについてコンソール ウィンドウ上に警告を示します。 この保護により、ユーザーはソース コントロールから、変更する最小のファイル セットを確認できます。
/clobber パラメーターは読み取り専用のファイルに対する制限を無効化し、書き込みや削除が可能になります。
/allowWrite パラメーターを使用すると、実際にファイルの書き込みまたは削除をせずに、解凍操作により生じる影響を評価できます。
/allowWrite パラメーターは詳細なロギングと共に使用すると効果的です。
ソース コントロールから最小ファイル セット確認されて解凍操作が終了した後、開発者は変更済みファイルを、他の種類のソース ファイルでするような仕方で、ソース コントロールに戻す場合があります。
ソース管理ファイルの形式
ソリューション パッケージ ツールは、抽出されたコンポーネント ファイルに対して 2 つのファイル形式をサポートします。 適切な形式を前もって選択すると、後でリポジトリ構造を移行する必要がなくなります。
| XML 形式 (レガシ) | YAML ソース管理の形式 | |
|---|---|---|
| ソリューション マニフェスト | Other\Solution.xml + Other\Customizations.xml |
solutions/<name>/solution.yml および YAML ファイルのサポート |
| 読み やす さ | 詳細な XML | コンパクトな YAML - 読みやすく、確認しやすい |
| Git での品質の相違 | 大規模な XML 差分 | フォーカスを絞った最小限の差分 |
| マルチソリューション リポジトリ | サポートしていません | サポートされている - 複数のソリューションが 1 つのフォルダーを共有する |
| キャンバス アプリ (.msapp) | サポートしていません | サポートされている |
| 最新のフロー | サポートしていません | サポートされている |
| ネイティブ Git 統合 | 使用しない | 常に使用 — Git 統合では常に YAML が書き込まれます |
YAML 形式を使用する場合: すべての新しいプロジェクト、およびネイティブ の Dataverse Git 統合を使用する場合。 YAML 形式は前方互換性があり、よりクリーンな変更履歴が生成されます。
XML 形式を使用する場合: 既に XML 形式を使用している既存のリポジトリを操作する場合、または YAML をサポートしていないレガシ ツールを使用している場合のみ。
注
Power Appsでネイティブ Git 統合を使用してソリューションをコミットすると、常に YAML ソース管理形式で格納されます。 SolutionPackager または pac solution pack を使用してそのソースを手動でパックまたはアンパックするには、フォルダーが YAML フォルダー構造に従っている必要があります。 詳細情報: SolutionPackager ツール - ソース管理ファイル形式
チーム開発
同じソリューション コンポーネントで複数の開発者が作業するとき、2 人の開発者が 1 つのファイルを変更する場合に競合が発生する場合があります。 個々のコンポーネントまたはサブコンポーネントを異なるファイルに分解することで、この発生を最小限にできます。 以下の例を考慮してください。
開発者 A、B 両方が同じソリューションで作業します。
独立したコンピューターでは、両方ともソース管理からソリューションの最新のソースを取得し、アンマネージド ソリューション .zip ファイルを独立したMicrosoft Dataverse組織にインポートします。
開発者 A は、"アクティブな連絡先" システム ビューと連絡先エンティティのメイン フォームをカスタマイズします。
開発者 B は、取引先企業エンティティのメイン フォームをカスタマイズして、「取引先担当者の参照ビュー」を変更します。
両方の開発者がアンマネージド ソリューションの .zip ファイルをエクスポートして解凍します。
開発者 A は、連絡先メイン フォーム用に 1 つのファイルをチェックアウトし、[アクティブな連絡先] ビューに 1 つのファイルをチェックアウトする必要があります。
開発者 B は、取引先企業のメイン フォーム用のファイルと、「取引先担当者の参照ビュー」用のファイルをそれぞれ確認する必要があります。
それぞれの変更が別のファイルに影響するため、両方の開発者が、任意の順番で送信する場合があります。
両方の提出が完了した後、彼らは手順 2 を繰り返し、自分たちの独立した組織で変更を続けることができます。 それぞれが両方の変更を有しており、自分の作業を上書きしてしまうことはありません。
前の例では、別々のファイルに変更がある場合にのみ成功します。 独立したカスタマイズが単一ファイル内の変更を要求することは避けられません。 前に示した例に基づいて、開発者 B が "アクティブな連絡先" ビューをカスタマイズしたのに対し、開発者 A もカスタマイズしていたとします。 この新しい例では、イベントの順序が重要になります。 この状況を解消する正しいプロセスをすべて書き出すと、以下のような内容になります。
開発者 A、B 両方が同じソリューションで作業します。
独立したコンピューターで、両者ともにソース コントロールからソリューションの最新ソースを取得し、圧縮し、アンマネージド ソリューションの .zip ファイルを別々の組織にインポートします。
開発者 A は、"アクティブな連絡先" システム ビューと連絡先テーブルのメイン フォームをカスタマイズします。
開発者 B は取引先企業テーブルのメインフォームをカスタマイズし、「アクティブな連絡先」を変更します。
両方の開発者がアンマネージド ソリューションの .zip ファイルをエクスポートして解凍します。
開発者 A は、連絡先メイン フォーム用に 1 つのファイルをチェックアウトし、[アクティブな連絡先] ビューに 1 つのファイルをチェックアウトする必要があります。
開発者 B は、アカウント メイン フォーム用に 1 つのファイルをチェックアウトし、[アクティブな連絡先] ビュー用に 1 つのファイルをチェックアウトする必要があります。
開発者 A が最初に準備ができます。
開発者 A がソース コントロールに送信する前に、最新のリソースを入手して、先着のチェックインが自分の変更と競合しないことを確認します。
競合がないため、開発者 A は送信できます。
開発者 B は開発者 A に続いて準備ができます。
開発者 B は送信する前に最新のリソースを入手して、先着のチェックインが自分の変更と競合しないことを確認します。
"アクティブな連絡先" のファイルは、開発者 B が最後に最新のソースを取得してから変更されているため、競合があります。
開発者 B は競合に対処する必要があります。 使用中のリソースのコントロール ボックスの機能がこの処理を助けることができます。それ以外の場合、次の選択がすべて実行可能です。
開発者 B は、ソースのコントロール履歴で、可能な場合は開発者 A が既に行った変更を確認できます。 直接のコミュニケーションを通し、それぞれの変更について話し合うことができます。 次に、開発者 B のみが、同意済みの解決法で自分の組織を更新する必要があります。 開発者 B は不整合なファイルをエクスポート、解凍、および上書きし、送信します。
ソース管理がローカル ファイルを上書きすることを許可します。 開発者 B はソリューションをパッケージ化し、それを組織にインポートし、ビューの状態を評価し、必要に応じて再カスタマイズします。 次に、開発者 B が競合するファイルをエクスポート、抽出、上書きする可能性があります。
事前の変更が不要とみなされる場合、開発者 B はファイルのコピーをソース コントロールのバージョンに上書きし、送信します。
共有環境または独立環境で作業する場合に関わらず、Dataverse ソリューションのチーム開発には、共通のソリューションに積極的に取り組むユーザーが、他のユーザーの作業を認識している必要があります。 Solution Packager ツールは、この必要性を完全に排除するものではありませんが、ソース管理レベルで競合しない変更を簡単にマージできるようにし、競合が発生する可能性のある簡潔なコンポーネントを事前に強調表示します。
次のセクションは、チームで開発するときにソース コントロールで Solution Packager ツールを効果的に使用する一般的なプロセスです。 これらは独立した環境でも共有開発環境でも同様に機能しますが、共有環境では、エクスポートと抽出にはエクスポートを実行した開発者による変更だけでなく、ソリューション内のすべての変更が含まれます。 同様に、ソリューション .zip ファイルをインポートするとき、すべてのコンポーネントを上書きする自然な動作が発生します。
ソリューションの作成
この手順では、ソリューションを最初に作成する際に使用する典型的なステップを特定します。
Dataverse を使用してクリーンな環境でソリューションを作成し、必要に応じてコンポーネントを追加または作成します。
チェックインの準備ができたら、以下の手順に従ってください。
アンマネージド ソリューションをエクスポートします。
Solution Packager ツールを使用し、ソリューションをコンポーネント ファイルに解凍します。
これらの解凍済みコンポーネント ファイルから、必要なファイルをソース コントロールに追加します。
これらの変更をソース コントロールに送信します。
ソリューションの変更
以下の手順は、既存のソリューションを修正する際に使用する典型的な手順を示します。
同期するか、最新のソリューション コンポーネント ファイル ソースを入手します。
Solution Packager ツールを使用して、コンポーネント ファイルをアンマネージド ソリューションの .zip ファイルに圧縮します。
環境にアンマネージド ソリューション ファイルをインポートします。
必要に応じてソリューションをカスタマイズして編集します。
ソース管理に変更を反映する準備ができたら、以下の手順に従ってください。
アンマネージド ソリューションをエクスポートします。
Solution Packager ツールを使用し、エクスポートされたソリューションをコンポーネント ファイルに解凍します。
同期するか、最新のソースをソース コントロールから入手します。
競合が存在する場合は調整します。
変更をソース コントロールに送信します。
開発組織でそれ以上のカスタマイズが発生する前に、手順 2 および 3 を実行する必要があります。 手順 5 では、手順 b を手順 c の前に終了する必要があります。
関連項目
ソリューション コンポーネント ファイル リファレンス (SolutionPackager)
SolutionPackager ツール
ソース管理ファイルの形式