この記事には、Git と Microsoft Dataverse の統合に関してよく寄せられる質問への回答が含まれています。
Power Platform のソースコード統合とは何ですか?
Git インテグレーションは、Power Platform カスタマイズ (ソリューションとそのオブジェクト) を Git リポジトリと同期させる簡単な方法を提供します。 ソリューションとそのオブジェクトは、人間が判読できる形式でリポジトリに格納されるため、ソース管理システムでソリューションを簡単に検索、変更の追跡、および管理できます。
Git 統合と既存の開発者ツールの違いは何ですか?
Git の統合は Power Platform に組み込まれており、より高性能で、作成者や管理者のために民主化され、より強固なセーフガードを備え、最適化されたファイル形式を使用しています。 開発者ツールは現在、コード優先の開発者に柔軟性を提供します。
Git 統合を使うための前提条件は何ですか?
Azure DevOpsに接続し、Azure DevOpsのプロジェクトに環境をバインドするために必要なアクセス許可を持つ Power Platform 環境が必要です。 Git にバインドするには、Dataverse 環境でシステム管理者の役割が必要になります。
ソース管理を操作するユーザーには、Azure DevOpsサブスクリプションとライセンスが必要です。 これらのユーザーには、Azure DevOps組織の Basic アクセス レベルと、プロジェクトとリポジトリに貢献するためのアクセス権が必要です。
開発環境とターゲット環境はマネージド環境として有効にする必要があります。
他にどのようなGitプロバイダーがサポートされていますか?
Azure DevOps Git リポジトリは、現在サポートされている唯一の Git プロバイダーです。 この機能は Git プロバイダー モデルを使用するため、他の機能も後でサポートされる可能性があります。
Dataverse との Git 統合を使用するにはどのようなライセンスが必要ですか?
環境内のすべてのユーザーは、マネージド環境のライセンス要件を満たす必要があります。 マネージド 環境は、環境の種類に関係なく必須です。
ソース コード統合を使用する開発者は、リポジトリにアクセスするためにAzure DevOps ライセンスも必要です。 詳細については、「
開発者は、さまざまな開発環境で作業しながら、ソリューションで共同作業を行うことができますか?
はい ソリューションを追加の各環境にインポートし、同じ Git の場所に接続します。 詳細については、「複数の開発環境を Git に接続する」を参照してください
"この環境でソース管理統合が有効になっていませんか?" というエラーが表示されるのはなぜですか?
このエラーは、Bring Your Own Key (BYOK) を使用して環境が暗号化されている場合に発生します。
BYOK は、ソース コードの統合に必要なエラスティック テーブルと互換性がありません。 詳細: 暗号化キーの管理
ソース管理の統合を有効にするには、次の手順に従います。
- 環境の暗号化キーを カスタマー マネージド キー (CMK) に移行します。
- ソース管理に再接続し、操作を再試行します。
環境が BYOK で暗号化されておらず、このエラーが発生した場合は、Microsoft サポート にお問い合わせください。
以下のメッセージが表示されるのはなぜですか、"選択したリポジトリのデフォルト ブランチを取得できませんでした。 新しいブランチを作成できるようにするには、デフォルトのブランチを選択します。
Azure DevOps Git リポジトリが初期化されていることを確認します。 新しいプロジェクトとリポジトリにはデフォルトで初期化されていないリポジトリがあり、デフォルトのブランチを作成するにはリポジトリを手動で初期化する必要があります。
開発、テスト、本番環境をソースコードと統合し、ブランチマージを用いて構成を別の環境にプッシュするべきでしょうか？
この機能は、Git に接続された開発環境内のアンマネージド ソリューションのみを使用するように設計されています。 アップストリーム環境へのデプロイでは、開発環境からマネージド ソリューションをエクスポートしたり、 Power Platform CLIpack コマンドを使用してソース管理からソリューションを構築したり、Power Platform でパイプラインを使用したりする必要があります。
ブランチを操作するにはどうすればいいですか?
この機能は現在、環境またはソリューションをリポジトリにバインドするときに指定する単一のブランチで動作します。 切断して別のブランチに再接続したり、プル要求 (PR)、マージ、その他の高度な Git 操作にAzure DevOpsを使用したりできます。
たとえば、開発を開発者ブランチに接続し、変更を機能ブランチに PR してから、ソリューションを切断して機能ブランチに再接続し、最新の変更を環境に取り込むことができます。
Gitのさまざまなオブジェクトに対してアンマネージドとマネージドソリューション表現がないのはなぜですか?
この機能が利用可能になる前は、マネージド とアンマネージド ソリューション バージョンを Git に格納するのが一般的でした。 これは不要になりました。 Git には、ソース コードとアンマネージドのカスタマイズのみを含める必要があります。 マネージドとアンマネージドは、ソリューションをビルドしてリリースする際に決定されます。
ソース コード ファイルは YAML であるのに、ソリューションのエクスポートは主に XML のままなのはなぜですか?
この機能では、ソリューション コンテンツを表すために YAML を使用しています。なぜなら、これは読みやすく、理解しやすくなり、マージも容易になるからです。
YAML ソース管理形式で使用されるフォルダー構造は何ですか?
ソリューションが Dataverse Git 統合を使用してコミットされるか、 pac solution cloneを使用して抽出されると、リポジトリ ルートの下の特定のフォルダー レイアウトに格納されます。
-
solutions/<SolutionUniqueName>/—solution.ymlおよびサポート マニフェスト ファイル (solutioncomponents.yml、rootcomponents.yml、missingdependencies.yml) が含まれています -
publishers/<PublisherUniqueName>/— 次のものが含まれます。publisher.yml - リポジトリ ルートにあるコンポーネント フォルダー (
entities/、workflows/、canvasapps/など)
この構造は、SolutionPackager または .zip を使用してフォルダーをpac solution pack ファイルに手動でパックする場合に必要です。
solutions/<name>/の下ではなくリポジトリルートに YAML ファイルを配置すると、Customizations.xmlが見つからないという誤解を招くエラーが発生します。 完全なリファレンスについては、 ソリューション YAML ソース管理の形式に関するページを参照してください。
ソース コードからソリューションをビルドして展開するにはどうすればよいですか?
Microsoftツールで YAML ソリューション形式をビルドできるようになりました。
Power Platform CLIpack コマンドを使用することをお勧めします。
unpack、clone、およびsyncコマンドは、現在 YAML 形式をサポートしていません。
コンパイルしたバイナリをソースコードにチェックさせたくない場合、コード ファースト オブジェクトで開発するにはどうすればよいですか?
現時点では、別のソリューションと Git フォルダーを使用して、Power Apps コンポーネント フレームワーク コントロールやプラグインなど、さまざまなオブジェクトを作成できます。
競合の解決方法
単純な競合は、ソリューションのソース管理ページで保持するバージョン (環境と Git) を選択することで解決できます。
ブランチのマージ時に検出されるマージ競合は、現在 Git 内で管理されています。
ソリューションのすべての変更ではなく、特定の変更をコミットできますか?
現時点では、ソリューション内の保留中のオブジェクトの変更をすべてコミットする必要があります。 ただし、コミットしない場合は、ソリューションからオブジェクトを削除できます (環境から削除することはできません)。 オブジェクトをコミットする準備ができたら、後でオブジェクトを追加し直します。
API を使用して Git にバインドし、コミットとプルをトリガーできますか?
はい 開発者向けドキュメントについては、Git、、CommitToGit への接続に関して、RefreshChangesFromGitのPullChangesFromGitを参照してください。
サポートされている方法でソース管理に直接変更を加えることはできますか?
この機能では、ソリューションのカスタマイズへの直接的な変更のサポートは変更されません。 環境内で直接変更を加え、その変更をソース管理にコミットするという方法を引き続き実行することをお勧めします。 ローカライズされたラベルの変更はソース内で直接許可されます。 開発者ツールを使用してサポートされるコードファースト オブジェクトもサポートされ、プラグイン、PCF コントロール、Web リソースが含まれます。
Git 統合を無効にすることはできますか?
Git への接続を防ぐためのテナントレベルまたは環境レベルの設定はありません。 ただし、Git へのアクセスは Git リポジトリ内で管理できます。 Git 接続パネル内で環境を切断することもできます。
大規模なソリューションをコミットできますか?
はい Git 統合を使用して大規模なソリューションをコミットできます。 ただし、Azure DevOpsでは、コミット操作中に個々のファイルごとに 17 MB の制限が適用されます。
ほとんどのソリューションは、多くのファイルで構成されています。 キャンバス アプリの成果物、プラグイン アセンブリ、その他のバイナリ負荷の高いコンポーネントなど、一部の個々のファイルは、この制限に近づいたり超えたりする可能性があります。 Azure DevOpsは最大 25 MB のファイルをサポートしていますが、ファイルはコミット プロセス中に base64 でエンコードされるため、サポートされるサイズは実質的に約 17 MB に削減されます。
大規模なソリューションを処理するために、システムは自動的に次の処理を行います。
- ソリューションを複数の小さなファイル バッチに分割します
- 各バッチを個別にコミットします
- コミットをスカッシュマージして、Git 履歴がクリーンなままになるようにします
ソリューション内の 1 つのファイルが 17 MB の制限を超えた場合でも、コミットが失敗する可能性があります。 これは、大規模な Canvas アプリ、大規模なプラグイン アセンブリ、PCF コントロール バンドル、またはその他のバイナリ負荷の高いコンポーネントでよく見られます。
ファイル サイズが原因でコミット エラーが発生した場合は、未使用のリソースを削除するか、大規模な Canvas アプリをより小さなコンポーネントまたはライブラリに分割することで、影響を受けるコンポーネントのサイズを小さくすることを検討してください。
すべてのオブジェクトタイプがサポートされていますか?
現在、使用頻度の低いレガシ オブジェクトの種類の一部はサポートされていません。 サポートされていないオブジェクトの種類が検出されると、ソリューション オブジェクト ビューでエラーが発生します。
既存のソリューションをアップグレードする方法を教えてください。
環境内の既存のソリューションを Git に接続してコミットできます。 ソリューションが Git のみの場合は、最初に開発者ツールを使用して、アンマネージド ソリューションをパックし、新しい開発環境にインポートします。 古いファイル形式と新しいファイル形式の間の中断を伴う変更を回避するために、新しいソース コードの場所をお勧めします。 YAML ソース管理ソリューションのパッキングの詳細については、「 SolutionPackager ツール」を参照してください。
Git 統合を使用してメタデータの変更を監査できますか? 市民開発者も対象ですか?
はい、これは一般的です。 Dataverse API を使用して、変更を自動的にコミットすることもできます。
Git 統合はソブリン クラウドで利用できますか?
はい
Git にプッシュされた変更を自動的にデプロイできますか?
はい。Azure PipelinesまたはGitHub Actionsを使用して、自動ビルドとリリースをトリガーできます。
Power Platform CLIpack コマンドは、他の環境にインポートされるソリューション成果物をビルドします。 または、Power Platform または Power Platform CLI pac パイプライン コマンドのパイプラインを使用してデプロイすることもできます。
ADO リポジトリとは異なる地域にある環境を接続できますか?
環境が ADO リポジトリとは異なる地域にある場合は、同意が必要です。 接続時にメッセージと同意が表示されます。
Git 統合はクロス テナント (x テナント) ワークロードをサポートしていますか? たとえば、Power Platform/Dataverse 環境がAzure DevOpsとは異なるテナントにある場合です。
現時点ではまだできません。
Git 統合はセキュリティ スキャンをサポートしていますか?
選択したスキャン ツールをAzure DevOpsツールに統合できます。