コード コンポーネント アプリケーションの ライフサイクル管理 (ALM)

ALM は、ソフトウェア アプリケーションのライフサイクル管理を説明するために使用される用語であり、開発、保守、およびガバナンスが含まれます。 詳細: Microsoft Power Platform のアプリケーション ライフサイクル管理 (ALM)。

この記事では、Microsoft Dataverse のコードコンポーネントの観点から、ライフサイクル管理の特定の側面を扱う際の考慮事項と戦略について説明します。

1. ALM の開発とデバッグに関する考慮事項
2. コード コンポーネント ソリューション戦略
3. バージョン管理と更新の適用
4. キャンバス アプリ ALM に関する考慮事項

ALM の開発とデバッグに関する考慮事項

コード コンポーネントを開発するには、以下の手順に従います:

1. コード コンポーネント プロジェクト (pcfproj) を、pac pcf init を使用してテンプレートから作成します。 詳細: コード コンポーネントを作成およびビルドする。
2. コード コンポーネント ロジックを実装する。 詳細: コンポーネントの実装。
3. ローカル テスト ハーネスを使用してコード コンポーネントをデバッグします。 詳細については、 コード コンポーネントのデバッグを参照してください。
4. ソリューション プロジェクト (cdsproj) を作成して、コード コンポーネント プロジェクトを参照として追加します。 詳細: コード コンポーネントをパッケージ化する
5. 配布と展開のために、コード コンポーネントをリリースモードでビルドする。

コード コンポーネントをモデル駆動型アプリ、キャンバスアプリ、またはポータル内でテストする準備ができたら、コード コンポーネントを Dataverse に展開する方法が 2 通りあります:

1. pac pcf Push: これは、ソリューションが指定されていない場合に、--solution-unique-name パラメータで指定されたソリューション、または一時的な PowerAppsTools で指定されたソリューションに一度に 1 つのコード コンポーネントをデプロイします。

2. pac solution init と msbuild を使って、1 つ以上のコード コンポーネントへの参照を持つ cdsproj ソリューション プロジェクトをビルドします。 各コード コンポーネントは、pac solution add-reference を使用して cdsproj に追加されます。 ソリューション プロジェクトには複数のコード コンポーネントへの参照を含めることができますが、コード コンポーネント プロジェクトには単一のコード コンポーネントのみを含めることができます。

   次の図は、cdsproj と pcfproj プロジェクトの 1 対多の関係を示しています。

   

詳細: コード コンポーネントをパッケージ化する

pcfproj コードコンポーネント プロジェクトのビルド

pcfproj プロジェクトをビルドする際、生成された JavaScript は、ビルドに使用されるコマンドと PcfBuildMode ファイル内の pcfproj によって異なります。

通常は、開発モードでビルドしたMicrosoft Dataverseにコード コンポーネントをデプロイしないでください。 多くの場合、コンポーネントは大きすぎてインポートできず、実行時のパフォーマンスが低下する可能性があります。 詳細については、「Microsoft Dataverseへのデプロイ後にコード コンポーネントをデバッグする」を参照してください。

pac pcf push でリリース ビルドを作成するには、PcfBuildMode 要素の下に新しい要素を追加することによって pcfproj を OutputPath 内に設定します。

<PropertyGroup>
   <Name>my-control</Name>
   <ProjectGuid>6aaf0d27-ec8b-471e-9ed4-7b3bbc35bbab</ProjectGuid>
   <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
   <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

次の表は、どのコマンドにより開発ビルドとリリース ビルドが作成されるかを示しています。

pcfproj で使用されるビルド コマンド	開発ビルド (デバッグ目的専用)	リリースビルド
npm start watch	常時
pac pcf push	既定の動作、または PcfBuildMode が pcfproj ファイルで development に設定されている場合	PcfBuildMode は pcfproj ファイル内で production に設定されています
npm run build	既定の動作	npm run build -- --buildMode production

詳細: コード コンポーネントをパッケージ化する

.cdsproj ソリューション プロジェクトのビルド

ソリューション プロジェクト (.cdsproj) を構築すると、出力をマネージドまたはアンマネージド ソリューションとして生成するオプションがあります。 マネージド ソリューションは、そのソリューションの開発環境ではない任意の環境に配置するために使用されます。 これには、テスト、UAT、SIT、および運用環境が含まれます。 詳細: 管理ソリューションとアンマネージド ソリューション。

