このシリーズについて
フローとつながったキャンバスアプリを別環境へ移すときの管理方法を、全5部で整理しています。1部ごとに1つの判断を扱い、読み進めると推奨構成にたどり着く形です。本記事は第1部です。
- 第1部 フローとつながったアプリを別環境に移すなら、アプリのパッケージではなくソリューション（この記事）
- 第2部 ソリューションを1本にするか、2本に分けるか
- 第3部 移行先の SharePoint との差は環境変数で吸収する
- 第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない
- 第5部 結局どう運ぶのがよかったか
この記事は学習メモです。実際に検証できた範囲と、まだ推測にとどまる範囲を分けて書いています。間違いや不足に気づいたら随時更新します。
最終的なゴールは、アプリとフローを別テナント（先方環境）へ移すことです。現在は自分たちのテナント内にある開発環境と既定環境を使って検証している段階で、未検証の部分も残っています。ある程度方向性が定まってきたので、いったん整理しました。
背景
社内向けの申請系アプリを別の環境へ移す機会があり、運び方を決める必要が出てきました。フローや接続参照は Dataverse（Power Platform のデータ基盤）側で管理される部品で、アプリ本体とは事情が違います。ここを整理しないまま進めると後で困りそうだと思い、一度調べることにしました。
運び方は2つあります。キャンバスアプリの「パッケージのエクスポート」で出力するもの（以下、アプリのパッケージ）と、Dataverse のソリューションとしてエクスポートするもの（以下、ソリューション）です。どちらもファイル自体は zip なので、この記事では呼び分けます。
課題
引っかかったのは、アプリのパッケージのインポート画面に出てくる「更新」の意味です。僕は「アプリのパッケージなんだから、運ばれるのはアプリ本体だけ。フローについては接続の紐づけが直るだけだろう」と思っていました。
調べたこと
Claude に公式ドキュメントの該当箇所を並べてもらい、自分で読み直して次の3点を確認しました。
- アプリのパッケージに含まれるリソースにはフローも並びます。フローに対する「更新」は、その環境にすでにあるフローがインポート時に更新される、という意味でした
- エクスポートの時点で、各リソースの既定のインポートアクションは「更新」に設定されています
- フローや接続参照など Dataverse への依存があるキャンバスアプリは、アプリのパッケージ方式ではサポート外。ALM が必要な場合は Dataverse とソリューションを使うよう書かれています
結果
アプリのパッケージはアプリだけを運ぶ道具ではなく、エクスポートした時点のフロー定義も一緒に持っていきます。気をつけたいのは、エクスポートしたあとにソリューション側のフローを更新した場合です。既定が「更新」のままインポートすると、フローがエクスポート時点の定義に戻ってしまう。ファイルが壊れているわけではないので、起きても気づきにくいんですよね。
まとめ
フローと接続しているアプリを別環境に移すなら、アプリのパッケージではなくソリューションを選びます。アプリのパッケージはエクスポート時点のフロー定義まで運ぶうえ既定のアクションが「更新」で、Dataverse 依存のあるアプリはサポート外とされているからです。
参考
- キャンバス アプリのエクスポートとインポートの概要
https://learn.microsoft.com/ja-jp/power-apps/maker/canvas-apps/export-import-app - パッケージとしてキャンバス アプリをエクスポート/インポートする
https://learn.microsoft.com/ja-jp/power-apps/maker/canvas-apps/export-import-app-package
次の記事：第2部 ソリューションを1本にするか、2本に分けるか