このシリーズについて
フローとつながったキャンバスアプリを別環境へ移すときの管理方法を、全5部で整理しています。1部ごとに1つの判断を扱い、読み進めると推奨構成にたどり着く形です。本記事は第2部です。
- 第1部 フローとつながったアプリを別環境に移すなら、アプリのパッケージではなくソリューション
- 第2部 ソリューションを1本にするか、2本に分けるか（この記事）
- 第3部 移行先の SharePoint との差は環境変数で吸収する
- 第4部 アプリからフローを呼ぶ参照は、環境変数では吸収できない
- 第5部 結局どう運ぶのがよかったか
この記事は学習メモです。実際に検証できた範囲と、まだ推測にとどまる範囲を分けて書いています。間違いや不足に気づいたら随時更新します。
最終的なゴールは、アプリとフローを別テナント（先方環境）へ移すことです。現在は自分たちのテナント内にある開発環境と既定環境を使って検証している段階で、未検証の部分も残っています。ある程度方向性が定まってきたので、いったん整理しました。
この記事では、キャンバスアプリの「パッケージのエクスポート」で出力するものを「アプリのパッケージ」、Dataverse のソリューションとしてエクスポートするものを「ソリューション」と呼び分けています。
背景
第1部で、フローとつながったアプリはソリューションで運ぶと決めました。次に迷ったのが、アプリとフローを1つのソリューションにまとめるか、2つに分けるかです。
課題
リリース後にフローへ手を入れる頻度は低い一方、アプリは要望に応じて更新したい。1本にまとめると、フローには一切触っていないのにアプリを更新するたびフローも上書き対象になります。同じ内容で上書きされるだけかもしれませんが、自分の把握が及ばないところで何か変わっている可能性は残る。そこが気持ち悪かったんですよね。
調べたこと
公式には、ソリューションをインポートするとその中のフローがオフになり再度オンになる、複数の小さいソリューションに分ければ影響を抑えられる、と書かれています。ただ僕はこの記述をうまく理解できませんでした。同じページに、移行先にすでにあるフローへ更新をインポートしても状態には影響しない、オフならオフのまま、とも書かれているからです。
そこで実際に試しました。フローだけを入れたソリューションを、同名のアンマネージドソリューションとして既定環境に入れ直します。開発環境のフローはオン、既定環境の同じフローはオフの状態です。結果は上書き更新で、フローはオフのままでした。ここで2つのことが分かります。同名のアンマネージドソリューションは上書き更新されること、そして運用中のオン・オフ設定は勝手に書き換わらないことです。
一方、1本のときにアプリ更新でフローが止まるのかどうかは、まだ検証できていません。
結果
止まるかどうかが分からない以上、それを理由に選ぶのはやめました。代わりに、箱を分ければアプリ用ソリューションにフローが入らないので、アプリを何度更新してもフローは上書きされない。この一点で2本を選んでいます。
分けると手間は増えます。インポートは2回になり、環境変数をどちらに置くか決める必要があり、アプリ用とフロー用のバージョンの対応も自分で記録することになる。1本ならこれらは考えなくていいので、アプリとフローを常にセットで更新するなら1本のままで十分だと思います。
まとめ
アプリとフローの更新頻度が違うなら2本に分けます。手間は増えますが、触っていないフローが上書き対象に入らないことを確実にできます。常にセットで更新するなら1本のままでかまいません。
参考
前の記事：第1部 フローとつながったアプリを別環境に移すなら、アプリのパッケージではなくソリューション
次の記事：第3部 移行先の SharePoint との差は環境変数で吸収する