Azure DevOps での ALM

完了

ソリューション アーキテクトは、開発から実稼働まで変更内容がどのようにプロモーションされるかのプロセスを定義する作業を主導します。 この作業には、ステージ (開発 > テスト > 実稼働など) の数の定義や、手動か自動かにかかわらずプロモーションを実行するプロセスの定義が含まれます。

Microsoft では、継続的インテグレーション (CI) と継続的配置 (CD) を使用することで、Microsoft Azure DevOps によってこのプロセスをサポートするツールを構築しています。

このセクションでは、Azure DevOps の概要と、展開を自動化するために Microsoft Power Platform で DevOps を使用する方法について説明します。

Azure DevOps

Azure DevOps には、作業の計画、コード開発でのコラボレーション、アプリケーションの構築と展開を行うためのサポート チーム向け開発者サービスが用意されています。

Azure DevOps でのコラボレーションを示す図。

Azure DevOps には、アプリケーションの開発に役立つ多くの機能が用意されています。

  • Azure Boards - チーム間での作業の計画、追跡、および説明を行います。
  • Azure Pipelines - 継続的インテグレーションおよび継続的配置 (CI/CD) のビルドとリリースを自動化するために使用します。
  • Azure Repos - 変更を保存および追跡するソース管理です。
  • Azure Test Plans - スクリプト化されたテストの計画、実装、および追跡を行います。
  • Azure Artifacts - ビルド パイプラインによって構築されたソリューションを公開します。

パイプライン

Power Apps は、Azure Pipelines を使用して、Power Apps に関連する一般的なビルドおよび展開タスクを自動化するツールを構築します。

ビルド パイプラインは、次の作業に使用できます。

  • 開発環境を作成する。
  • 開発からソース管理に変更をコミットする。
  • ソリューション チェッカー ツールを有効にする。
  • 自動化されたテストを実行する。
  • ソース管理から出力ソリューションを構築する (マネージドとアンマネージドなど)。

リリース パイプラインは、次の作業に使用できます。

  • ビルド パイプラインのソリューションを取得し、1 つ以上のテスト環境または実稼働環境に展開する。
  • リリース プロセスの一部として自動化されたテストを実行する。
  • 次の環境に進む前に、承認を一時停止する。

Microsoft Power Platform Build Tools のタスクは、ビルド パイプラインとリリース パイプラインを構成する場合に使用できる他に Azure DevOps タスクと一緒に使用できます。 通常、チームが確立するパイプラインには、開始、開発からのエクスポート、ビルド、リリースなどがあります。

Azure DevOps と Microsoft Power Platform の図。

展開の方法

リリース パイプラインからソリューションを展開する場合は、リリースを手動でプッシュするか自動でプッシュするかを決める必要があります。 リリース パイプラインの実行は、Azure DevOps ユーザーが手動でプッシュしたり、スケジュールに基づいて自動で実行したり、プル要求によってトリガーしたりするように構成できます。 リリース パイプラインで継続的デプロイを有効にすると、ソリューションの最新のビルドが使用可能になったらすぐに他の環境にプッシュすることができます。

ソリューションの迅速な障害対応のためには、できるだけ早く手動でトリガーして上流の環境で最新のビルドを適用するのが望ましい方法ですが、ソリューションの更新を定期的に行う場合は、スケジュールやプル要求によってトリガーするとより効率的です。

リリース パイプラインの継続的デプロイとプル要求のトリガーのスクリーンショット。

リリース パイプラインのスケジュールされたリリースのトリガーのスクリーンショット。

以下に例を示します。

Contoso Bank には、本番稼働までにさまざまなテストのステージを経る必要がある複雑な Power Platform ソリューションを開発しているチームがあります。 この開発チームは、その開発プロジェクトにアジャイル手法を使用しており、定期的なビルドとリリースのサイクルを適用しています。 そのため、Contoso Bank の開発チームは、リリース パイプラインでスケジュールされたトリガーを使用しています。スケジュールは、事前に定義したスプリントのサイクルに基づいています。 これは、リリースをプッシュする自動での方法です。

一方で、UAT 環境で大きなバグが見つかった場合は、開発者は新しいビルドでバグにパッチを適用し、リリース パイプラインを手動でトリガーして、UAT 環境でのテストをできるだけ早く続けることができます。

Contoso Bank では、リリース サイクルに厳格なタイムラインがない小規模なプロジェクトも行っています。 その場合、新しいビルドの作成には定期的なスケジュールがないため、リリース パイプラインでは手動でのトリガーの使用が望ましくなります。

DevOps を使用した手動から自動の ALM への移行や適切な展開方法のベスト プラクティスの詳細については、DevOps を使用した手動から自動の ALM への移行を参照してください。

その他の自動化ツール

Azure DevOps を使用せずにデプロイを自動化する場合は、以下を使用できます。

  • Dataverse と管理者 API を使用すると、サポートされている任意の言語から自動化できます。
  • PowerShell は、より細かい制御を行うためにビルド タスクの代わりに使用できます。
  • Power Automate をプラットフォーム管理者コネクタと一緒に使用すると、展開を自動化できます。
  • GitHub アクションは、現在プレビューの段階です。