Dataverse Git 統合の概要 (プレビュー)
[この記事はプレリリース ドキュメントであり、変更されることがあります。]
ソース管理の統合により、開発チームは Azure DevOps Git リポジトリを使用して、1 つ以上の Microsoft Dataverse 環境間で同期ソリューションとソリューション オブジェクトを同期できます。 ソース管理統合機能はソリューション エクスペリエンス内でネイティブに利用できるため、シチズン デベロッパー、コード ファースト デベロッパー、管理者は、さまざまなツールや環境間でバージョン管理、変更追跡、シームレスなチーム コラボレーションのメリットを享受できます。 Git 統合は、開発環境での使用を目的としており、ソリューション成果物とデプロイするパイプラインを作成するビルドを使用してデプロイを行うことができるテスト環境や運用環境では使用しないでください。
重要
- これはプレビュー機能です。
- プレビュー機能は運用環境での使用を想定しておらず、機能が制限されている可能性があります。 これらの機能を公式リリースの前に使用できるようにすることで、顧客が一足先にアクセスし、そこからフィードバックを得ることができます。
- この機能は現在、早期リリース サイクル用に作成された環境でのみ利用できます。 早期リリース サイクル環境に移動する
この記事では、Dataverse 環境とソリューションで Git 対応ソース管理を使用する際の主要な概念と利点について説明します。 Git の詳細については、Azure DevOps Azure DevOps Git リポジトリを参照してください。
Power Platform と Dataverse の ALM
Power Platform は、組織がソリューションのアプリケーション ライフサイクル管理 (ALM) を管理できるようにする、すぐに使用できる機能を多数提供します。 プラットフォーム内のさまざまな種類のコンポーネントのコンテナーとしてソリューションをパッケージ化し、アプリケーション ライフサイクルに関係する環境を管理し、Power Platform でパイプラインを使用して、ソリューションを展開する機能が含まれています。 開発者ツールを使用して Power Platform で Git リポジトリを統合する方法もいくつかあります。 Dataverseの Git のネイティブ統合により、プロセスが簡素化および合理化され、メーカーは使い慣れた方法でソリューションを操作し、 Power Apps (make.powerapps.com) の簡素化されたインターフェースを通じてソース管理と対話できるようになります。
給付
- 真実のソースとしてのソース管理: 一部の組織では、Dataverse での展開の真実のソースとなるのは、ソリューションが構築されるメーカー環境です。 この動作の主な原因は、非ネイティブの Git 統合では高度な技術とツールが使用され、開始するには専門的な IT 専門知識が必要になることです。 Dataverse での Git のネイティブ統合により、わずか数ステップでソース管理を有効にでき、メーカーがソリューションを操作するための使い慣れたインターフェースが提供されます。
- SDLC ベスト プラクティスを使用した安全性、監査、コンプライアンス: ソフトウェア開発ライフサイクル (SDLC) のベスト プラクティスは、ソフトウェア開発プロジェクトを効果的に管理するのに役立つ一連のガイドラインとプロセスです。 Dataverse で Git 統合を使用すると、バージョン管理、コード レビュー、静的ソース コード分析などの SDLC プラクティスに追従することで、ソリューションの品質、信頼性、セキュリティを確保できます。 Dataverse の Git 統合では、監査、コンプライアンス、トレーサビリティなどの機能も提供され、ソリューションの変更を追跡したり、他のチーム メンバーと効果的に共同作業を行ったりするのに役立ちます。
- 短期間の開発環境: 環境のカスタマイズと構成のコピーをソース管理に保存することで、ソース管理から Dataverse 内で開発環境を迅速かつ簡単に復元できます。 これにより、開発およびテストの目的で短期間の環境を作成できます。 短命の環境を使用すると、永続的な環境に依存せずに、ストレージを解放し、新しい機能を試し、ソリューションをテストおよび反復することができます。
- Fusion 開発チーム: Fusion 開発チームは、ソリューションを構築するために協力する開発者とメーカーの両方で構成されるチームです。 Dataverseの Git 統合を使用すると、これらのユーザーは別々の環境で独立してビルドし、共通のソース管理リポジトリと同期して他のユーザーと共同作業を行うことができます。 ソース管理の統合により、開発者とメーカーの両方のスキルと専門知識を活用して、組織のニーズを満たす高品質のソリューションを構築できます。
- 保護: ソリューションの信頼できる情報源としてソース管理を使用すると、ソリューションの意図しない変更から迅速かつ簡単に回復できます。 ソリューションをソース管理に保存することで、以前の状態またはバージョンに復元できます。
重要な概念
マネージド ソリューションとアンマネージド ソリューションの比較
Dataverseとの Git 統合を使用している場合、ソース管理に保存されるソリューションは、作成者の環境内の管理されていないソリューションから取得されます。 管理されていないソリューションを使用すると、変更をコミットしてプッシュするときに、ソース管理と同期されるコンポーネントを作成者が追加、削除、更新できます。 マネージド ソリューションはソース管理から構築され、テストや運用などの下流環境に展開されますが、それらの環境では編集できません。 マネージド ソリューションは、ソリューションの信頼できるソースが常にソース管理であること、および変更がソース管理に追加されて他の場所に展開される前に、作成者の環境でのみ行われることを保証するために使用されます。
ソリューション コンポーネントのファイル形式
Dataverse での Git 統合の導入により、ソース管理でのソリューションとソリューション コンポーネントの表現方法が変更されました。 変更をコミットしてソース管理にプッシュすると、ソリューション コンポーネントは Git と互換性のある特定の形式で保存されます。 この形式は、ソリューション コンポーネントを読みやすく理解しやすい方法で表現するために使用され、時間の経過に伴うソリューション コンポーネントの変更を追跡するために使用できます。 ソリューション コンポーネントのファイル形式は人間が判読できるように設計されており、ソース管理でソリューション コンポーネントへの変更を表示するために使用できます。 さらに、複数のソリューションを同じリポジトリとフォルダーに保存できるようにするために、ソース管理内のソリューション コンポーネントがソリューションごとに重複しなくなりました。 代わりに、ソリューション コンポーネントは 1 つの場所に保存され、同じリポジトリとフォルダー内の複数のソリューション間で共有できます。
Git を使ったコードファースト開発
Power Platform のコードファースト開発は、Power Platform CLI、Visual Studio、Visual Studio Code 拡張機能などの開発ツールを使用して実現されます。 ソース管理の統合がなければ、コードファースト開発者をソリューション開発プロセスに参加させることは困難です。これは、Power Apps Component Framework (PCF) コントロールや Dataverse プラグインなどのコンポーネントが、ソース コードから構築されたパッケージ化されたアセットとしてソリューションに展開され、Power Apps (make.powerapps.com) で直接編集できないためです。 ローコード コンポーネントとコードファースト コンポーネントの両方の開発プロセスの一部としてソース管理がなければ、ソリューションへの変更を管理し、変更が制御された方法で追跡および展開されるようにすることは困難です。
Dataverse で Git 統合を有効にすると、コードファースト開発者の作業環境に対応でき、ローコード開発者とコードファースト開発者の両方にシームレスなエクスペリエンスを提供できます。 ただし、ローコード環境でコードファースト コンポーネントを管理する場合には、留意すべき点がいくつかあります。
Dataverse Git 統合を使ったフュージョン開発
Power Platform は、ローコード開発とコードファースト開発の両方の機能を提供します。 この記事では、コードファースト開発プロセスに関連する Dataverse および Git 統合について説明し、コードファースト コンポーネントとローコード コンポーネントを単一の環境で管理する方法に関するガイダンスを提供します。 Power Apps component framework コントロール、Dataverse プラグイン、カスタム ワークフロー活動などのコンポーネントは、ソース管理で管理できるコードファースト コンポーネントの例です。
単一環境でのコードファーストとローコードコンポーネント
コードファースト コンポーネントは、Dataverse 環境にインポートできるマネージド ソリューションまたはアンマネージド ソリューションを生成するビルド プロセスを通じてソリューションに含めることができます。 ただし、コード ファースト コンポーネントは、ソリューション ビルド プロセスを使用して展開せずにビルドすると、メーカー環境のアンマネージ ソリューションに直接展開することもできます。 この柔軟性を考慮すると、ビルド プロセスがあります。
コードファースト コンポーネントをメーカー環境のアンマネージ ソリューションに直接展開する場合、それらのコンポーネントがソース管理にコミットされると、コンパイルされた (ビルドされた) バージョンのみがソース管理に保存されます。 例えば、プラグインの場合はバイナリ DLL、または Power Apps component framework control の場合はトランスパイルされ最適化されたバンドル JavaScript などです。 その結果、ソース管理にはコンポーネントの 2 つのコピーが残ることになります。1 つはビルドされたバージョンで、もう 1 つはソースコードで表されます。 リポジトリにバイナリを保存すると、ソース コードとビルドされたバージョンが同期されていない場合、混乱や潜在的な競合が発生する可能性があります。ソース コードはコンポーネントの唯一の情報源である必要があり、単一のコピーのみを保存する必要があるため、この方法は推奨されません。
推奨されるアプローチは、ソリューション ビルド プロセスの一部としてコードファースト コンポーネントを構築し、生成されたアンマネージ ソリューションをメーカー環境にインポートすることです。 このアプローチにより、ソース コードとビルドされたバージョンが同期され、ソース コードがコンポーネントの唯一の情報源になることが保証されます。 ただし、このアプローチでは、インポート プロセスおよび展開プロセスで使用するために、マネージド ソリューションまたはアンマネージド ソリューションを生成するためのビルド プロセスを用意する必要があります。 たとえば、Power Platform パイプラインや Git 同期プロセスが使用する成果物を作成する Azure Pipelines または GitHub ワークフローを作成できます。