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