ソリューションを作成する前に、少し時間をかけて環境戦略とソリューション戦略を計画してください。 次の点を考慮してください。
| 特徴 | 考慮事項 |
|---|---|
| アプリケーション スコープ | 実装は、Sales、Customer Service、Field Service、Finance などの複数のアプリケーションにまたがっていますか? |
| リリースの頻度 | 運用環境に更新プログラムを展開する予定の頻度はどのくらいですか? 配信方法は、スプリント サイクルなどのアジャイル プラクティスに基づいていますか? |
| 運用環境のサポート | 新機能を途中で導入することなく、運用環境で緊急の修正をどのように処理しますか? |
| ソリューション アーキテクチャ | いくつのソリューションを管理していますか? これらのソリューションはコンポーネントを共有しているか、相互に依存していますか? |
| 環境計画 | 開発ライフサイクルをサポートするために必要な Microsoft Dataverse 環境はいくつですか? 開発、テスト、運用に個別の環境が必要ですか? 開発者は共有環境で共同作業を行いますか。それとも、分離された環境を個別に動作させる必要がありますか? |
次のセクションでは、最も単純なものから最も複雑なものまで、3 つの戦略について概説し、それぞれの長所と短所を示します。
単一ソリューション戦略
すべてのカスタマイズは、開発中に 1 つのアンマネージド ソリューションにグループ化され、後でデプロイ用の単一のマネージド ソリューションとしてエクスポートされます。
推奨対象:
- 小〜中規模の実装
- 将来のモジュール化の可能性が低いシナリオ
| 利点 | 不利 |
|---|---|
| 環境のセットアップと管理が簡素化されました。 | 必要に応じて、後でスケーリングまたはモジュール化するために、より多くの労力が必要です。 |
| デプロイが簡略化されました。 管理するソリューションが 1 つしかないため、環境間でのエクスポートとインポートは簡単で、エラーが発生しやすくなります。 | 多数のカスタマイズを含む 1 つのソリューションでは、デプロイ時間が長くなる可能性があります。 ソリューションのサイズを小さくするには、 テーブルのセグメント化を使用します。 インポート時間を短縮するには、 パフォーマンスに関する推奨事項に進む必要があります。 |
| 変更の検索、監査、管理が容易になります。 | 複数の開発者が同じ開発環境で作業すると、お互いの変更が上書きされるリスクがあります。 このリスクは、ソース コードのバージョン管理を実装し、ブランチ戦略を採用し、ブランチごとに専用の開発環境を使用することで軽減できます。 ソース コードのバージョン管理と分岐戦略では、変更の追跡、コラボレーションのサポート、競合解決メカニズムが提供されます。 詳細情報: Git ブランチ戦略を採用する。 |
メモ
Microsoft Power Platform の最近の機能強化により、アップグレード オプションを使用するソリューションを含め、マネージド ソリューションのインポート時間が短縮されました。 これらの最適化には、コンポーネントの依存関係の処理の向上と、変更されていないコンポーネントのオーバーヘッドの削減が含まれます。 これらの機能強化のメリットを得る方法については、パフォーマンスに関する推奨事項に関 するページを参照してください。
同じ開発環境内の複数のソリューション
複数のアンマネージド ソリューションは、1 つの開発環境内で維持されます。各開発環境は、通常、関連のない機能またはモジュール専用です。
推奨対象:
- コンポーネントを共有しない個別の独立した機能領域を持つ小規模な実装。
| 利点 | 不利 |
|---|---|
| 環境のセットアップと管理が簡素化されました。 | 同じ開発環境内で複数のアンマネージド ソリューションを維持すると、依存関係の競合の可能性が高くなります。 たとえば、ソリューション A はソリューション B に依存するためインポートできないのに対し、ソリューション B はソリューション A に依存するためインポートできない場合があります。 |
| 機能領域は、互いに独立して展開できます。 | 同じ開発環境で作業している複数の開発者が、お互いの変更を上書きする可能性があります。 アンマネージド ソリューションで作業しても、分離は提供されません。 すべての変更は、編集中のソリューションに関係なく、環境に直接適用されます。 |
メモ
同じ開発環境に複数のソリューションがある場合、マネージド ソリューションをターゲット環境にインポートした後、多くの場合、レイヤーを作成します。 詳細情報: ソリューション レイヤーとマージ動作
重要なのはあなたが次のことをすることです。
- 複数のソリューションに同じアンマネージド コンポーネントを含めないでください。
- すべてのテーブルを含むソリューションは 1 つだけです。 両方にテーブルが含まれる 2 つの異なるソリューションはありません。 これは、テーブル間に単一の関係があるというリスクが頻繁に発生するためです。これにより、ソリューション間の依存関係が作成されてソリューション アップグレードが起こるか、後で問題を削除されます。
- ソリューション発行元を 1 つだけ使用します。 ソリューションパブリッシャーはマネージド ソリューションのコンポーネントを所有しており、その関連付けを後で変更することはできません。 たとえば、カスタム テーブルがパブリッシャー X を使用してソリューション A を通じてマネージドテーブルとしてインポートされた場合、そのテーブルを Publisher Y を使用してソリューション B に後で移動することはできません。唯一のオプションは、テーブルを削除し、ソリューション A をアップグレードしてターゲット システムからテーブルを削除してから、Publisher Y を使用してソリューション B のテーブルを再作成し、ソリューション B をインポートすることです。このプロセスにより、事前に移行されていない限り、カスタム テーブルに格納されているすべてのデータが失われます。
- ソリューション間の依存関係を作成しないでください。 依存関係によってインポート順序が適用され、問題が発生する可能性があります。 たとえば、テーブル用のソリューションとクラウド フロー用のソリューションがあり、フローがカスタム列に依存している場合、列が存在するため開発中に機能します。 ただし、クラウド フロー ソリューションのみがターゲット環境にインポートされている場合、インポート プロセスでカスタム列への依存関係が認識されない可能性があります。 その結果、フロー ソリューションは正常にインストールされますが、フロー自体は機能しません。 詳細情報: 複数のソリューションによって作成された依存関係の例
複数のソリューションによって作成された依存関係の例
- アプリケーション リボン。 複数のソリューションが同じアプリのアプリケーション リボンまたはサイト マップを変更する場合。
- プラグインまたはクラウド フロー。 プラグインまたはフローがカスタム列でトリガーされるか、カスタム テーブルを更新する場合、オブジェクトはこれらのカスタム テーブルに依存します。
- セキュリティ ロール。 カスタム テーブルが存在する場合、セキュリティ ロールは通常、ユーザー アクセスのためにこれらのテーブルに依存します。
専用開発環境を備えた複数のソリューション
この戦略には、分離された独自の Dataverse 開発環境で各アンマネージド ソリューションを開発する必要があります。 この戦略は、たとえば、Sales、Customer Service、Field Service などのさまざまなアプリケーションが個別に構築および保守されるモジュール アーキテクチャでよく使用されます。 共通コンポーネント (アカウントテーブルや連絡先テーブルなど) を含む基本ソリューションが作成され、各アプリ固有の開発環境にマネージド ソリューションとしてデプロイされます。 その後、各アプリには独自のアンマネージド ソリューションがあり、ベース マネージド ソリューションの上に階層化されているため、チームは基本基盤を変更せずに機能を拡張できます。
推奨対象:
- 大規模なエンタープライズ プロジェクト。
- Teams には複数の開発者やパートナーが含まれています
- 厳密なガバナンスと CI/CD パイプラインを必要とするシナリオ。
| 利点 | デメリット |
|---|---|
| 他のユーザーに影響を与えずにモジュールを追加または更新することで、システムの拡張と進化が容易になります。 | インフラストラクチャとメンテナンスのオーバーヘッドが高くなります。 |
| 複数のチームは、互いの変更と競合することなく、異なるモジュールで並列に作業できます。 | 堅牢な環境戦略とガバナンスが必要です。 |
| 自動化されたテストと DevOps プラクティスを簡単に実装できます。 | より複雑なデプロイ。 |
| 特定のアプリのみをデプロイする必要がある場合、特に CI/CD パイプラインでは、より小さなソリューションを迅速にデプロイできます。 | |
| バグや回帰は、変更が特定のモジュールに分離されたときにトレースする方が簡単です。 |
ソリューションレイヤーを構築する方法
メモ
次の手順でソリューションを作成する前に、環境全体のすべてのソリューションに同じ発行元を使用します。 詳細: ソリューション発行者
- "基本" 開発環境では、共通のアンマネージド テーブルを含む基本ソリューションがあり、他のテーブルはありません。 次に、このソリューションをマネージドとしてエクスポートします。
- 後で基本レイヤーの上に配置される拡張機能または "アプリ" レイヤーの 2 つ目の開発環境を設定します。
- マネージド ベース レイヤーをアプリ レイヤー開発環境にインポートし、アプリ レイヤーのアンマネージド ソリューションを作成します。
- テーブル、列、テーブルリレーションシップ、プラグイン、フローなどを特定の "アプリ" ソリューションに追加することで、データ モデルを拡張できるようになりました。 次に、アプリ ソリューションを管理対象としてエクスポートします。 アプリ ソリューションは引き続き基本レイヤー ソリューションに依存していますが、複数のソリューションをこのように管理する方が適切な方法であることに注意してください。 カスタム列に依存するフローの前に説明した例を考えてみましょう。 ほとんどの場合、カスタム列とフローの両方が同じアプリ ソリューションに存在します。 ただし、カスタム列が基本ソリューションの一部である場合でも、その基本ソリューションを最初にマネージドとして完了してデプロイする必要があります。そうしないと、アプリ ソリューション内のフローを作成することもできません。
- 運用環境では、マネージド基本レイヤーをインポートしてから、マネージド アプリ レイヤーをインポートします。 これにより、マネージド ソリューション間の依存関係が明確な 2 つのマネージド レイヤーが環境内に作成されます。
- 必要に応じて維持するための異なるソリューションをいくつでも用意するために、このパターンを繰り返します。 ただし、ソリューションの階層化を管理しやすくするために、ソリューション数を最小限に抑えることをお勧めします。