SolutionPackagerType は、pac solution init で作成された .cdsproj ファイルに含まれていますが、最初はコメント アウトされています。該当するセクションのコメント アウトを解除し、マネージド、アンマネージド、または 両方 に設定します。

 <!-- Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both) -->
 <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
 </PropertyGroup>

次の表は、どのコマンドと構成により開発ビルドとリリース ビルドが作成されるかを示しています:

cdsproj で使用されるビルド コマンド	SolutionPackageType	出力
msbuild	マネージド	管理ソリューション内にビルドされた開発
msbuild /p:configuration=Release	マネージド	リリース ビルド (管理ソリューション内)
msbuild	アンマネージド	アンマネージド ソリューション内の開発ビルド
msbuild /p:configuration=Release	アンマネージド	アンマネージド ソリューション内にビルドされたリリース

詳細: コード コンポーネントをパッケージ化する

コード コンポーネントによるソース コード管理

コード コンポーネントを開発する際は、Azure DevOps または GitHub のようなソース コード管理プロバイダーを使用することをお勧めします。 Git ソース管理を使用して変更をコミットする場合、pac pcf init テンプレートによって提供される .gitignore ファイルにより、一部のファイルはソース管理に追加されません。これは、それらのファイルが npm によって復元されるか、またはビルド プロセスの一部として生成されるためです。

# dependencies
/node_modules

# generated directory
**/generated

# output directory
/out

# msbuild output directories
/bin
/obj

/out フォルダが除外されているため、結果として bundle.js ファイル (および関連リソース) ビルトは、ソース管理に追加されません。 コード コンポーネントが手動で、または自動ビルド パイプラインの一部としてビルドされる場合、bundle.js は、すべての変更が確実に含まれるように、最新のコードを使用してビルドされます。

また、ソリューションが構築されても、関連するソリューションの ZIP ファイルはソース管理にコミットされません。 代わりに、出力はバイナリ リリースのアーティファクトとして公開されます。

コード コンポーネントで SolutionPackager を使用する

ソースが pcfproj と cdsproj を管理するだけでなく、SolutionPackagerは、ソース管理にコミットできる一連の XML ファイルとして、ソリューションをそれぞれの部分に段階的に解凍するために使用できます。 これには、メタデータの全体像を人間が読める形式で作成できるという利点があるため、プル要求または類似するものを使用して変更を追跡できます。 環境のソリューション メタデータに変更が加えられるたびに、Solution Packager を使用して解凍し、変更を変更セットとして表示できます。

注

現時点では、変更を Dataverse ソリューションからエクスポートするために段階的に使用できるという点で、SolutionPackager は pac solution clone を使用することとは異なります。

コード コンポーネントを、テーブル、モデル駆動型アプリ、キャンバス アプリなどの他のソリューション要素と組み合わせている場合は、通常 cdsproj プロジェクトのビルドは必要ありません。 代わりに、ビルドされたアーティファクトを pcfproj からソリューションのパッケージ フォルダに移動させてから、インポート用に再パックします。

コード コンポーネントを含むソリューションを、SolutionPackager /action: Extract を使用して解凍したら、次のようになります:

.
├── Controls
│   └── prefix_namespace.ControlName
│       ├── bundle.js *
│       └── css
│          └── ControlName.css *
│       ├── ControlManifest.xml *
│       └── ControlManifest.xml.data.xml
├── Entities
│   └── Contact
│       ├── FormXml
│       │   └── main
│       │       └── {3d60f361-84c5-eb11-bacc-000d3a9d0f1d}.xml
│       ├── Entity.xml
│       └── RibbonDiff.xml
└── Other
    ├── Customizations.xml
    └── Solution.xml

Controls フォルダーの下に、には、ソリューションに含まれる各コード コンポーネントのサブフォルダーが表示されます。 他のフォルダーには、ソリューションに追加されたその他のソリューション コンポーネントが含まれています。

このフォルダー構造をソース管理にコミットする場合、上にのアスタリスク (*) がついたファイルは除外します。これは、pcfproj プロジェクトが対応するコンポーネント用にビルドされたときの出力となるためです。

