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

8 分

このモジュールでは、アプリコンポーネントを追跡し、ある環境から別の環境に手動で転送するために、ソリューションをどのように使用できるかについて学習しました。このトピックでは、これらのアクションの一部を自動化することで、プロジェクトに対してより信頼性の高いアプリケーションライフサイクル管理 (ALM) をどのようにして実装できるかを見ていきます。 ALM には、アプリのビルドだけでなく、ガバナンス (要件管理など)、開発、およびメンテナンスが含まれます。 ALM 戦略では、Azure DevOps や GitHub などのツールと共に、ソリューションが重要な役割を果たします。

プロジェクトでは、通常、ソリューションアーキテクトが ALM 戦略の概要を示し、DevOps フォーカスのリソースによって自動化が実装されます。チームメンバーは、選択したツールで作業項目を管理し、ソリューションを使用してアプリやフローに加えた変更を追跡することで、ALM プロセスに参加します。その後、ソリューションは ALM 自動プロセスに配置されます。これにより、構築プロセスとリリースプロセスが開始されて、変更内容が自動的に開発からテストへと移行し、適切な承認を得て実稼働へと移行します。アプリケーションライフサイクルは、循環型のアプリ開発プロセスであり、次の各領域: 計画と追跡、開発、構築とテスト、展開、操作、監視、および検出からの学習が含まれます。

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

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

ソース管理は、ソリューションコンポーネントのバージョンを追跡するための Azure DevOps および GitHub の機能です。たとえば、Power App を変更し、ソリューションがエクスポートされてソース管理にチェックインされると、新しいバージョンが作成されます。作業項目を使用して変更を追跡する場合は、それがソース管理にチェックインされるときにバージョンに関連付けることができます。これにより、プロジェクトチームは、変更がいつ行われたかを追跡し、必要に応じて問題のある変更をロールバックすることができます。また、ソース管理を使用すると、開発チームが新しいバージョンに取り組むのと同時に、現在の実稼働バージョンを保守することができます。

ソース管理は、ソリューションの信頼できるソースとなるので、ALM の重要な部分です。つまり、開発環境が破損した場合、ソース管理に移動して新しい開発環境を再構築するため、問題とはなりません。ソース管理では、開発環境を破棄することが可能になります。テスト環境と実稼働環境へのすべての展開は、追跡されていない開発環境ではなく、ソース管理バージョンから行われます。

環境からエクスポートされたソリューションファイルは、技術的にはソース管理にチェックインできますが、これは個々のコンポーネントの変更を追跡する効果的な方法ではありません。ソリューションファイルは、単一の圧縮バイナリファイルです。ソリューションファイルをソース管理にチェックインすると、ファイルが変更されたことを通知できるだけで、各コンポーネント内で変更された情報を簡単に列挙することはできません。これを改善するために、自動化にステップが追加されます。これにより、開発環境からソリューションが取得されてソース管理に組み込まれ、プロセス内で圧縮ファイルがアンパックされます。圧縮ソリューションファイルをアンパックすることで、コンポーネントごとに個別のファイル (場合によっては、コンポーネントごとに複数のファイル) が作成されます。これらのファイルは、ソース管理にチェックインされて、変更を細かい粒度で追跡できます。コンポーネントでこれらの個々のファイルを使用することで、複数の開発環境を整備することが可能になります。これらの環境では、変更がソース管理で追跡され、変更間の競合が最小限に抑えられます。

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 は、Power Platform 固有のタスクまたはアクションのコレクションです。これらのツールを使用すると、カスタムツールやスクリプトを手動でダウンロードして、Microsoft Power Platform でビルドされたアプリのアプリケーションライフサイクルを管理する必要がなくなります。これらは、タスク (下流環境へのソリューションのインポートなど) を実行するために個別に使用するか、シナリオを調整するためにパイプライン内で組み合わせて使用することができます。

厳密な用語は、自動化の構築に Azure DevOps と GitHub Actions のどちらを使用するかによって異なります。たとえば、Power Platform 固有の操作は、Azure DevOps ではタスクと呼ばれ、GitHub Actions ではアクションと呼ばれます。

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

Power Platform チェッカー - ソリューションの静的分析を実行し、自動化に追加することで問題を早期に見つけます。
ソリューションのエクスポート - マネージド、アンマネージド、または両方のソリューションを環境からエクスポートします。
ソリューションのインポート - ソリューションを環境にインポートします。
ソリューションのアンパック - ソース管理にチェックインできるように、圧縮されたソリューションファイルを各コンポーネントの個別のファイルに分割します。
ソリューションのパック - ソース管理に表されるソリューションを、別の環境にインポート可能な solution.zip ファイルにパックします。
ソリューションバージョンの設定 - 自動化でバージョン番号を更新することにより、一貫したバージョン管理戦略を実装できます。
環境の作成、削除、およびコピー - 自動化の一部として、環境管理の自動化を実行できます。

ソリューション管理を自動化すると、プロジェクトでアプリケーションライフサイクルの一貫性を向上させることができます。手動プロセスのみを使用してプロジェクトに取り組んでいる場合は、いくつかの基本的な自動化の実装を調査するようにチームに促してみてください。一貫性が向上するのに加え、より完全なアプリケーションライフサイクル管理方法を実装すると、作成および展開するアプリケーションの品質が向上します。

続行