記事公開日
最終更新日
【Power Apps / Power Automate】環境変数を活用する（後編）
こんにちは。DXソリューション営業本部の吾妻です。
前回の記事 では、Power Platformに用意されている「環境変数」の考え方や、Power Platformのどこで利用できる機能なのかについて、簡単にご紹介しました。
今回は、Power Platformの「ALM」の考え方と関連付けて、実際のシステムで環境変数をどのように利用すべきかをご説明したいと思います。
ALMとは？
まず、 アプリケーション ライフサイクル （ALMのAとL）は、次の図のように、計画・追跡 → 開発 → 構築・テスト → 展開 → 運用 → 監視・学習を循環させていくソフトウェア開発プロセスのことを指します。
そして、「アプリケーション ライフサイクル マネジメント（ ALM ）」とは、Power Platformの機能であるソリューションやAzure DevOpsといった製品を活用して、アプリのパフォーマンスや、信頼性、UXを向上させるための考え方を示したものです。ALMを実現するための機能は、 ALMツール と呼ばれています。
このような考え方は、ローコード開発（Power Platform製品群）に限ったものではなく、通常のスクラッチ開発でも同様の運用が取られることは多いと思いますが、運用ではなく機能として、ALMに基づいていることを保証することで、客観的に見て、信頼性などが保たれていると確認できる状態にしておくことが重要です。
ALMのための運用方法
ALMの初歩として、まずは
①ソリューションの機能を用いてアプリやフローなどのコンポーネントを一括管理すること
②テストが済んだソリューションだけを本番運用に乗せること
③Power Platform環境を目的別に使い分けて、環境間でソリューションを移行していくこと
の実現を目指します。
環境間でソリューションを移行するためには、それぞれの環境でコンポーネント（ソリューションの中身）を手作業で作り直すのではなく、移行元の環境でソリューションパッケージをエクスポートして、移行先の環境でインポートします。こうすることで、移行元のコンポーネントと移行先のコンポーネントが同一の内容であることを保証します。エクスポートするとき、ソリューションを開発環境に移行したい場合はアンマネージドソリューションとして、検証環境や運用環境に移行したい場合はマネージドソリューションとして、パッケージを作成するように設定します。
なお、ソリューションパッケージには、コンポーネントは含まれますが、Dataverseテーブルのレコード（データ）は含まれません。そのため、データも環境間で移行したい場合には、ソリューションの移行とは別に実施する必要があります（後ほどまた出てきます）。データを移行する際には、Dataverseのインポート／エクスポート機能を利用したり、Power Automateクラウドフローを実装したり、Excelアドインを利用したりといった方法が想定されます。その中から、データ容量や実行タイミング、インポート後の権限管理（所有者の設定）といった条件に合わせて選択します。
ALMのための環境構成
これ以降は、「Power Platform環境の管理」の記事でご紹介した、「業務システムごと、かつ、目的ごとに、開発環境・検証環境・運用環境の3環境を払い出す運用」をもとに考えていきます。
この環境構成を採用した場合の、ALMを意識した運用方法は以下のようになります。
①開発者が開発環境でアプリやフローなどを作成し、単体テスト／結合テストを行う
…単体テスト／結合テストの対象は、アプリやフローそれぞれで完結するものや、アプリとフローが連携するもの
②開発環境でテストが完了して本番運用に乗せることが可能だと判断されたソリューションをパッケージ化する
…マネージドソリューションとしてパッケージ化することによって、ソリューションのバージョン番号や内容（コンポーネント）を確定させる
③開発環境からエクスポートしたパッケージが、運用環境にインポートできることを保証するために、（運用環境の前に）検証環境にインポートしてみることでデプロイ（インポート作業そのもの）のテストを行う
④検証環境へのデプロイが正常に完了して、システム全体としてきちんと動作することを確認する
…アプリやフローだけでなく、ソリューションコンポーネントすべてを含めたテストを行う（総合テスト相当）
⑤検証環境にインポートしたのと同じパッケージを、運用環境にインポートする
…検証環境にインポートしたのと同じパッケージなので、検証環境でのテストをパスしたのと同様、運用環境でもきちんと動作することが期待できる（絶対にきちんと動作するとは限らないので、運用環境でもテストは必要）
⑥運用環境に利用者がアクセスできるように、セキュリティグループやセキュリティロールの設定を変更する（本番リリース）
⑦システムのバージョンアップ（コンポーネントの編集）を行う場合は、①に戻る
（システムが運用され続ける限り、①から⑦を繰り返し続ける）
なぜ環境変数を利用するのか？
この「開発環境・検証環境・運用環境の3環境を払い出す運用」で問題となるのは、異なる環境で同一のソリューションパッケージを使用しなければならないために、環境ごとに異なるパラメーターをアプリやフローに埋め込むことができないという点です。
ソリューションの内容を編集できるのは開発環境のみであり、マネージドソリューションとして扱う検証環境・運用環境では編集できないので、アプリやフローにパラメーターを埋め込んでしまうと、ソリューションを丸ごと検証環境・運用環境に展開したあとでも、開発環境用のパラメーターをそのまま使わざるを得ないことになります。また、開発環境にあるうちに検証環境用のパラメーターに書き換えたとしても、そのパッケージをそのまま運用環境にも展開しなければならないので、結局運用環境用のパラメーターに変更できず、利用できません。
ここで言うパラメーターとは、以下のような設定値を指します。
(a) Power Platform環境の「環境URL（Environment URL）」のように、環境ごとに固有の値となるもの
(b) SharePointリストのURL、外部サービスのエンドポイントURLや認証情報（APIキー）のように、接続先サービスでも検証用／本番用が分かれていて、対応する設定値を環境ごとに保持しておく必要があるもの
(c) メンテナンスモードを設定するためのフラグのように、本番リリース後にも随時設定値を変更する必要があるもの
このうち、(a)の環境URL（例：https://org*****.crm7.dynamics.com）のように、自身が格納されている環境の情報を動的に取得することで、環境間で移行したとしても問題ないものもありますが、そうでない場合には、アプリやフローとは独立して、定数の値を保持する必要があります。
また、(c)のフラグは、Dataverseにマスタテーブルを用意して、そこで設定値を管理することもできますが、運用方法でご説明した通り、Dataverseテーブルの中身（レコード）はソリューションパッケージに含めることができないので、移行直後にデータ移行を別途行うか、マスタデータの初期登録を行うクラウドフローを用意する必要があるので、若干手間が増えます。
そこで、環境変数を利用することで、パラメーターをソリューションの中でまとめて管理することをおすすめします。
具体的な実装の例
それでは、具体的な構成と実装の例を見ていきましょう。
例として、Power Automateから外部サービスを利用する実装を考えます。外部サービス側では、検証と運用のエンドポイントが用意されていて、以下の対応関係を持つことにします。
ちなみに、上の図では、Power Platform検証環境からは外部サービスの運用エンドポイントに接続しない前提としていますが、これは設計の際に検討が必要なポイントだと思います。
原則として、運用エンドポイントにアクセスできる開発者の人数や、アクセスする頻度は少なく抑えた構成としたほうが、本番稼働中のシステムでの障害発生や、情報漏洩のリスクを抑えられます。
しかし、その一方で、外部サービス側の運用エンドポイントから実データを取得しないと発覚しないようなバグ・データ不正が生じる可能性もあります。そのため、検証エンドポイントと運用エンドポイントでのデータの差異をなくし、検証環境から運用エンドポイントにアクセスする構成とすることも考えられます。この場合、開発者は検証環境を操作できないようにセキュリティグループを設定する、パッケージを展開する際に承認を必要とするような運用とする、といった、制限をかける必要があります。
これら2つの構成は、トレードオフの関係にあるといえるため、機能やセキュリティの要件に合わせて設計する必要があります。
Before
ALMを意識しない実装の場合、以下の図のように、クラウドフローの先頭で、「変数を初期化する」アクションで追加して、そこでエンドポイントURLやAPIキーを初期値として代入しておき、その値を後続のHTTPアクションで認証情報としてHTTPヘッダーの値の欄で利用する、といった内容とすることが多いかと思います。
このような実装の場合には、ソリューションを別の環境に移行した際に、移行先の環境でクラウドフロー自体を編集しない限り、値を書き換えることができなくなります。
アンマネージドでソリューションパッケージを移行するのであれば、これでも問題ありません。
しかし、ALMを実現するためには、検証環境・運用環境にインポートするのは、マネージドのパッケージでなければなりません。
マネージドのソリューション（マネージドのパッケージをインポートしてできたソリューション）では、下図のように、クラウドフローも環境変数も、ソリューションコンポーネントとしては編集できない状態となります（環境変数の値の編集については後述します）。
このため、クラウドフローを編集できず、Power Platform側の運用環境から外部サービス側の運用エンドポイントにアクセスさせることができなくなります。
After
移行先の環境でクラウドフロー自体を編集しなくても、外部サービスを呼び出すためのパラメーターを差し替えることができるようにすることで、ALMを実現できるように作り直したいと思います。
まず、環境変数を作成して、「現在値」に定数を格納します。
環境変数は、検証環境と運用環境で同じものを使うので、同じパラメーターに対して2つ作成する必要はありません。つまり、「環境変数-検証-エンドポイント」／「環境変数-運用-エンドポイント」のように用意する必要はなく、「エンドポイント」1つのみ用意すれば十分です。逆に、2つ用意してしまうと、アプリやフローの中で条件分岐して参照先の環境変数を変化させる実装が必要になり、冗長となります。
次に、クラウドフローの中身を編集します。Beforeでは、変数を初期化する際の値として、文字列を直接記述していましたが、今回は「動的な値」から対応する環境変数を選択します。
インポートの様子
環境変数を利用したソリューションパッケージをインポートする際のUIを示します。インポート手順の最中に、環境変数の値だけを更新する画面が表示されたら、移行先環境で利用するパラメーターの値に書き換えてあげます。
ここでのポイントは、「環境変数を編集する画面（作成する時と同じような画面右端に出てくるUI）」ではなく「環境変数の値だけを更新する画面」だということです。値だけしか変更されていない（変更できない）ことが保証されます。
このように環境変数を用意して、クラウドフローから環境変数を参照するようにすることで、クラウドフローを編集することなくパラメーターを差し替えることができ、ALMを実現するための第一歩を踏み出すことができました。
まとめ
今回は、環境変数の概要と、「ALM」の考え方と関連付けた場合のPower Platformでの利用箇所についてご紹介しました。
QES では Power Platform の開発支援、QAサポート、開発者教育、ガバナンス整備など、組織で Power Platform を活用するためのサポートを包括的にご提供しています。Power Platform 活用についてご興味がある／利用中だが課題を感じていらっしゃるお客様はまずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