必要な唯一のファイルは、*.data.xmlファイルです。これには、パッケージ化プロセスに必要なリソースを説明するメタデータが含まれているためです。 各コード コンポーネントがビルドされた後、out フォルダーのファイルは、SolutionPackager フォルダーのそれぞれのコントロール フォルダーにコピーされます。 ビルド出力が追加されると、パッケージ フォルダーには、SolutionPackager /action: Pack を使って Dataverse ソリューションに再パックするのに必要なすべてのデータが含まれます。

詳細: SolutionPackager コマンドライン引数。

コード コンポーネント ソリューション戦略

コード コンポーネントは、Dataverse ソリューションを使用してダウンストリーム環境に展開されます。 開発環境に展開されると、他のソリューション コンポーネントと同じ方法でデプロイできます。 詳細情報 ソリューションの概念 - Power Platform を参照してください。

ソリューション内にコード コンポーネントを展開するには、次の 2 つの戦略があります。

1. セグメント化されたソリューション - ソリューション プロジェクトは、pac solution init、pac solution add-reference を使用して作成され、1 つ以上のコード コンポーネントを追加します。 このソリューションは、ダウンストリーム環境にエクスポートおよびインポートできます。他のセグメント化されたソリューションは、コード コンポーネント ソリューションに依存するため、最初にその環境に展開する必要があります。 これは、全体的な機能が異なるソリューション セグメントとレイヤーに分割され、相互依存関係がソリューション フレームワークによって追跡されるため、ソリューション セグメンテーションと呼ばれます。 このアプローチを使用する場合、複数の開発環境 (セグメント化されたソリューションごとに 1 つずつ) が必要になる可能性があります。 詳細情報、Power Apps でセグメント化されたソリューションを使用するを参照してください。

2. 単一のソリューション - 単一のソリューションを Dataverse 環境内に作成し、その中にコード コンポーネントを、他のソリューション コンポーネント（テーブル、モデル駆動型アプリ、キャンバス アプリなど）とともに追加します。これらの他のコンポーネントは、それらのコード コンポーネントを参照します。 このソリューションは、ソリューション間の依存関係なしに、ダウンストリーム環境にエクスポートおよびインポートできます。 このアプローチでは、コードと環境のブランチが重要になり、別の領域で行われている変更を行わずに、ソリューションの一部に更新を展開できます。 詳細: Microsoft Power Platform とのブランチおよびマージ戦略。

混合単一ソリューションアプローチよりもセグメント化ソリューションアプローチを採用する理由は次のとおりです。

1. バージョン管理のライフサイクル - ソリューションの他の部分とは別のライフサイクルで、コード コンポーネントを開発、展開、バージョン管理する場合。 これは、開発者が構築したコード コンポーネントがアプリ作成者によって消費されている「フュージョン チーム」がある場合の一般的なシナリオです。 通常、これは、コード コンポーネントが他のソリューション コンポーネントとは異なるコード リポジトリに存在することも意味します。

2. 共有使用 - コード コンポーネントを複数の環境間で共有したいため、コード コンポーネントを他のソリューション コンポーネントと結合したくない場合。 これは、ISV である場合や、それぞれが独自の環境を持つ組織のさまざまな部分で使用するコード コンポーネントを開発している場合が考えられます。

次の図は、これら 2 つのアプローチのソリューション ライフサイクルの概要を示しています:

次の図は、次の点を説明しています:

1. PAC CLI を使用してプッシュ - コード コンポーネントを Dataverse 内部でテストする準備ができたら、pac pcf push を使って開発環境へ展開します。 これにより、PowerAppsTools_namespace という名前のアンマネージド ソリューションが作成されます。この場合、namespace はコード コンポーネントを展開する目的で使用するソリューション プロバイダーの名前空間接頭辞です。 ソリューション プロバイダーはターゲット環境にすでに存在している必要があり、ダウンストリーム環境で使用するものと同じ名前空間の接頭辞を持っている必要があります。デプロイ後、テスト用にコードコンポーネントをモデル駆動型またはキャンバス アプリに追加できます。

   注

   上記のように、開発ではなく本番用に最適化されたコードを展開するよう、本番ビルド用にコード コンポーネント cdsproj を構成することが重要です。

2. 既存のコードコンポーネントを追加する (PAC CLI のデプロイ後) -単一ソリューションのアプローチを使用している場合、デプロイすると、コード コンポーネントを別のソリューションに追加できます。 (このソリューションは、PowerAppsToolsソリューションで使用しているものと同じソリューション発行者を共有する必要があります。)

   

