ALM における重要な検討事項

完了

ソリューション アーキテクトはプロジェクトのアプリケーション ライフサイクル管理 (ALM) について、戦略を定義する必要があります。 この作業は、ソリューションのガバナンスを組織で適切に確立するために役立つプロセスの 1 つです。

環境戦略

環境は、ビジネス データ、アプリ、フロー、接続、およびその他の資産を保存し管理するためのコンテナーです。組織のメンバーにリソースの使用を許可するアクセス許可と共に使用します。

環境は、役割やセキュリティ要件、対象ユーザーが異なるアプリを分離するためのコンテナーとして機能します。 環境の利用方法は、組織によって、あるいは構築しようとしているアプリによって異なります。たとえば次の方法があります。

• 1 つの環境にすべてのアプリを構築する。
• アプリをテスト バージョンと本稼働バージョンに分けて、それぞれに環境を作成する。
• 社内のチームや部署に対して環境を個別に作成し、それぞれのデータやアプリを専用の各環境に格納する。
• 世界の各支社に環境を分けて作成する。

環境およびその他のデータ セキュリティ層の構成方法について戦略的に検討することで、組織全体で開発の生産性が高まると同時に、リソースのセキュリティ保護や効率的な管理が可能になります。 環境のプロビジョニングとアクセス、および環境内のリソースを戦略的に管理することには、次のような重要な目的があります。

• データとアクセスのセキュリティを保護する。
• 既定の環境の使い方を正しく理解する。
• 環境を必要な数だけ正しく管理し、容量が余ったり不足したりしないようにする。
• アプリケーション ライフサイクル管理 (ALM) を促進する。
• リソースを論理的に分類して整理する。
• 実稼働中のアプリを専用の環境に配置して区別することで、その運用 (およびヘルプデスク) をサポートする。
• データを格納および送受信する場所を、パフォーマンスやコンプライアンスの観点から許容される地理的領域に限定する。
• 開発中のアプリケーションを分離する。

Microsoft Power Platform では、次の種類の環境を使用できます。

• サンドボックス - Dataverse の非運用環境はすべてサンドボックス環境です。 サンドボックスは実稼働環境から分離されているため、少ないリスクでアプリケーションの変更を安全に開発し、テストすることができます。
• 実稼働 - アプリやソフトウェアを、本来の目的のために配置して運用するための環境です。
• コミュニティ (開発者) - Power Apps コミュニティ プランのユーザーは、個人的な用途に限り、Power Apps プレミアムの機能、Dataverse、および Microsoft Power Automate を使用することができます。 つまり、この環境は主に学習目的で提供されています。 開発者環境はユーザーを 1 人だけ含む環境であり、アプリの実行や共有を行うことはできません。 コミュニティ プラン環境は、Azure DevOps パイプラインに参加できます。
• 既定 - 各テナントに対して既定の環境が 1 つずつ自動的に作成され、そのテナントのすべてのユーザーによって共有されます。 既定の環境は Microsoft 365 サービスで使用されます。
• 試用版 - 新しい機能を試したり、概念実証を行ったりするための試用環境です。 試用環境は、30 日後に自動的に削除されます。

重要

ソリューション アーキテクトは、用意する環境の数とそれぞれの目的、および環境間の依存関係について定義する必要があります。 ALM を正常に保つために、少なくともテスト環境は使用してから実稼働環境に展開する必要があります。 そうすれば、この環境でアプリをテストできるだけでなく、展開をテストすることもできます。

詳細については、「環境の概要」および「環境戦略を確立する」を参照してください。

ソリューション対応と非ソリューション対応のコードおよびコンポーネントについて

Microsoft Power Platform プロジェクトは、環境内のソリューション内部にパッケージ化できるコンポーネントと、ソリューションに追加できないコンポーネントで構成されます。 追加できないコンポーネントには、Azure に配置されたコンポーネント、構成データ、および Power BI レポートがあります。 ALM を計画する際には、非ソリューション対応コンポーネントを処理する方法について検討する必要があります。

ソリューション アーキテクトは、アプリケーション ライフサイクル管理をソリューションを使用して行うか、ソース コード管理を使用して行うかを判断する必要があります。 これまで、Microsoft Power Platform のプロジェクトの多くがソリューションを中心として管理されてきましたが、最近ではより多くのプロジェクトがソース管理を中心に管理されています。

環境を中心に管理する場合は、次のようなアプローチになります。

• 開発環境をマスター コピーとして、すべての変更が行われる。
• 変更が開発 > テスト > 実稼働の環境順に進められる。

ソース管理を中心に管理する場合は、次のようなアプローチになります。

• ソース管理がマスターとなる。
• 開発環境はソース管理から再作成される (このプロセスは自動化され繰り返し行われる)。
• 開発環境への変更がソース管理にチェック インされる。

ソース管理を中心とするアプローチでは、ソースのマスターを確実に所有し、開発環境を追跡中の任意のバージョンから再作成することが可能になります。 現在、Microsoft はソース管理を中心とした ALM を推奨しており、それをサポートするためのツールを構築しています。

