ソリューション管理を自動化する

  • 8 分

このモジュールでは、アプリの部分を追跡し、複数の場所間でそれらを手動で移動するのにソリューションが非常に便利であることを既に学習しました。 ここでは、自動化によって、アプリケーション ライフサイクル管理 (ALM) と呼ばれるものを通じてアプリ管理をさらに強くする方法を詳しく説明します。 ALM は、アプリの作成だけでなく、ルール (要件など) の設定、開発、円滑な実行管理など、すべてに関することを対象とします。 ソリューションは、ALM 戦略において、Azure DevOps または GitHub などの役に立つその他のツールに加えて、キー プレイヤーのような役割を果たすものです。

通常、プロジェクトのソリューション アーキテクトは ALM 計画をマップし、DevOps に関するスキルを持つ担当者がその自動化を設定します。 チーム メンバーとして、選択したツールを使用してタスクを管理し、ソリューションを使用してアプリとフローの変更を監視することで、このプロセスに関与し続けるという職務があります。 その職務が終われば、ALM 自動化が後を引き継ぎます。 開発からテスト、実稼働に至るまで、変更を自動的に移行する一連のアクションが開始されます。 すべての手順を確実に追跡するために、それぞれの手順に対していくつかの承認が必要な場合があります。アプリケーション ライフサイクルを、計画、作成、テスト、展開、実行、監視、および発見した情報を基にした学習を含む、アプリ開発の終わりのないサイクルとして考えてみましょう。

アプリケーション ライフサイクル開発プロセスの図。

すべてのアクションを手動で行うことができますが、自動化を使用すると、実行のたびに一貫性が保たれます。 これらのアクションは、手動アクションの実行者が病欠した場合にも実行されます。 Azure DevOps や GitHub といった DevOps フォーカスのツールでは、自動化を実現しながら、作業項目の追跡やソース管理を行うこともできます。

ソース管理とソリューション

ソース管理は、Azure DevOps や GitHub などのツールに見られる、プロジェクトのすべての段階に対する高機能のバージョン トラッカーのようなものです。 Power App を使用している場合に変更を加えたとします。 変更のたびに、プロジェクトの新しいバージョンを作成するようなものです。 また、「作業項目」を使用して、行った変更をメモし、これらのメモをバージョンにリンクできます。 これにより、チームで変更された時間を記録し、問題が発生した変更を元に戻すことができます。 そのため、チームが新しいバージョンの作成に忙しくしているときでも、現在のバージョンを使用することができます。

ソース管理は、プロジェクトの最終的な信頼できるソースであるため、アプリケーション ライフサイクル管理 (ALM) では極めて重要です。 開発環境がクラッシュした場合でも、心配ありません。 ソース管理に格納されている情報を使用して、開発環境を再構築できます。 ある意味、ソース管理では開発環境の置換が可能になります。 テストや実稼働の環境にデータを送信すると、実際には、開発領域からランダムな情報ではなく、ソース管理の情報を送信します。

ただし、これには裏があります。環境からソリューションをエクスポートするというのは、すべてを 1 つの大きなファイルに梱包するようなものです。 そのファイルをソース管理に追加しただけでは、何かが変更されたということが示されるだけで、各部分で何が変更されたのかは正確には示されません。 そのため、これをより便利するために、ステップを自動化プロセスに追加します。 このステップでは、開発領域からソリューションを取り出し、(スーツケースの荷解きをするように) そのソリューションを展開して、各部分に別々のファイルを作成します。 これらの個別のファイルが、ソース管理に追加されます。 これにより、すべての変更を詳細に追跡できます。 さらに、すべての変更がソース管理に従う複数の開発環境を使用することで、1 つの変更が別の変更に影響を与える可能性を減らすことができます。

DevOps ツールによる自動化

自動化は手動プロセスに一貫性をもたらすため、重要です。 作成した自動化は、オンデマンドで、スケジュールに基づいて、またはチェックイン イベントに基づいて実行できます。 自動化の実装に使用できるツールにはさまざまなものがありますが、Azure Pipelines と GitHub Actions にはどちらも、Microsoft による Power Platform タスクおよびアクションのサポートが事前に組み込まれています。

何を自動化できるか?

自動化ではタスクやアクションが実行されるだけであるため、自動化できる内容にはさまざまなものがあります。 これは Power Automate フローに似ていますが、アプリの管理や展開の作業にさらに特化されたものと考えることができます。 Power Platform プロジェクトで使用されるいくつかの一般的な自動化を次に示します。

  • 新しい開発環境の作成とソース管理からのソリューションのインストール

  • 開発環境からの変更の取り込みとソース管理の更新

  • 品質上の問題を特定するためのソリューション チェッカーの実行

  • 環境のプロビジョニングおよびプロビジョニング解除

  • Power Apps Test Studio のテストを含む自動テストの実行

  • 下流環境に展開するための展開用のソース管理からの構築管理ソリューション

  • テストや実稼働などの下流環境への展開

自動化は各プロジェクト要件に合わせてカスタマイズされますが、通常は開始、構築、およびリリースの自動化が含まれます。

展開の開始フェーズ、構築フェーズ、およびリリース フェーズを示す図。

自動化を使用するプロジェクトで作業する場合は、展開されている全体的なプロセスを確認してください。 一般的に、自動化の構築は、DevOps にフォーカスしたリソースで実行されます。

Power Platform Build Tools

Microsoft Power Platform Build Tools は、Microsoft Power Platform でアプリを管理するために設計されたツール ボックスのようなものです。 これらのツールは役立つアクションで構成され、特別なツールの選択や複雑なスクリプトの記述の手間を省き、アプリのライフサイクル中でさまざまなタスクを処理できるようになります。 アプリを新しい環境に持ち込むなど、特定のことを実行するために 1 つ 1 つ使用できます。また、それらをまとめて順序よく組み合わせて操作を自動的に実行することもできます。

ここで、作業を自動化するために Azure DevOps または GitHub Actions のどちらを使用しているかによって、用語が少し違ってきます。 Azure DevOps では、これらのアクションを「タスク」と呼ぶのに対し、GitHub Actions では「アクション」と呼びます。

次に、最も一般的な操作をいくつか紹介します。

  • Power Platform チェッカー - ソリューションの静的分析を実行し、自動化に追加することで問題を早期に見つけます。

  • ソリューションのエクスポート - 管理ソリューション、管理されていないソリューション、または両方のソリューションを環境からエクスポートします。

  • ソリューションのインポート - ソリューションを環境にインポートします。

  • ソリューションのアンパック - ソース管理にチェックインできるように、圧縮されたソリューション ファイルを各コンポーネントの個別のファイルに分割します。

  • ソリューションのパック - ソース管理に表されるソリューションを、別の環境にインポート可能な solution.zip ファイルにパックします。

  • ソリューション バージョンの設定 - 自動化でバージョン番号を更新することにより、一貫したバージョン管理戦略を実装できます。

  • 環境の作成、削除、およびコピー - 自動化の一部として、環境管理の自動化を実行できます。

自動化が必要な理由 これは、アプリ作成プロセスの一貫性と信頼性を確保するスマートな方法です。 チームでまだすべてを手動で行っている場合は、一部の機能を自動化してみることをお勧めします。 これにより、作業の一貫性が向上するだけでなく、よりよいアプリを作成し、より高品質にアプリを展開することもできます。