3. アンマネージド ソリューション プロジェクトを構築する - ソリューション cdsproj プロジェクトを使用している場合、アンマネージド ソリューションはmsbuild を使ってビルドでき、次に開発環境にインポートします。

4. 既存のコード コンポーネントを追加する (ソリューション プロジェクトのデプロイ後) - pac pcf push 後とほぼ同じ方法で、ソリューション プロジェクト ビルドからインポートされたコード コンポーネントは、同じソリューション発行者接頭辞が使用されていれば、混合ソリューションに追加できます。

5. 単一のソリューションを管理対象としてエクスポート - 単一の混合コンポーネント ソリューションは、管理対象としてエクスポートし、ダウンストリーム環境にインポートできます。 コード コンポーネントと他のソリューション コンポーネントは同じソリューションに展開されるため、すべて同じソリューションとバージョン管理戦略を共有します。

6. コード コンポーネントのセグメント化されたソリューションを管理対象としてエクスポート - セグメント化されたソリューション アプローチを使用している場合は、コード コンポーネント ソリューション プロジェクトを管理対象としてダウンストリーム環境にエクスポートできます。

7. 管理対象としてコード コンポーネントのセグメント化されたソリューションをビルドする - セグメント化されたソリューションを使用していて、アンマネージドソリューションが必要ない場合、msbuild /p:configuration=Release を使用してソリューション プロジェクトを管理ソリューションとして直接ビルドできます。 次に、これをコード コンポーネントに依存する必要のある環境にインポートできます。

8. セグメント化されたコード コンポーネント ソリューションを消費する- マネージド セグメント化ソリューションを介してコード コンポーネントを展開すると、コード コンポーネント ソリューションに依存して、他のソリューションをビルドできます。 コード コンポーネントへの依存関係は、ソリューションのタイプ 66 の MissingDependencies セクションに記載されています。 詳細: ソリューション コンポーネントの依存関係の追跡。

9. コード コンポーネントのセグメント化されたソリューションを、使用するソリューションの前にデプロイする - セグメント化されたコード コンポーネント ソリューションに依存するソリューションをインポートする場合、インポートする前にコード コンポーネント ソリューションをターゲット環境にインストールする必要があります。

詳細: ソリューションを使用した拡張機能のパッケージ化および配布.

コード コンポーネントと自動ビルド パイプライン

コード コンポーネント ソリューションを手動でビルドして展開するだけでなく、自動ビルド パイプラインを使用してコード コンポーネントをビルドおよびパッケージ化することもできます。

• Azure DevOps を使用している場合、Azure DevOps に対して Microsoft Power Platform ビルド ツール を使用できます。
• GitHub を使用している場合、Power Platform GitHub Actions を使用できます。

自動化されたビルド パイプラインを使用することの利点は以下の通りです:

• 時間効率 - 手動タスクを削除すると、コンポーネントのビルドとパッケージ化のタスクが迅速になり、変更がチェックインされるたびなど、定期的に実行できるようになります。
• 繰り返し可能 - ビルド プロセスが自動化されると、毎回同じように実行されるため、ビルドを実行するチームのメンバーによって変化しません。
• バージョン管理の一貫性 - ビルド パイプラインがコード コンポーネントとソリューションのバージョンを自動的に設定すると、新しいビルドが作成されたときに、以前のバージョンと一貫したバージョン管理を徹底できます。 これにより、機能、バグ修正、および展開の追跡が容易になります。
• 保守性の高さ - ソリューションのビルドに必要なものはすべてソース管理内から含まれているため、コードをチェックアウトすることで、いつでも新しいブランチや開発環境を作成できます。 更新をデプロイする準備ができたら、プル要求をダウンストリーム ブランチにマージできます。 詳細: Microsoft Power Platform とのブランチおよびマージ戦略。

上記のように、コード コンポーネントのソリューション管理には、セグメント化されたソリューション プロジェクト、またはモデル駆動型アプリ、キャンバス アプリ、コード コンポーネントが追加されるテーブルなどの他のアーティファクトを含む単一の混合ソリューションの 2 つのアプローチがあります。