注

実稼働環境以外のすべての環境は破棄されるべきです。つまり、開発環境とテスト環境を削除し、すべての作業を無駄にしないように環境を再作成できるのが理想的です。

ソース管理を中心とするアプローチを Azure DevOps に適用すると、パイプラインを構築およびリリースすることができます。 環境を中心とするアプローチの場合は、アプリの作成者や開発者に対してワークフローを定義する必要があります。 ソリューション アーキテクトは、誰がどのような方法で、開発から実稼働まで環境を移動しながらアプリの開発を進めるかを判断する必要があります。

また、各環境の構成方法を定義し、その作業を容易にするための方法についても検討する必要があります。

チーム作業

Microsoft Power Apps のプロジェクトは、主に次の 2 つの面で従来のアプリ開発とは異なります。

• プロジェクト チームのさまざまなメンバーが共同で作業してソリューションを作成する
• 開発手法

Power Apps は、プロの開発者にも市民開発者にもメリットの大きいプラットフォームです。 従来の開発環境では、プロの開発者以外は実際のアプリの作成に加わることができませんでした。 Power Apps であれば、これまでプロの開発者しか使えなかったような高度な機能を使用して、必要なアプリを誰でも構築することができます。 Power Apps では、コードを記述しなくても機能が充実したカスタムのビジネス アプリを構築できるため、メンバー全員で開発作業を行うことができます。

Power Apps には、アプリの使用可能バージョンをすばやく作成できるように、Power Apps WYSIWYG (表示されたものがそのまま出力される) 開発エクスペリエンスが用意されています。 開発プロセスの早い段階で実際のアプリの機能を体験することができ、新しく要件が追加された場合は、次回のバージョンで新しい機能を追加できます。

Microsoft Power Platform でのコンポーネントのカスタマイズおよび開発には、次のような問題があります。

• Microsoft Power Platform では、コンポーネントのバージョン管理はサポートされません (キャンバス アプリを除く)。
• 同じ Microsoft Power Platform コンポーネントを、複数のユーザーが同時に作業することはできません。
• モデル駆動型アプリには複数のコンポーネントが含まれ、それぞれにエディターが使用できるため、複数の作成者で作業を分割することができます。 しかし、キャンバス アプリにはエディターが 1 つしかないため、同時に 1 人のユーザーしか作業を行うことができません。 キャンバス コンポーネントを使用すると、複数の作成者が同じアプリに対して同時に作業を行うことができます。

ソリューション アーキテクトは、アプリに変更を加えて次の段階に進めるための、アプリ ビルダー ワークフローを作成する必要があります。 作成者間の矛盾を最小限に抑えるために、管理者はコミュニケーションや作業の割り当てをプロアクティブに行う必要があります。

作成者ごとに環境を個別に作成すると、環境を分離して追跡できるため、 衝突を最小限に抑えられますが、作業をマージしたり、矛盾を解決したりするために余分な手間がかかります。 その手間は、作成者間で環境を共有すれば省けますが、アプリ ビルダー間を分離することができず、変更を追跡するための詳細な情報が得られなくなります。

ソース管理

環境を中心としたアプローチを使用する場合でも、どのコードをソリューションのマスター コピーとするかを決めておく必要があります。

ソリューション対応の開発者コード資産 (プラグイン、PCF コード コンポーネント、フォーム スクリプト (TypeScript からトランスパイル) など) は、開発者のデスクトップではなく、ビルド環境で "ビルド" する必要があります。 その後、構築された資産を環境に展開して、そこからマスター ソリューションをエクスポートするか、ソリューションを構築してインストールする必要があります。

ツール

Microsoft では、Microsoft Power Platform での ALM に使用できるツールやアプリを多数ご用意しています。

• Microsoft Power Platform 管理センター - 管理者が環境を作成および管理するための統合型ポータルです。
• Power Apps build tools - Azure DevOps を使用して、Power Apps で繰り返し行われるビルドや展開の作業を自動化します。
• GitHub - 多くのユーザーを持つバージョン管理システムです。
• Configuration Migration Tool - 構成データや参照データを環境間で移動できます。
• Package Deployer - 資産のパッケージを Dataverse インスタンスに展開できます。 パッケージは、ソリューション ファイル、フラット ファイル、カスタム コード、HTML ファイル、およびデータで構成されます。
• ソリューション パッケージャー - 圧縮されたソリューション ファイルを複数の XML ファイルやその他のファイルに解凍し、ソース管理システムで簡単に管理するためのツールです。
• Microsoft Power Apps CLI - 開発者がコード コンポーネントを作成するための、シンプルなコマンド ライン インターフェイスです。
• パッケージ展開 PowerShell モジュール - パッケージを Dataverse 環境に展開するために使用します。
• Power Apps Checker PowerShell モジュール - Power Apps のチェッカー サービスと対話し、静的分析ジョブを実行して結果をダウンロードすることができます。

注

Microsoft Power Platform の GitHub アクションは、現在プレビューの段階です。