ワークロード開発サプライ チェーンの設計に関する推奨事項
この Power Platform Well-Architected オペレーショナル エクセレンス チェックリストの推奨事項に適用されます:
| OE:06 | 予測可能で自動化されたパイプラインを通じて提案された変更を推進するワークロード サプライ チェーンを構築します。 パイプラインは、環境全体でこれらの変更をテストし、促進します。 サプライ チェーン を最適化して、ワークロードの信頼性、セキュリティ、コスト効率、パフォーマンスを高めます。 |
|---|
このガイドでは、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに基づく、ワークロード開発サプライ チェーンの設計に関する推奨事項について説明します。 クラウド ワークロードでは、サプライ チェーンは、環境全体の構成とワークロードの変更に影響を与えるために使用する標準化されたツールとプロセスのスイートです。 サプライ チェーンを開発して、ワークロードを維持するための予測可能で標準化された方法を確保します。 CI/CD パイプラインはサプライ チェーンの現れですが、サプライ チェーンは 1 つである必要があります。 同じプロセスを 追従する し、同じツールを使用するパイプラインが複数ある場合があります。
ワークロードの変更を適切に管理しない場合に発生する可能性のある損害からワークロードを保護するために、サプライ チェーンを組み込みます。 予期しない動作が発生するリスクを回避するために、ワークロードの状態を常に把握しておいてください。 問題発生時に、説明されていない変更を再度追跡するために貴重な時間を費やす必要がある場合、このリスクはさらに増大します。 これらのリスクを最小限に抑えるには、サプライ チェーンを定義するプロセスとツールを標準化し、ワークロード チームがそれらの使用に全面的に取り組むようにします。
主要な設計戦略
次の推奨事項は、サプライ チェーンの中核となる考え方を定義するのに役立ちます。
サプライ チェーンのプロセスとツールにより、提案されたワークロードの変更を行います。 自動化されたテンプレート ベースの展開の厳格なポリシーを適用します。 この方法により、すべての環境にわたるワークロードの構成が標準化され、明確に定義され、厳密に制御されるようになります。 コード プロモーション チェーンにある環境では、手動プロセスやユーザーとの対話を使用して更新を実行しないでください。 定義した展開プラクティスに従い、パイプライン経由で環境へのすべての変更を組み込みます。 このポリシーを適用するために、アクセスをデフォルトとして読み取り専用に制限し、書き込みアクセスを許可するアクセス承認ゲートを使用することを検討してください。
この考え方の重要な側面は、すべての変更が運用に展開されるまでは、提案された変更 であることです。 統合やスモーク テストなどの自動テストにより、サプライ チェーンが変更を自動的に拒否できるようにします。
すべての環境とパイプラインで、コード アセットとアーティファクトの 1 つのセットを使用します。 組織にとっての共通の問題点は、非運用環境が運用環境と異なる場合です。 運用環境と非運用環境を手動で構築すると、環境間で構成が一致しなくなる可能性があります。 この不一致によりテストが遅くなり、変更が運用システムに悪影響を与える可能性が高くなります。
組織構造をサプライチェーンとパイプラインの設計に反映します。 組織はチーム間でサイロ化されている可能性があります。 各チームは、サプライ チェーンの一部を管理する場合があります。 たとえば、多くの組織には、セキュリティとコンプライアンスの設定、または環境構成を管理するチームがあります。 これらのチームは、アプリケーションの開発、テスト、展開を管理する開発チームとは別のものです。 サプライ チェーンに関与するチームを組織する方法はたくさんあります。 サプライ チェーンは、すべてのチームがシームレスに連携することに依存しています。 すべてのチームが標準プロセスに従い、標準ツールを使用して、サプライ チェーンを可能な限り効率的にするようにします。
ワークロード ライフ サイクルの一部をアウトソーシングする場合、サプライ チェーン はサードパーティ ベンダーに依存する可能性があります。 これらのベンダーは、サプライ チェーン の成功にとって、社内リソースと同じくらい重要です。 使用するプロセスとツールについて、すべてのチーム間で相互合意があることを確認します。
展開方法を標準化します。 ワークロードに対して許容可能な運用ダウンタイムについて、製品の所有者と話し合ってください。 ダウンタイムがどの程度許容されるのか (許容される場合) に応じて、要件に適した展開方法を選択できます。 複雑さとリスクを軽減するために、メンテナンス期間中に展開を実行するのが理想的です。
総合的なテスト戦略を計画します。 システムの信頼性の基本原則は「シフトレフト」の原則です。 アプリケーションの開発と展開は、左から右に進む一連のステップとして表されるプロセスです。 テストをプロセスの最後までに限定すべきではありません。 可能な限り、テストを先頭または左側に移動します。 エラーは早期に発見すれば、修復コストが安くなります。 アプリケーションのライフサイクルの後半で修正するには、コストがかかったり、修正が不可能になったりする可能性があります。
可能であれば、一貫性を確保するために自動テストを使用します。 サプライ チェーンの設計に次の種類のテストを含めます:
ユニット テスト: ユニット テストは通常、継続的インテグレーション ルーチンの一部として実行されます。 単体テストは広範囲かつ迅速に行う必要があります。 コードの 100 パーセントをカバーするのが理想的です。 テンプレートやスクリプトを含む、すべてのコード アセットに単体テストを適用します。
スモーク テスト: スモーク テストは、ワークロードがテスト 環境 で立ち上げられ、期待どおりに実行されることを確認します。 スモーク テストでは、コンポーネントの相互運用性は検証されません。 スモーク テストでは、インフラストラクチャとアプリケーションの展開方法が機能していること、およびプロセス終了後にシステムが意図したとおりに応答することを検証します。
統合テスト: 統合テストでは、アプリケーション コンポーネントが個別に動作することを確認し、コンポーネントが適切に相互に対話できるかどうかを判断します。 大規模な統合テスト スイートを実行するには、かなりの時間がかかります。 そのため、シフトレフトの原則を取り入れ、ソフトウェア開発ライフサイクルの早い段階でテストを実行するのが最適です。 統合テストは、スモーク テストや単体テストでテストできないシナリオ用に用意してください。 必要に応じて、長時間実行されるテスト プロセスを定期的に実行できます。 定期的な間隔は、適切な妥協点を提供し、アプリケーション コンポーネント間の相互運用性の問題を、導入後遅くても 1 日以内に検出します。 一部のテスト シナリオでは、手動での実行が効果的です。 人間の対話性要素をテストに導入する必要がある場合は、手動テストを使用します。
受け入れテスト: コンテキストに応じて、受け入れテストを手動で実行できます。 部分的または完全に自動化することができます。 受け入れテストでは、ソフトウェア システムが要件仕様を満たしているかどうかを判断します。 このテストの主な目的は、システムがビジネス要件に準拠しているかどうかを評価し、システムがユーザーへの配信に必要な基準を満たしているかどうかを判断することです。
テストを通じてコードプロモーションプロセス全体に品質ゲートを実装します。 コードを、品質保証やテストなどの下位環境、およびステージングや運用などの上位環境に展開します。 展開が品質ゲートを通過するときに、変更が運用に移行する前に、品質目標を満たしていることを確認します。 ビジネス要件によって、品質ゲートの焦点が決まります。 また、基本的な Power Platform Well-Architectedの原則であるセキュリティ、信頼性、パフォーマンス効率も考慮してください。
また、承認ワークフローを品質ゲートに統合します。 適宜、承認ワークフローを明確に定義し、自動化します。 ゲートを効率的かつ安全に通過できるように、自動化に品質受け入れ基準を定義します。
Power Platform の促進
Power Platform のパイプラインは、ALM 自動化機能と継続的インテグレーションと継続的デリバリー (CI/CD) 機能をサービスに組み込むことで、Power Platform およびDynamics 365 の顧客向けにアプリケーション ライフサイクル管理 (ALM) を民主化することを目的としています。
Azure DevOps 用の Microsoft Power Platform を使用することで、Power Platform でビルドされたアプリに関連する一般的なビルド & デプロイ タスクを自動化することができます。
GitHub Actionsを使用すると、開発者は自動化されたソフトウェア開発ライフサイクル ワークフローを構築できます。 Power Platform Microsoft Power Platform の GitHub アクション を使用して、リポジトリにワークフローを作成して、アプリをビルド、テスト、パッケージ化、リリース、デプロイし、自動化を実行し、ボットやその他のコンポーネントを Power Platform 上で管理できます。
ALM Accelerator は、継続的インテグレーション/継続的配信プロセスを自動化するために設計された一連のアプリケーション、スクリプト、パイプラインで構成されるオープンソース ツールです。
Power Apps チェッカーの Web API は、カスタマイズに対して実行されたスタティック分析のチェックや Microsoft Dataverse プラットフォームへと拡張するメカニズムを提供します。
Microsoft Power Platform CLI (PAC CLI) は、ソリューションのインポートとエクスポート、およびソリューション ソース ファイルへのパックとアンパックをサポートするコマンド ライン ツールです。 Power Platform Power Platform PAC CLIは、 スタンドアロンのコマンドライン ツール として、または コードの拡張機能 Visual Studio として利用できます。
不変の infrastructure as code (IaC) の展開には、Terraform、Bicep、Azure Resource Manager を使用できます。 要件とチームのツールに対する習熟度に応じて、リソースの展開と管理にこれらのツールを 1 つ以上使用できます。
組織の整合性
クラウド導入フレームワークは、中央チームがワークロード ランディング ゾーンを提供するためのガイダンスを提供します。 ワークロード ランディング ゾーンは、ワークロードのカスタム サプライ チェーン がアプリケーションをデプロイする場所です。
詳細については、「 Azureランディング ゾーンとは何ですか? 」および「 Azureランディング ゾーンの設計原則」をご覧ください。