Microsoft Power Platform に関する ALM の基本
この記事では、アプリケーション ライフサイクル管理 (ALM) の実装に必要なコンポーネント、ツール、およびプロセスについて説明します。
環境
環境は、組織のビジネス データ、アプリ、ビジネス プロセスを保存、管理、共有する場所です。 また、ロール、セキュリティ要件、対象者が異なる可能性があるアプリを分離するコンテナとしても機能します。 環境ごとに Microsoft Dataverse データベースを 1 つのみ設定できます。 詳細情報: 環境の概要
重要
環境を作成するときに、Dynamics 365 Sales や Dynamics 365 Marketing などの Dynamics 365 アプリのインストールを選択できます。 これらのアプリは後でアンインストールまたはインストールできないため、必要かどうかをこのときに判断することが重要です。 これらのアプリをビルドしておらず、今後も必要としない場合は、環境にインストールしないことを推奨します。 これは、環境間でソリューションを配布するときに、依存関係の複雑化を回避するのに役立ちます。
ALM で使用される環境の種類
Power Platform管理センターを使用して、Power Platform環境のこれらのタイプを作成できます:
サンドボックス サンドボックス 環境 は、非本番環境の 環境 です Dataverse。 サンドボックス環境は運用環境から独立しており、アプリケーションの変更を、低リスクで安全に開発およびテストできる場所です。 サンドボックス環境には、リセット、削除、コピー操作など、運用環境で有害な機能が含まれています。 詳細: サンドボックス環境の管理
生産 アプリやその他のソフトウェアが意図された用途のために運用される 環境。
開発者 (正式にはコミュニティと呼ばれます)。 Power Apps 開発者プランでは、Power Appsプレミアム機能、Dataverse、および個人使用 Power Automate のアクセスが与えられます。 この計画は、主に Power Apps、Power Automate、および Microsoft Dataverse または学習目的のため次の方法で構築およびテストすることを目的としています。 開発者環境は単一ユーザー環境であり、運用アプリの実行または共有には使用できません。
デフォルト 各テナントに対して単一のデフォルト 環境 が自動的に作成され、そのテナント内のすべてのユーザーによって共有されます。 テナントは顧客を識別します。顧客は1つ以上のサブスクリプションとサービスに関連付けられている場合があります。 Microsoft Power Apps にサインアップする新しいユーザーは、既定の環境の作成者ロールに自動的に追加されます。 既定の環境は、Microsoft Entra テナントの既定の地域に最も近い地域に作成され、次の名前が付けられます: "{Microsoft Entra テナント名} (既定)"
開発、テスト、運用など、特定の目的のために正しい環境を作成して使用します。
環境上の詳細情報については、環境に関する概要を参照してください。
誰がアクセスできますか ?
Microsoft Dataverse でリソースとデータのセキュリティを定義および管理します。 Microsoft Power Platform はタスクを実行するための環境レベルの管理者ロールを提供します。 Dataverse には、Dataverse 内のアプリ、アプリ コンポーネント、アプリ作成者とユーザーが持つリソースへのアクセス レベルを定義するセキュリティ ロールが含まれています。
| 環境 目的 | アクセス権を持つ役割 | コメント |
|---|---|---|
| 開発 | アプリ作成者と開発者。 | アプリ ユーザーはアクセスできません。 開発者がリソースを作成するには、少なくとも環境作成者セキュリティ ロールが必要です。 |
| テスト | 管理者とテストしているユーザー。 | アプリ作成者、開発者、運用アプリのユーザーはアクセスできません。 テスト ユーザーには、テストを実行するための十分な特権が必要です。 |
| 実稼働 | 管理者とアプリ ユーザー。 ユーザーは、使用するアプリのタスクを実行するのに十分なアクセス権を持っている必要があります。 | アプリ作成者と開発者は、アクセス権を持たないようにするか、ユーザーレベルの特権のみを持つようにする必要があります。 |
| 既定値 | 既定では、テナントのすべてのユーザーが、データベースがある Dataverse 既定の環境でアプリを作成および編集できます。 | 特定の目的のための環境を作成し、それらを必要とするユーザーにのみ適切なロールと特権を付与することを強くお勧めします。 |
詳細:
ソリューション
別の環境にアプリケーションおよびコンポーネントを移動したり、既存のアプリケーションに一連のカスタマイズを適用するために、ソリューションが使用されます。
ソリューションには次の機能があります。
メタデータと構成データを含む特定のエンティティが含まれます。 ソリューションにはビジネス データは含まれていません。
モデル駆動型アプリ、キャンバス アプリ、サイト マップ、フロー、エンティティ、フォーム、カスタム コネクタ、Web リソース、オプション セット、グラフ、フィールドなどの、多くの異なる Microsoft Power Platform コンポーネントを含めることができます。 すべてのエンティティをソリューションに含められるわけではないことに注意してください。 たとえば、アプリケーション ユーザー、カスタム API、組織設定の各システム テーブルはソリューションに追加できません。
それらは、他の環境にエクスポートおよびインポートされる出荷単位としてパッケージ化されるか、分解され、資産のソース コードとしてソース管理にチェックインされます。 ソリューションは、既存のソリューションに変更を適用するためにも使用されます。
管理ソリューションは、そのソリューションの開発環境ではない環境に展開するために使用されます。 これには、テスト、ユーザー受け入れテスト (UAT)、システム統合テスト (SIT)、および運用環境が含まれます。 管理ソリューションは、環境内の他の管理ソリューションから独立してサービス (更新、修正プログラム、削除) を提供できます。 ALM のベスト プラクティスとして、管理ソリューションはビルド サーバーによって生成され、ビルド アーティファクトと見なされます。
管理ソリューションの更新は、以前のバージョンの管理ソリューションに展開されます。 これにより追加のソリューション レイヤーは作成されません。 更新を使用してコンポーネントを削除することはできません。
修正プログラムには、親管理ソリューションの変更のみが含まれています。 修正を使用するのは、小規模な更新 (修正プログラムと同様) を行う場合のみで、アンインストールする必要がある場合があります。 インポートされた修正プログラムは、上位のソリューションの上に重ねられています。 修正プログラムを使用してコンポーネントを削除することはできません。
ソリューションをアップグレードすると、基本レイヤーと既存の修正プログラムのすぐ上に新しいソリューション レイヤーがインストールされます。
ソリューションのアップグレードの適用には、既存のすべての修正プログラムと基本レイヤーの削除が含まれます。
ソリューションをアップグレードすると、既存のコンポーネントが削除されますが、アップグレードされたバージョンには含まれなくなります。
詳細: ソリューションの概念
ソース管理
ソース管理はバージョン管理とも呼ばれ、ソフトウェア開発資産を維持および安全に保存し、それらの資産に対する変更を追跡するシステムです。 複数のアプリ作成者と開発者が同じファイル セットで作業している場合、変更の追跡は特に重要です。 ソース管理システムでは、変更をロールバックしたり、削除されたファイルを復元したりすることもできます。
ソース管理システムで維持されている資産は "単一の情報ソース" つまり、ソリューションの単一のアクセス ポイントと修正ポイントであるため、ソース管理システムは組織が正常な ALM を実現するのに役立ちます。
分岐と統合戦略
ほぼすべてのソース管理システムには、何らかの形式の分岐および統合サポートがあります。 分岐とは、開発のメイン ラインから分岐し、メイン ラインを変更せずに作業を続けることを意味します。 統合のプロセスは、開発分岐からメイン ライン分岐へなど、1 つの分岐を別の分岐に結合することで構成されます。 一般的な分岐戦略には、トランク ベースの分岐、リリース分岐、および機能分岐があります。 詳細: Git 分岐戦略の採用
ソリューションを使用したソース管理プロセス
ソース管理システムでソリューションを操作するときに使用できる主なパスは 2 つあります:
- アンマネージド ソリューションをエクスポートし、アンパックされた状態でソース管理システムに配置します。 ビルド プロセスでは、パックされたソリューションがアンマネージドとして一時ビルド環境 (サンドボックス環境) にインポートされます。 次に、ソリューションをマネージド ソリューションとしてエクスポートし、ビルド アーティファクトとしてソース管理システムに保存します。
- ソリューションをアンマネージド ソリューションとしてエクスポートし、また、ソリューションをマネージド ソリューションとしてエクスポートして、両方をソース管理システムに配置します。 この方法ではビルド環境は必要ありませんが、すべてのコンポーネントのコピーを 2 つ維持する必要があります (アンマネージド ソリューションからのすべてのアンマネージド コンポーネントのコピー 1 つと管理ソリューションからのすべてのマネージド コンポーネントのコピー 1 つ)。
詳細: 構築ツール タスク
自動化
自動化は、ALM の生産性、信頼性、品質、効率を向上させるアプリケーション ライフ サイクルの重要な部分です。 自動化ツールとタスクは、サンドボックス環境の作成とリセットに加えて、ソリューションの検証、エクスポート、パック、アンパック、エクスポートに使用されます。
詳細: Microsoft Power Platform ビルド ツールの概要
共有ソース管理を使用したチーム開発
開発チームと協力してプロジェクトを構築する方法を検討することは重要です。 サイロを分割し、見解と会話を促進することで、チームはより優れたソフトウェアを提供できるようになります。 一部のツールとワークフロー Git、GitHub、および Azure DevOps は、通信とソフトウェアの品質を向上させるという明確な目的のために設計されました。 ソリューション システムで構成を操作すると、チーム開発に課題が生じる可能性があることに注意してください。 ソース管理システムには統合の発生方法に制限があるため、組織は統合の競合をできるだけ回避するために複数の開発者からの変更を調整する必要があります。 複数のユーザーが複雑なコンポーネントフォーム、フロー、キャンバス アプリなどに同時に変更を加えるような状況は避けることをお勧めします。
継続的統合と展開
任意のソース管理システムを使用して、継続的統合と継続的展開 (CI/CD) を開始するためのパイプラインを構築できます。 ただし、このガイドでは GitHub と Azure DevOps に重点を置きます。 GitHub は、何百万人もの開発者が使用する開発プラットフォームです。 Azure DevOps は、チームをサポートするための開発者サービスを提供して、作業の計画、コード開発との共同作業、およびアプリケーションの構築と展開を行います。
開始するには、以下が必要です:
詳細: 最初のパイプラインの作成
ライセンス
Power Apps および Power Automate を使用してアプリとフローを作成または編集するには、ユーザーはそれぞれ、Power Apps または Power Automate のユーザーごとのライセンス、または適切な Dynamics 365 アプリケーション ライセンスが必要です。 詳細については、Microsoft Power Platform のライセンスの概要 を参照してください。 ライセンスのニーズについて話し合うために、 Microsoft アカウント担当者に連絡することもお勧めします。
ALM の考慮事項
ALM を Microsoft Power Platform のアプリ構築の不可欠な部分と考えると、アプリの速度、信頼性、ユーザー エクスペリエンスを大幅に向上させることができます。 また、コードを作成する従来の開発者と市民開発者の両方の複数の開発者が、構築されるアプリケーションに共同で貢献できるようになります。
アプリケーション開発の最初に考慮すべきいくつかの項目について説明している以下の記事を参照してください: