ALM ワークショップのトピック
このユニットでは、アプリケーション ライフサイクル管理 (ALM) ワークショップのテンプレートを入力および評価する際に考慮する事項について説明します。 これらのトピックは、ソリューション アーキテクトがワークショップで収集した情報を評価し、調査結果とレコメンデーションを作成するのに役立つように設計されています。 ALM がすべてに適合するとは限りません。 プロジェクトごとに、適用する ALM の内容と精度を決定する必要があります。 Dynamics 365 と Microsoft Power Platform での ALM を理解するには、Microsoft Power Platform でのアプリケーション ライフサイクル管理 のトピックを読んで確認することをお勧めします。
全体的な戦略
ソリューションを作成するには、プロジェクト チームによって使用されている開発手法を理解することが重要です。 また、関与するチームの数、特にカスタマイズに関与するチームの数を理解することも重要です。 ALM 戦略はこれらのチームをサポートするためのもので、プロジェクトチームの効果的な作業を支援する必要があります。
重要な検討事項
開発手法の欠如 「とりあえずやってみよう」というのは、良いアプローチとは言えません。
Microsoft Power Platform および Dynamics 365 のプロジェクトでは、従来のウォーターフォール手法を使用することはお勧めできません。 ほとんどのチームは、優れたプロジェクトを実現するために、アジャイル アプローチまたは反復アプローチの形を活用しています。
変更を行うために関与すべき人物と、その変更をどのように実施するかを明確に把握できていない場合、それはリスクとなります。
作業項目の割り当てを含む作業項目の追跡ツールが用意されているか?
ALM の進化
すべてのお客様が最初から ALM プロセスを完全に自動化しているわけではありません。 一部のお客様は、段階的な (ハイハイ - 歩く - 走る: Crawl-Walk-Run) アプローチを選択しています。
開発においてアンマネージド
ハイハイ (Crawl):
- エクスポート/インポート
- エクスポート/ファイルに保存
- システム/インポート
歩く (Walk):
- ソース管理のない複数のソリューション
- マスター データの導入
- ソリューション ベースのソース管理の導入
走る (Run):
- パッケージの展開による自動化の導入
- ソリューション パッケージャーを通じて有効になったバージョン管理
上流のあらゆる場所でマネージド
- 自動ビルドとインスタンス管理
- 自動ソース管理された Azure DevOps
環境
実装中の ALM 戦略をサポートするためには、環境を作成する必要があります。 少なくとも、プロジェクトには、開発、テスト、および実稼動環境が通常必要です。 これらの環境は、試用環境またはコミュニティ環境ではなく、サンドボックス環境または運用環境のいずれかである必要があります。 さらに、Go-Live 後に運用環境に適用する必要がある変更用に修正プログラム環境を用意することも検討してください。
異なる地域に環境を作成する場合、チームは、環境が異なる時間に更新されることを認識しておく必要があります。 たとえば、カナダで開発が行われており、北米地域で稼働している場合は、北米にはない機能がカナダに存在する可能性があります。 複数の地域を使用している場合は、Microsoft の更新や機能を使用した調整がより必要になります。
各 Microsoft Dataverse ソリューションには、カスタマイズを行うチーム メンバーをサポートするための開発環境が少なくとも 1 つなければなりません。 ソース中心型のモデルでは、複数の開発環境を使用できますが、マージする際の競合が発生時した場合、解決するには調整が必要です。 単一の開発環境では、基本的な調整のみが必要であるため管理が簡単になりますが、複数の環境では、開発者の高度な分離とチームのスピードアップができます。 適切なアクセス制御を配置して、適切なチーム メンバーだけがさまざまな環境にアクセスできるようにする必要があります。 これにより、ユーザーは、割り当てられた開発環境以外の部分で変更を行うこともできなくなります。
環境についての重要な検討事項
適切な数の環境が特定されているか? 少なくとも、開発、テスト、および実稼動環境が必要です。 明確な目的がないまま多くの環境を作成すると、管理が困難になる可能性があります。
アンパック ソリューションをソース管理に保存することが計画されているか?
トライアル環境は使用されているか? そのような場合は、トライアルの期限が予期せずに切れてしまい、実施したカスタマイズが失われる可能性があります。
環境計画をサポートするために使用できるストレージ容量があるか?
ソース管理
また、カスタマイズやその他のコード資産がさまざまなテスト環境を通じて、実稼働環境に対してどのように展開されるかを理解することも重要です。 ここで重要なことは、何をカスタマイズとコード資産の信頼できるソースとするかです。 従来、プロジェクトは環境中心型で、たとえば開発環境がカスタマイズの信頼できるソースとされていました。 このモデルでは、カスタマイズは、開発からテスト、および実稼動に直接移行することができます。 変更は開発からエクスポートされたソリューションとして転送されます。
過去に完了した既存のソリューションを改良している場合は、これは元のプロジェクトで使用されたモデルになります。 新しいプロジェクトでは、すべてのカスタマイズとプロジェクトのコード資産の信頼できるソースとしてソース管理を使用する必要があります。 たとえば、Azure DevOps git リポジトリを使用して、すべてを保存できます。 プロジェクトチームは、このモデルを使用して、ソース管理でカスタマイズした内容を確認できます。 展開されるマネージド ソリューションは、ソース管理から生成され、カスタマイズをテストや実稼働に展開するために使用されます。 この方法では、開発環境を破棄することが可能になります。 ソース管理中心型アプローチのもう 1 つの利点は、変更された内容に関する詳細情報を保持し、分岐戦略を支援することです。 分岐は、次のバージョンが作成されているときに運用バージョンのサービスを有効にするために不可欠です。 さらに、プル要求をリンクするか作業項目にコミットすることで、追跡可能性を高め、開発プロセス全体を改善します。
ソース管理についての重要な検討事項
ソース管理中心型ではなく環境中心型のアプローチを過去に使用していた場合、ソース管理に移行する計画はあるか?
適切な数の環境が特定されているか? 少なくとも、開発、テスト、および実稼動環境が必要です。 作成する環境が多すぎると、管理が困難になる可能性があります。
マネージド ソリューションは、開発以外のすべての環境で使用されているか?
ソリューション
可能な場合、ソリューション対応コンポーネントであるすべてのプロジェクト資産を、Dataverse ソリューションで管理する必要があります。 単一の基幹業務またはビジネス プロセスに重点を置いたプロジェクトでは、ほとんどの場合、単一のカスタム ソリューションを使用する必要があります。 プロジェクト チームは、作成している会社または製品を表すカスタム ソリューション発行者を関連付けて、デフォルトの発行者を使用しないようにする必要があります。 必要とされるビジネス ケースがある場合を除き、複数の発行元を使用しないでください。
複数のソリューションを使用する場合は、解決する特定の目的に合わせて使用する必要があります。 たとえば、独立したソリューションに配置されるプロジェクトは、複数回使用することが計画されている再利用可能なコンポーネントです。 ソリューションは、業種またはビジネス プロセス別にセグメント化できます。 このようにセグメント化されたソリューションは、共通の基盤を共有することができますが、それぞれに依存関係はなく、カスタマイズに応じて分離される必要があります。 ただし、これによって管理が複雑になり、個別のソリューションを使用するメリットについての評価が必要になります。
各ソリューションは、独自の開発環境を用意し、分離を維持する必要があります。 ソリューションが別のソリューションに依存している場合は、依存しているソリューションのマネージド バージョンを開発環境にインストールする必要があります。 ソリューション フレームワークは、修正プログラム ソリューションの概念をサポートしていますが、ソース中心型のモデルを使用する場合は推奨されません。
ソリューションについての重要な検討事項
チームは既定の発行元を使用しておらず、適切なカスタマイズ プレフィックスを使用してカスタム発行元を作成しているか?
提案されているソリューション アーキテクチャはそれぞれ、明確な目的を持つ適切な数のソリューションを使用しているか?
環境計画は、プロジェクトで使用されるソリューションの数をサポートし、適切なソリューションの分離を実現しているか?
計画の作成
ここでは、複数の環境を使用するソリューションの構築を、チームがどのように計画するかについて説明します。 ソリューションは、コンポーネントを変更することができる開発環境で構成する必要があります。 ALM 計画では、開発環境のみで変更が行われるように確保する必要があります。 アンマネージド ソリューションを使用する場所は、開発環境のみに限定する必要があります。他のすべての環境には、管理ソリューションがインストールされている必要があります。 各開発環境では、単一のアンマネージド ソリューションのみを保持する必要があります。
ソリューションを手動でエクスポートしてインポートする機能はサポートされていますが、ビルド プロセスには、繰り返し可能なプロセスを作成するためのいくつかの自動化が含まれている場合があります。
ビルド プランについての重要な検討事項
開発環境では、単一のアンマネージド ソリューションのみを保持しているか?
マネージド ソリューションは、開発以外のすべての環境で使用されているか?
アクセス制限またはその他のメカニズムを使用して、変更が開発環境のみで行われるようにしているか?
すべてのコンポーネントがソリューションに対応しているとは限りません。また、ソリューションに対応してしないコンポーネント (たとえば、Power BI ビジュアル化) を処理するための計画が必要です。
ソリューション パッケージャー
アンマネージド ソリューションを開発環境から取得して、ソース管理リポジトリに格納する準備には、ソリューション パッケージャーを使用する必要があります。 ソリューション パッケージャーは、単一のソリューション ファイルを取得し、各ソリューション コンポーネントを表す個別のファイルに分割します。 このプロセスは「ソリューションのアンパック」と呼ばれます。 ソリューション パッケージャーからのアウトプットは、ソース管理リポジトリにチェックインされます。 このチェックインされたバージョンが、プロジェクトの信頼できるソースになります。
ソリューション パッケージャーでは、フォルダーをソース管理からパッケージ化し、単一のソリューション ファイルを再作成することもできます。 このようにして、ソース管理にチェックインされたファイルを使用し、他の環境にインポートするソリューションを作成することができます。
ソリューション パッケージャーについての重要な検討事項
ソリューション パッケージャーとソース管理リポジトリが計画されているか?
ソリューションは、ソース管理リポジトリから構築したテストおよび実稼働環境に展開されているか?
ソリューション チェッカー
Power Automate および Power Apps は Dynamics 365 の展開をカスタマイズするために使用され、独自のインライン アプリ チェッカーを備えているため、リアルタイムの問題解決に役立ちます。 ただし、ソリューション チェッカーは、ソリューション全体を確認して、静的分析を行い、見つかった問題の詳細な一覧を生成することができます。 (詳細については、ソリューション チェッカーを使用して、Power Apps のモデル駆動型アプリを検証するを参照してください。)
ソリューション チェッカーは、開発環境で構築しているアンマネージド ソリューションで定期的に実行する必要があります。 ソリューション チェッカーを使用すると Power Apps および Power Automate フローに加えて、開発者が作成するプラグインのようなコード資産も分析することができます。 プロジェクト チームは、Maker Portal でソリューションを選択して、手動でソリューション チェッカーを実行できます。
ソリューション チェッカーは、PowerShell または Azure DevOps パイプライン タスクを使用して、ビルド プロセスの一部として実行するように自動化することもできます。 ソリューション チェッカーの実行を自動化することで、ソリューション チェッカーの実行はビルド プロセスの不可欠な要素となり、多数のエラーが発生している場合はビルドを停止するように設定することもできます。 単に、ソリューション チェッカーを実行するだけではチームの成功を保証することはできません。特定された問題を定期的に評価および解決するための計画も用意する必要があります。
ソリューション チェッカーについての重要な検討事項
ビルド プロセスの一部として、ソリューション チェッカーを実行するための計画があるか?
ソリューション チェッカーの結果を定期的に確認するプロセスは組み込まれているか?
ソリューション チェッカーはビルドの自動化に統合されており、手動操作を必要とせずに実行できるか?
展開の自動化
ビルド計画の重要な部分として、プロセスを繰り返し実行するために、どのような自動化を使用できるかを検討する必要があります。 ビルド プロセスの自動化に使用可能な多数のツールが、Microsoft とそのコミュニティから提供されています。 Azure DevOps および Microsoft Power Platform タスクは、ソリューションの管理と展開タスクの自動化に使用できる 1 つのオプションです。
たとえば、チームは Azure DevOps パイプラインを作成して、毎日 7:00 PM に開発環境から抽出して git リポジトリにチェックインすることができます。 チームが朝出勤した時に、同じパイプラインを使用してソリューション チェッカーを実行して、前日の夜のビルドで問題が見つかったかどうかをすぐに確認できます。
このパイプラインは、ソリューションをクリーンなビルド環境にインポートして、その日の開発で意図せず導入された依存関係を検出することもできます。 これにより、ソース管理にチェックインされた内容が、他の環境へ展開するためのクリーンなバージョンであることを確保できます。 パイプラインは、テストの自動化に使用して、手順の一部とすることもできます。
Azure パイプラインは、テストや実稼働などの上流の環境に展開するためにリリース パイプラインで使用される、マネージド ソリューションの成果物を生成するためにも使用されます。 テストに使用されたのと同じソリューションの成果物が実稼働に使用されることになります。 こうすることで、実稼働環境へ向けた一連の環境を通じたプロセスの中で、大きな問題が起きないようにすることができます。 また、Azure パイプラインを使用して、開発者のコード資産を作成し、開発者のローカル ワークステーションにビルドされないようにすることもできます。
展開を自動化するもう 1 つのオプションは GitHub Actions です。
展開の自動化についての重要な検討事項
Azure DevOps または別の自動化ツールが、ビルド プロセスを自動化するために使用されているか? または、チームは手動での作業に依存しているか?
ソリューション チェッカーは自動化されたパイプラインの一部として統合されているか?
すべての開発者コード資産は、個々の開発者のローカル端末ではなく、ビルド プロセスによって作成されているか?
バージョン管理
検討すべきビルド計画のもう 1 つの要素として、複数の有効なバージョンを管理するための戦略が挙げられます。 既定では、変更は開発環境からテスト環境、さらに実稼働環境に展開され、それが変更の単一の作業ストリームとなります。 実稼働環境で問題が特定された場合は、その問題を開発環境で修正し、一連の環境を通じて実稼働環境に再度展開することができます。 このような単一の作業ストリームは、新しい開発が行われていない場合に正しく機能します。
開発チームが開発環境でバージョン 2 へ既に移行しており、問題が発生した実稼働環境でその問題を修正した場合、バージョン 2 の作業も実稼働環境に反映される可能性があり、混乱が起きます。 理想的なアクションは、既に実稼働にあるものだけを表す別の作業ストリームの開発環境で変更を行い、反映するのは修正のみに留め、バージョン 2 での変更が反映されないようにすることです。 そのためには、プロジェクトチームが事前に計画を立て、複数の有効なバージョンを管理するための戦略を策定する必要があります。 実稼働をサポートするための有効な開発ストリームとメンテナンス ストリームを用意するだけで、これを実現できる可能性があります。 より複雑なプロジェクトでは、複数の有効な開発ストリームを同時に使用することもできます。
有効な開発とメンテナンスの両方のストリームを同時に処理するには、通常、Dataverse 環境とソース管理の分岐を組み合わせて行います。 分岐を使用すると、プロジェクト資産のコピーを作成し、その分岐に関連付けられている環境での変更を隔離することができます。 1 つの分岐の変更は、別の分岐に統合することができます。 分岐戦略はできるだけシンプルなものにして、分岐の統合時に多くの競合を解決する必要がないようにします。
バージョン管理についての重要な検討事項
チームは、開発作業と実稼働環境でのバグ修正を別に管理する方法を検討しているか?
分岐戦略は複雑すぎていないか?
環境計画に合わせてソース管理の分岐が設定されているか?
バグ修正が確実にメインの開発環境に戻されるように、変更管理プロセスが用意されているか?
テスト戦略
テスト戦略には独自のワークショップがありますが、テスト プロセス自体は、全般的な ALM 戦略の一部として統合されている必要があります。 たとえば、品質保証チームが前日の作業のテストを毎日実行するように計画している場合は、前日の変更を反映して更新された環境で、品質保証チームがテストを開始できるようにする必要があります。
テストの自動化も検討する必要があり、テストの自動化はビルド プロセスの一部として統合できます。 これには、テスト環境の準備、テスト データの読み込み、およびテストの実行などが含まれます。 テストの結果を使用して、ビルド パイプラインの進行状況を確認し、エラーが発生した場合にビルド プロセスが続行されないようにすることができます。
モデル駆動型の Power Apps は、EasyRepro を使用してテストできます。 Power Apps キャンバス アプリは、Power Apps のテスト スタジオを使用してテストできます。 Test Studio は、アプリケーションにアクションを記録し、それを再生することでテストを自動化します。 Easy Repro はスクリプトを使用して、実行するテスト ステップを定義します。 記録後やスクリプトの生成後は、テストを Azure DevOps のパイプライン タスクとして含めることができます。
テストを行った後は、問題を特定して評価し、修正する必要があります。 全体的な ALM 戦略には、問題を文書化する方法と問題を優先順位付けする方法を含める必要があります。 バグが発生するたびに開発チームがすべての作業を止めてバグ修正に集中すると、全体的なプロセスが中断することになります。 通常はプロジェクトで変更管理プロセスを確立して、いつ修正を導入するかについて、各問題に優先順位を付けます。
テスト戦略についての重要な検討事項
ALM 戦略は、全体的なテスト方針に沿っているか?
特定された問題を追跡および管理するための変更管理プロセスが用意されているか?
少なくともいくつかのテストが、ビルドの自動化プロセスに統合されているか?
リリースと展開
ソリューションが構築できたら、テスト環境から実稼働環境に展開する必要があります。 一般的に、これは環境にソリューションを単にインポートするだけではありません。 まず、環境の開始状況を把握しておく必要があります。 たとえば、テストを行う際、スタンダードなテスト データでテストを毎回行うか、前回のテストが完了した時点からテストを行うか決定する必要があります。 各環境では、少なくとも最初の展開で構成する必要がある、何らかのコンフィギュレーション データ (環境変数など) が使用されている場合があります。 ほとんどの場合、テスト環境では、それらが実稼働サービスと通信していないことを確認する必要があります。 すべての顧客にテスト メールを送信することは、通常は歓迎されません。
リリースと展開についての重要な検討事項
データおよび接続しているサービスの観点から見て、各テスト環境がどのようなものであるべきか検討されているか?
環境ごとにソリューションをカスタマイズするために、必要なソリューション環境変数が作成されているか?
参照データ
ほとんどのソリューションでは、何らかの形式の参照データをさまざまな環境で管理する必要があります。 構成移行ツールは、1 つの環境からデータをエクスポートして他の環境にインポートする場合に役立つツールです。 構成移行ツールは、フィールドとリレーションシップを含む、エクスポートするデータのスキーマを定義することによって機能します。 エクスポートを実行すると、エクスポートされたすべてのデータを含む zip ファイルが作成されます。 また、構成移行ツールは、データ ファイルを Package Deployer ツールで使用できる環境にデータをインポートすることもできます。 このツールでは、各エンティティに対して定義されている一意の条件をフィールドの組み合わせに基づいて使用することにより、重複を回避することができます。 一致するレコードが見つかった場合、レコードは更新されます。それ以外の場合は、新しいレコードが作成されます。
参照データについての重要な検討事項
ソリューションの参照データを構成する要素が明確に理解されているか?
参照データのマスター コピーがどのようなもので、どこに保管され、どこで追跡されるかが明確になっているか?
環境間で参照データを管理する方法が計画されているか?
Package deployer
リリースと展開の管理に役立つもう 1 つのツールとして、Package Deployer ツールがあります。 Package Deployer を使用すると、複数のソリューション、構成移行ツールからのデータ、およびパッケージのインポート完了の前後に実行される開発者コード ロジックを含むパッケージを作成できます。 多くの点で、Package Deployer は、Microsoft Power Platform のインストール ウィザードと考えることができます。 Package Deployer を実行して、パッケージとデータを環境に手動でインポートすることができます。 Package Deployer は、PowerShell を使用した実行もサポートします。これにより、Azure パイプラインへの自動化と統合が可能になります。
Package Deployer についての重要な検討事項
- Package Deployer が展開戦略において役に立つかどうかチームは検討したか?
リリース パイプライン
このユニットの前半で、ビルド プロセスの自動化について説明しました。これは、展開用のソリューションを準備し、それをビルドの成果物として作成します。 また Azure パイプラインは、複数の環境に対するリリースを管理するためのリリース パイプラインの概念もサポートしています。 リリース パイプラインは、たとえば、マネージド ソリューション ファイルなどのビルドの成果物を、テスト環境または実稼働環境に展開することを目的としています。 リリース パイプラインには、各環境間の承認プロセスを組み込むことができます。 こうすることで、環境階層でリリースが進行する中で、複数の関係者からの実行承認を調整することができます。
リリース パイプラインについての重要な検討事項
Azure パイプラインまたは同様のツールが、構築したソリューションを環境間に展開するために使用されているか?
環境間の展開が進行する中で、それはどのように承認されるか?
実行モデル
ここでは、運用開始後の戦略について説明します。 ここでは、初期展開が完了しており、実稼働を開始し機能拡張のための作業を行っていることを前提としています。 ユーザーは構築されたものを使用して、変更を望む、または生産性を高めるために強化して欲しい機能を特定します。 プロジェクト チームは、これらの変更要求を取り込むツール、または、変更の評価、優先順位付け、および分類を行う方法を用意しておく必要があります。
たとえば、これらの変更は、クリティカル、マイナー、およびメジャーという3つのカテゴリに分類することができます。
継続的な変化の管理について考えるときは、少なくとも次の 3 タイプの変化を処理するためのプロセスを用意しておく必要があります。 たとえば、ユーザーが作業を完了することを阻害しているクリティカルなものについては、すぐに変更を行う必要があります。 通常このような問題は、週単位の更新を待つことはできないため、計画されている更新や展開を待たずに運用環境を更新できるような手法を用意しておく必要があります。 このような重大な問題に対応するプロセスを用意し、問題を解決するために運用環境へ変更を加える必要がないようにしておきます。
運用開始後の戦略についての重要な検討事項
ソース管理の分岐や環境戦略は、重要な修正をすぐに反映できるような仕組みになっているか?
運用開始前に得た問題のバックログを、メンテナンスや機能強化サイクルに反映する計画はあるか?
稼働中のアプリケーションで特定された問題を追跡し、優先順位を付けるための変更管理が用意されているか?
重要な修正を、正常なリリース プロセスに速やかに反映するためのプロセスが用意されているか?
Microsoft の更新サイクル
問題の改善または修正のためにチームが行う更新と同様に、Microsoft は Microsoft Power Platform および Dynamics 365 アプリケーションについて修正を行います。 通常 Microsoft は、ユーザー エクスペリエンスを中断することのないように更新プログラムを週に 1 回リリースします。 これらの更新は、環境への影響を最小限に抑えるために、安全な展開手法を使用してリリースされます。 これらの更新プログラムをいつ運用環境に適用するかは、管理者ツールを介して制御できます。
ほとんどの Dataverse および Dynamics 365アプリケーション では、修正は地域ごとにリリースされます。 環境に悪影響が及ばないようにするため、これらを検証するための 1 つの方法として、自分の環境の前に更新プログラムを反映する地域内の環境でテストし、自動テストを実行して問題を特定する方法があります。 それが実行できない場合でも、重要な機能に対して自動テストを毎週実行して、カスタマイズに悪影響が及んでいないことを確認できます。
現時点では、Microsoft は 1 年に 2 回 (4 月と 10 月)、より重要な更新プログラムをリリースします。これらの更新は、既存アプリケーションのユーザー エクスペリエンスに影響を与える可能性があります。 これらの更新は事前に計画され、予定されている変更を詳述したリリース計画が公開されます。 これは実際の更新の数ヶ月前に自動的に行われます。
自動更新プロセスの一部として、変更が自動的にすべての環境に適用されるまで、管理者は事前に環境の変更を手動で有効にすることができます。 こうすることで、運用環境ではないサンドボックス環境に運用環境をコピーし、変更を検証してから運用環境に展開することができます。 テストが成功したら、自動更新を待機する代わりに、独自のスケジュールで変更を選択できるようになります。
更新サイクルについての重要な検討事項
チームは、週単位のテストを行う必要があるかどうかを評価し、テスト計画を策定しているか?
顧客は更新プロセスを理解しており、年に 2 回の更新を事前に検証する準備をしているか?
キャパシティ管理
キャパシティ管理は、展開前の、またプロジェクトの実稼働後の使用管理で重要です。 キャパシティ管理は、単なるストレージ管理ではありませんが、ストレージは重要な要素の 1 つです。 もう 1 つの重要なキャパシティ管理は API 要求で、ライセンス割り当てが十分であること、また必要に応じて追加のアドオン API 要求に対応していることが必要です。 AI Builder や Power Virtual Agents をはじめとする他の製品やアドオンには、キャパシティ管理における全体的な作業を支援する機能もあります。
ストレージ容量の観点から見ると、Dataverse のキャパシティは、データベース、ログ、およびファイル キャパシティに分類されます。 これらは、それぞれ実際の使用状況に応じて個別に追跡され、ストレージを追加することができます。 テナントに新しい環境を作成するには、少なくとも 1 GBのデータベース容量を確保する必要があります。 複数の環境を含む ALM 戦略を作成する場合は、これは重要な検討事項です。 組織の ALM 戦略に一時的な環境が含まれている場合は、実際に使用されている場合にのみキャパシティを考慮します。 ただし、自動化されたプロセスを使用して作成するには、オートメーションの実行時に容量が確保されている必要があります。容量が確保されていない場合、自動化プロセスは失敗します。
データベースの容量については、稼働開始時に Dataverse に移行するデータに基づいて初期キャパシティを見積もりもる必要があります。 これには、実稼働以外の環境に存在する可能性があるデータも含まれます。 このプロセスの最初の重要なステップとして、エンティティごとに存在するレコードの数を把握します。 データの一部を移行できるようになると、Dataverse に読み込むサンプルに基づいて、読み込む予定のデータの全サイズを推定することによって、ある程度のインサイトを得ることができます。 移行するデータを完全に読み込むことができるようになると、その環境のサイズ情報を取得できるようになります。 Microsoft Power Platform 管理センターには、上位エンティティのストレージ使用率を調べるためのツールが用意されています。 初期容量に加えて、実際の環境でソリューションを実行するにつれて継続的に増加する容量について考慮することも重要です。 主要なエンティティについては、成長率を把握することによって、継続的に必要な容量を決定することができます。
ファイル容量の使用量は、レコード上で添付ファイルと画像ファイルのデータ型をどの程度使用しているかによって異なります。 ファイル容量は、1 つ以上の Insights アプリケーションがインストールされている場合にも使用されます。 ストレージの見積もりはデータベースの容量と似ており、レコードの数と平均ファイルサイズを把握しておくことが重要です。
ログの使用量は、監査とプラグインの追跡機能を使用するかどうかによって異なります。 監査は一定の容量を消費しますが、有効にすることが重要な機能です。 監査は、環境、エンティティ、およびフィールド レベルで制御され、適切な場所で有効にする必要があります。 変更を行ったユーザー、行われた変更、システムの問題のトラブルシューティングに関する情報を得ることができるため、監査は、ビジネス シナリオに役立ちます。 ビジネス ニーズを満たす場合は、保持期間を設定できる機能を利用します。
使用されている容量は、Microsoft Power Platform 管理センターで確認できます。 詳細については、Dataverse 分析 を参照してください。
キャパシティについての重要な検討事項
チームは、エンティティ別のレコード量をよく理解しているか?
初期稼働後に容量を監視するための計画が用意されており、十分な容量をプロビジョニングするための準備が整っているか?
API 要求のキャパシティ管理
API 要求には、コネクタからのすべての API 要求、Power Automateの各ステップのアクション、およびすべての Dataverse APIの使用が含まれます。 これに含まれるすべての項目のリストは、要求の制限と割り当て に掲載されています。 Power Apps、Power Automate、および Dynamics 365 の各ライセンスによって、24 時間ごとに API 要求が割り当てられます。 一般的に、ライセンス割り当てには、ライセンスを所有しているアプリケーションの通常の使用に関する多数の API 要求が含まれています。 割り当てが定期的に超過する場合は、アドオン ライセンスを使用して追加の API 要求を購入できます。 超過の最も一般的な原因は、一括処理を行う統合またはカスタム ロジックです。 多くの場合、これらは、API 要求を超過しないように処理を効率化して調整できます。 ソリューション アーキテクトは、この種のプロセスについて考慮して、可能な限り API の使用を最適化する必要があります。
API 要求の割り当て追跡に加えて、Dataverse ではサービス保護制限も実装されます。 これらは、サービスを使用するすべてのユーザーに、一貫した可用性とパフォーマンスを保証するように設計されています。 繰り返しますが、通常の使用ではサービス保護は開始されません。 ただし、大規模な統合では、サービス保護のトリガーによってエラーが発生する場合があります。 サービス保護制限は、スライディング ウィンドウを使用して 5 分ごとに評価されます。 使用率は、ユーザーによって送信された要求の数、要求の実行時間の組み合わせ、ユーザーによる同時要求によって評価されます。
サービスの保護制限は、追加のライセンス割り当てを購入することによって上書きすることはできません。適切な再試行ロジックを使用して、アプリケーションで処理する必要があります。 サービス保護の制限および再試行の処理方法については、サービス保護の API 制限 を参照してください。
API 要求についての重要な検討事項
チームは、API 要求で問題の原因となる可能性のあるホット スポットを特定しているか?
すべての統合または一括 API 作業に再試行ロジックが追加されているか?
API の使用状況を監視し、必要に応じて容量を調整するための計画が準備されているか?