セグメント化されたコード コンポーネント ソリューションプロジェクトを使用している場合は、プロジェクトを Azure DevOps パイプライン (Microsoft Power Platform ビルド ツールを使用) または GitHub パイプライン (GitHub アクションMicrosoft Power Platformを使用) 内部でビルドできます。 各コード コンポーネント pcfproj フォルダーがソース管理に追加され (generated、out、node_modules フォルダーを除く)、cdsproj プロジェクトが作成され、ソース管理に追加する前にも各コード コンポーネントが pac solution add-reference を使って参照されます。 次に、パイプラインは次のことを実行します:

1. Solution.xml ファイルのソリューション バージョンを、ビルドのバージョンに一致するよう更新します。 ソリューション バージョンは、ImportExportXml/Version 属性内に保持されます。 バージョン管理戦略の詳細については、以下を参照してください。
2. ControlManifest.Input.xml ファイルでコード コンポーネント バージョンを更新します。 バージョンは、manifest/control/version 属性内に保管されます。 これは、ビルドされたすべての pcfproj プロジェクトに対して行う必要があります。
3. 引数/restore /p:configuration=Releaseを指定して、ワイルドカード *.cdsproj を使用して MSBuild タスクを実行します。 これにより、すべての cdsproj プロジェクトとその参照 pcfproj プロジェクトがビルドされます。
4. ビルドしたソリューションの ZIP ファイルを、パイプラインのリリース アーティファクトに追加します。 このソリューションには、cdsproj に参照として含まれているすべてのコード コンポーネントが含まれます。

コード コンポーネントに加えて他のコンポーネントを含む混合ソリューションを使用している場合、これは上記のように SolutionPackager を使用してソース管理に抽出されます。 次に、パイプラインは次のことを実行します:

1. 上記手順 1 と手順 2 と同じ方法で、ソリューションとコード コンポーネントのバージョンを更新します。
2. Microsoft Power Platform ビルド ツールを、PowerPlatformToolInstaller タスクを使ってビルド パイプラインにインストールします。
3. コマンド node_modules を備えた Npm タスクを使って ci を復元します。
4. Npm の customCommand パラメーターを備えた run build -- --buildMode release タスクを使って、本番リリース モードでコード コンポーネントをビルドします。
5. ビルドの出力を、対応する管理のソリューション パッケージャー フォルダーにコピーします。
6. Power Platform ビルド ツール PowerPlatformPackSolution タスクを使ってソリューションをパッケージ化します。
7. ビルドしたソリューションの ZIP ファイルを、パイプラインのリリース成果物に追加します。

後の工程で開発環境を作成できるように、アンパックされたソリューション メタデータをアンマネージド形式でソース管理にコミットすることをお勧めします。 管理ソリューション メタデータのみがコミットされた場合、新しい開発環境の作成は難しくなります。これには以下の 2 つのオプションがあります:

1. Solution Packager の /packagetype:Both オプションを使用して管理とアンマネージドの両方をコミットします。 これにより、マネージド モードまたはアンマネージド モードのいずれかでパックできますが、ソース コード内で重複するという欠点があり、変更が複数の xml ファイル (管理バージョンとアンマネージドバージョンの両方) に表示されることがよくあります。
2. アンマネージドをソース管理にのみコミットし (結果としてよりクリーンな変更セットになります)、ビルド パイプライン内でパッケージ化されたソリューションをビルド環境にインポートしてから管理対象としてエクスポートし、管理展開アーティファクトに変換できるようにします。

バージョン管理と更新の適用

コード コンポーネントをデプロイおよび更新するときは、次のことができるように、一貫したバージョン管理戦略を立てることが重要です:

• 含まれている機能/修正に対して、展開されているバージョンを追跡する。
• キャンバス アプリが最新バージョンに更新する必要があることを確実に検出する。
• モデル駆動型アプリがキャッシュを無効化し、新しいバージョンを読み込むようにしてください。

一般的なバージョン管理戦略はセマンティック バージョニングで、形式は次のとおりです: MAJOR.MINOR.PATCH。

PATCH バージョンを増やす

ControlManifest.Input.xml には、コントロール要素にコード コンポーネントのバージョンが保存されます:

<control namespace="..." constructor="..." version="1.0.0" display-name-key="..." description-key="..." control-type="...">

コード コンポーネントに更新を展開する場合、変更を検出するには、ControlManifest.Input.xml のバージョンで少なくともその PATCH (バージョンの最後の部分) がインクリメントされている必要があります。 これは、バージョン属性を直接編集するか、次のコマンドを使用してパッチのバージョンを 1 つ進めることにより、手動で実行できます:

pac pcf version --strategy manifest

または、パッチ パーツの正確な値を指定するには (たとえば、自動ビルド パイプラインの一部として)、次を使用します:

pac pcf version --patchversion <PATCH VERSION>

詳細情報: pac pcf version。

メジャーとマイナー バージョンをインクリメントするタイミング

コード コンポーネントのバージョンのメジャー バージョンとマイナー バージョンは、それが配布される Dataverse ソリューションと同期しておくことをお勧めします。 例:

1. 展開されたコード コンポーネントのバージョンは 1.0.0 で、ソリューション バージョンは 1.0.0.0 です。
2. コード コンポーネントに小さな更新を加え、1.0.1 を使用して、コード コンポーネントのパッチ バージョンを pac pcf version --strategy manifest にインクリメントします。
3. デプロイ用にコード コンポーネントをパッケージ化する場合、Solution.xml のソリューション バージョンは 1.0.0.1 に更新されます。または、ソリューションを手動でエクスポートすることにより、バージョンは自動的にインクリメントされます。
4. メジャー バージョンとマイナー バージョンを 1.1.0.0 にインクリメントするように、ソリューションに大幅な変更を加えます。
5. この場合、コード コンポーネントのバージョンを 1.1.0 に更新することもできます。

Dataverse ソリューションは 4 つの部分で構成されており、次の構造として考えることができます: MAJOR.MINOR.BUILD.REVISION。

AzureDevOps を使用している場合、Build と Rev 環境変数 (実行 (ビルド) 番号 - Azure パイプライン) を使ってビルド パイプライン バージョン管理を設定し、記事PowerShell スクリプトを使用してパイプラインをカスタマイズするで説明されているアプローチと同様の PowerShell スクリプトを使用します。

セマンティック バージョン パート	ControlManifest.Input.xml のバージョン部分 MAJOR.MINOR.PATCH	Solution.xml のバージョン部分 MAJOR.MINOR.BUILD.REVISION	AzureDevOps ビルド バージョン
MAJOR	MAJOR	MAJOR	パイプライン変数 $(majorVersion) を設定するか、またはソース管理に最後にコミットされた値を使用します。
MINOR	MINOR	軽微	パイプライン変数 $(minorVersion) を設定するか、またはソース管理に最後にコミットされた値を使用します。
---	---	ビルド	$(Build.BuildId)
パッチ	パッチ	改訂	$(Rev:r)

キャンバス アプリ ALM に関する考慮事項

キャンバス アプリでコード コンポーネントを使用することは、モデル駆動型アプリとは異なります。 インサート パネルで より多くのコンポーネントを入手する を選択することで、コード コンポーネントをアプリに明示的に追加する必要があります。 コード コンポーネントがキャンバス アプリに追加されると、アプリ定義内のコンテンツとして含まれます。 デプロイ後 (およびコントロール バージョンがインクリメントされた後) にコード コンポーネントの新しいバージョンに更新するには、アプリ作成者が Power Apps Studio で最初にアプリを開き、コード コンポーネントを更新するダイアログでプロンプトが表示されたら更新を選択します。 その後、ユーザーがアプリを使うときに使用する新しいバージョンのために、アプリを保存して公開する必要があります。

アプリが更新されていない場合、またはスキップが使用されている場合、アプリは新しいバージョンで上書きされているため、環境に存在していなくても、古いバージョンのコード コンポーネントを引き続き使用します。

アプリにはコード コンポーネントのコピーが含まれているため、異なるキャンバス アプリ内から単一の環境で異なるバージョンのコード コンポーネントを並べて実行することができます。 ただし、同じアプリで異なるバージョンのコード コンポーネントを並べて実行することはできません。 アプリ開発者は、新しいバージョンが配布された際には、アプリを最新のコード コンポーネントに更新することをお勧めします。

注

現時点では、一致するコードコンポーネントがその環境にデプロイされていなくても、キャンバス アプリをインポートできますが、アプリが最新バージョンのコード コンポーネントを使用するように更新され、同じバージョンがその環境に最初に、または同じソリューションの一部として常にデプロイされていることが推奨されます。

関連記事

Microsoft Power Platform によるアプリケーション ライフサイクル管理 (ALM)
Power Apps Component Framework API の参照
最初のコンポーネントを作成する
コード コンポーネントのデバッグ