Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / GitHub ActionsによるPower Platform ALM：ソース・ビルド・テスト・デプロイを当て推量なしで（AI吹き替え）

Transcript

GitHub ActionsによるPower Platform ALM：ソース・ビルド・テスト・デプロイを当て推量なしで（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして未来の働き方を形作る人々が集う10日間、準備はいいですか?
0:07
この1月、M365コンが帰ってきます。さらに規模を拡大してお届けします。
0:12
世界中のMVPや業界の専門家によるライブセッション、実践的なデモ、そして貴重な知見を体験してください。
0:18
ありきたりなスライドは使いません。中身のない流行り言葉も排除します。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に切り込みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれのニーズに合わせたセッションをご用意しています。
0:35
10日間にわたる充実したプログラムで、多様なテクノロジーを探求し、世界中のコミュニティとつながりましょう。
0:40
ライブで視聴し、組織に持ち帰れる実践的な知見を得てください。
0:45
2027年1月、10日間、一つのマイクロソフトコミュニティ。
0:49
ただいま登録受付中です。
0:52
今すぐお席を確保しましょう。
0:54
サイトはメートル365コンドットネットです。
0:59
メートル365コンドットネットから今すぐご登録を、1月のライブでお会いしましょう。
1:04
パワープラットフォームのデプロイが、ブラックボックスのように感じたことはありませんか?
1:08
アップデートをリリースする際、開発、テスト本番環境でうまくいくことを祈りながら、息を止めて見守っていませんか?
1:13
GitHub Actionsを使ってアルムプロセスの全段階を制御、可視化し、推測や手作業を排除できたらどうでしょうか?
1:21
各コンポーネント、ソース管理、自動化、セキュアな変数がどのように連携しているのか、その舞台裏を明らかにします。
1:28
これは単なる手順の紹介ではありません。
1:30
多くのガイドが省略している理由を解説し、次回のデプロイで迷わないための知識を提供します。
1:35
なぜパワープラットフォームのアルムは迷路のように感じるのでしょうか?
1:38
パワーアップスのデプロイで、何か重要なことが漏れているのではという不安を感じたことがあるなら、それはあなただけではありません。
1:46
パワープラットフォームは手軽なアプリ開発を謳っていますが、その裏側にあるアルムは決して単純ではありません。
1:53
ウェブアプリなら、ソース管理からパイプラインでビルドされ、予測可能な挙動で本番環境へデプロイされます。
1:59
一方パワープラットフォームは、ロジックの半分をドラッグ&ドロップUIやコネクタ画面、Gitリポジトリからは見えない数式の中に隠しています。
2:08
そのため、管理者ガイドのステップをすべて踏んでも、ビジネスクリティカルなアプリが開発環境を離れると、診断困難な奇妙なエラーが発生するのです。
2:17
世の中に出回っているアルムガイドを見てみましょう。
2:19
そのほとんどは、ソリューションのZIPファイルをエクスポートしてインポートする手順を説明するだけです。
2:24
シンプルに見えますよね?
2:25
しかし、方法、Howはあくまで一つの側面にすぎません。
2:27
彼らが飛ばしているのは、理由、ホワイ、です。
2:29
なぜパワープラットフォームのデプロイは、通常のコードではありえないような壊れ方をするのでしょうか?
2:33
それが混乱を招く最大の要因です。
2:36
根本的な問題は、パワーアップスのロジックや接続、構成情報が、従来のコードのように保存されていないことにあります。
2:42
単にリポジトリをクローンしてユニットテストを確認すればいいというわけではありません。
2:45
そのため、アプリを移行しようとすると、アウトルック、シェアポイント、カスタムAPIへの接続といった隠れた依存関係が、必ずしもZIPファイル内に綺麗に収まるとは限りません。
2:53
こんなシナリオを考えてみましょう。
2:55
開発環境で、素晴らしい新しいアプリを完成させたとします。
2:58
ソリューションをエクスポートしてテスト環境にインポートすると、突然フローが動かなくなってしまいます。
3:02
これは単なるファイルの問題であることは稀です。
3:04
その代わり、接続先が間違っていたり、権限が一致していなかったり、先ほどまで問題なかった接続がデータポリシーによってブロックされたりします。
3:11
では、これを開発、テスト、本番という3つの環境で行うことを想像してみてください。
3:16
それぞれ異なる接続、データ保護ポリシー、承認者、管理上のガードレールが設定されています。
3:21
単なるコピー&ペーストでは解決できません。
3:24
調査結果は、管理者や開発者が毎週直面している状況を裏付けています。
3:27
パワープラットフォームのデプロイ失敗の大部分は、コネクタ参照の欠落や環境変数の管理不備によるものです。
3:34
コネクタ参照が欠落しているということは、フローがアウトルックやデータバースへの接続を見つけられないことを意味します。
3:40
そのため、別の環境でアプリやフローを実行しようとした瞬間に、実行時エラーが発生します。
3:47
また、パワープラットフォームの環境変数は他のマイクロソフト365製品とは異なる動作をするため、経験豊富な開発者でさえも苦労します。
3:55
変数は本来、エンドポイントやキー、テナント固有の設定を扱うためのものです。
4:00
しかし、ソリューションをエクスポートした後に更新を忘れると、一見無害な変更でもライブアプリを壊してしまうことがあります。
4:06
多くの人が最初は同じ罠にはまります。
4:09
ソリューションのジップをエクスポートすれば必要なものが全て含まれると思われがちですが、実際には動的なコネクタ参照はスキップされてしまいます。
4:15
例えば、開発環境でサードパーティサービスへのhttpコネクタを使用するアプリがあるとします。
4:19
テスト環境や本番環境にインポートしても、そのコネクタのインスタンスは存在しません。
4:24
アプリ内のコネクタ参照は存在しないオブジェクトを指すことになり、ユーザーや管理者が手動で接続を再作成して再割り当てするまで、ソリューション内のフローは静かに壊れたままになります。
4:34
開発者や管理者が複数人いる場合、どの参照がどこを指しているのか把握するのはさらに難しくなります。
4:40
開発環境では動いていたのに、という事後検証は誰も望んでいません。
4:44
もう一つの複雑な要素は、サービスプリンシパルです。
4:47
多くの人は手っ取り早く始められるため、ユーザーアカウントを使ってソリューションのエクスポートやインポートを行います。
4:53
しかし、GitHub Actionsや他のCIシステムを使って自動化しようとすると、個人の資格情報を使用する方法はすぐに行き詰まります。
4:59
権限の壁にぶつかり、明確なエラーメッセージが出なかったり、自動化のために意図されたアカウントではなく個人アカウントで重要なデプロイを実行しているためにコンプライアンス監査に抵触したりすることもあります。
5:10
サービスプリンシパルは、Azure ADで作成されるアプリのIDのようなものでパイプラインに必要なすべての権限、ログ記録、監査を管理します。
5:19
これがないと、自動化プロセスはバータリ的な手動操作の寄せ集めになり、誰が何を変更したのかわからなくなります。
5:25
ソース管理もまた予測不能な要素になってしまいます。通常のコードであれば、コミット履歴やブラム、ツールが使えます。
5:32
しかしパワープラットフォームのソリューションファイルは単なるスナップショットに過ぎず、細かな変更履歴を追跡できません。
5:37
キャンバスアプリの画面数式やドキュメントが不十分なフローに隠れたロジックは、再エクスポートするまで可視化されません。
5:44
誰かがUIでフローの設定を少し変更しただけで、なぜ下流環境の挙動が突然変わったのかを突き止めるのは困難です。
5:50
結局、パワープラットフォームのアルム管理は、パズルのピースが半分足りない、あるいは箱の下に隠れているような状態を解くようなものです。
5:57
目に見えない依存関係、環境固有のコネクタ、コードからは読み取れない変数など、これらすべてが従来の開発ワークフローを混乱させます。
6:07
さらに、本番環境には開発やテスト環境とは異なる厳しい権限、データポリシー、監査要件が課されることがほとんどです。
6:15
しかし、良い面もあります。この複雑さには理由があります。
6:20
パワープラットフォームがソース、変数、コネクタをこれほど独特な方法で扱うのには、実用的な理由があるのです。
6:27
それは、ビジネスユーザーがコードを気にせずに強力なアプリを作成できるようにするためです。
6:32
その副作用として、自動化を設定する担当者は、裏側で何が動いているかを追跡する必要があります。
6:38
その目に見えない繋がりを理解していれば、パワープラットフォームのアルムを妨げる多くの落とし穴を回避、修正できます。
6:46
これらすべてを管理するのが大変だと感じるなら、それは正しい反応です。
6:50
しかし、この混乱を整理するための4つのアルムの柱が存在します。
6:53
ソース、ビルド、テスト、デプロイです。
6:56
パワープラットフォームではそれぞれに癖がありますが、これらを組み合わせることで、混沌とした状況に秩序を取り戻すことができます。
7:02
アルムの核となるシステムソース、ビルド、テスト、デプロイ、誰かがパワープラットフォームのパイプラインを安定させたいという度に、真っ先に思い浮かぶのが、これら4つの基本となるアルムの柱です。
7:15
従来型の開発の世界では、寝ていてもできるような作業かもしれません。
7:18
しかし、パワープラットフォームはそれほど甘くありません。
7:21
突然、ソースの意味が変わってしまうからです。
7:24
ソリューションファイルを扱い、アプリやフロー、時にはソースの一部になりすますコネクタが詰まったジップバンドルをエクスポートする必要があるのです。
7:33
基本から始めて、この世界で各柱がなぜ少し奇妙に見えるのかを解き明かしていきましょう。
7:38
手元にあるのはソリューションのジップファイルです。
7:40
それは、一般的な意味でのコードではありません。
7:42
ファイルを開くとタイプスクリプトやCナンバーで見られるロジックではなく、XMLやJSONの定義ファイルが目に飛び込んできます。
7:48
しかし、これがパワープラットフォームのソースコードなのです。
7:51
チームはここでつまずくことがよくあります。
7:53
移植性が高いように見えますが、画面の数式更新やフローのロジック調整といった変更のほとんどは、新しいソリューションジップをエクスポートするまで反映されません。
8:02
Gitでソリューションファイルのバージョン管理は可能ですが、編集の度にエクスポートを徹底しなければ、履歴に大きな穴が開いてしまいます。
8:10
次は構成設定です。
8:12
通常のアプリなら、接続文字列を構成ファイルに保存して完了ですが、パワープラットフォームは環境固有のデータをソリューション内に隠し持っています。
8:21
環境変数だけでなく、コネクタ参照、動的エンドポイント、ロール、権限などがビジネスロジックと一緒にバンドルされているのです。
8:29
開発環境やテスト環境からエクスポートする前にこれらを更新し忘れると、間違った場所を指したまま固定されてしまいます。
8:36
チームが懸命にジップファイルをコミットしていても、いざデプロイすると、誰もコネクタ参照を再設定しなかったせいで、アプリの半分が本番環境ではなく開発環境のデータバースを参照していたという事態を何度も見てきました。
8:48
次はビルドです。
8:49
ビルドという言葉は通常、コードのコンパイルやCIジョブで緑色のチェックマークが付く様子を連想させます。
8:55
パワープラットフォームにおけるビルドプロセスは、ジップバンドルを保存し、スキーマを再確認し、依存関係を検証することです。
9:02
GitHub Actionsのパイプラインでは、ビルドジョブがコミットされたソリューションファイルを取得し、マイクロソフトのパワープラットフォームCLIを使用して展開、検証、再パッケージ化を行います。
9:11
検証のステップこそが、成功か混沌かの分かれ道です。
9:14
壊れた参照やサポートされていないアクションを検知できるかもしれません。
9:18
さらに悪いことに、フローの変更がソース管理されていないカスタムコネクタに依存している場合、ビルドは不完全なパッケージを黙って作成してしまいます。
9:26
ここからが難しいところです。
9:28
ビルドジョブの役割はコンパイルよりも、確実なエクスポートを調整し、内容が出荷可能な状態であることを確認することにあります。
9:36
これを怠ったり急いだりするチームは、ビルド自体は成功しても、UATや本番環境では本来の機能の半分が失われているという事態に陥ります。
9:44
マイクロソフトはソリューションファイルでARMが移植可能になると主張し続けていますが、常に注釈がついて回ります。
9:50
移植性は、コネクタが適切にマッピングされ、環境全体でロールが設定されているかどうかに依存します。
9:55
次はテストという難所です。
9:57
ウェブアプリのパイプラインでは、自動化テストでユニットテストやUIチェックを実行します。
10:02
パワープラットフォームでは、何をもってテストとするかが議論の的となります。
10:06
ソリューションの検証を指すこともあれば、ソリューションが開けるか、主要な依存関係が解決するかを確認することもあります。
10:12
また、テスト用フローを実行したり、テスト環境でコネクタが応答するかを確認することもあります。
10:18
キャンバスアプリ内のビジネスロジックの検証は自動化パイプラインに組み込まれていないことが多いため、テストは手動で行われることがほとんどです。
10:25
しかし、コネクタの欠落を見つけたり、重要なフローを検証したり、テスト環境へピンを打って視覚情報が有効か確認したりするチェックは自動化できます。
10:33
デプロイを行うと、その苦労が身に染みてわかります。
10:36
標準的なアプリのデプロイなら、AzureにWebアーティファクトをプッシュするだけで済むかもしれません。
10:39
パワープラットフォームの場合、接続のマッピング、権限の割り当て、シークレットの更新、環境変数の入れ替えを行い、最後に通常のユーザーアカウントではなくサービスプリンシパルを使用してインポートを実行する必要があります。
10:49
そうしなければ、監査や権限拒否の問題に悩まされることになります。
10:53
GitHub Actionsはこのプロセスを統合できますが、それには各ジョブがターゲットとする環境と使用すべきシークレットを認識していることが条件となります。
11:00
開発環境と本番環境で同じ資格情報を使い回して近道をしようとするチームを見かけますが、それは混乱やデータ漏洩、権限エラー、そして特定の環境でしか発生しない機能不全を招く原因となります。
11:10
数ヶ月前に私が関わった実際のチームの例を挙げましょう。
11:13
彼らは標準的なGitリポジトリ、バージョン管理されたソリューションジップ、明確なブランチ戦略など、ほとんどの点で正しい手順を踏んでいました。
11:18
しかし彼らのパイプラインはデプロイの度に必ず失敗していました。
11:20
なぜでしょう。
11:21
本番環境へインポートする前に、環境変数の入れ替えやコネクタ参照の更新を全く言っていなかったからです。
11:27
そのせいで、主要なフローが誤ったエンドポイントを指し、データが間違ったシステムへと流れていました。
11:31
解決策は、GitHubパイプライン内にインポート時に変数を入れ替え、すべてのコネクタを再マッピングするスクリプトステップを追加することでした。
11:37
マイクロソフトの公式ガイダンスも、この点について明確に述べています。
11:41
環境間で移行を行うにはソリューションファイルを使用し、コネクタ参照とロールマッピングは必ずパイプラインの一部として処理してください。
11:48
環境のロックダウンが進むにつれ、これらの手順を省略することがアプリを壊す最大の原因になると指摘されています。
11:54
ソース、ビルド、テスト、デプロイを独立したステップではなく、連携した稼働パーツとして扱うようになれば、なぜ多くのアルムの取り組みが失敗するのかが理解でき、運任せではなく実際に問題をトラブルシューティングできるようになります。
12:06
次は、GitHub Actionsがいかにしてこの複雑な連携を調整し、トリガー、ブランチングジョブ分離を通じてパワープラットフォームの自動化を柔軟かつ安全に保つかについて解説します。
12:17
GitHub Actions、トリガーとジョブによる連携
12:20
パワーアップを更新した後にGitHub Actionsのパイプライン完了を待ったことがあるなら、自動化が即時ではなく、決して魔法ではないことをすでにご存知のはずです。
12:29
多くのチームは、最初のワークフローが動いたという興奮の直後に、その壁にぶつかります。
12:33
スクリプトをセットアップし、リポジトリに接続すれば、新しいコミットがすべて自動的にすべての環境へスムーズに展開されると期待してしまいます。
12:41
そこで現実に直面するのです。
12:43
GitHub Actionsは、単にスクリプトを実行するのではなく、トリガージョブ、そして環境間の引き渡しに基づいた論理チェーンを使用します。
12:51
その順序と構造こそが、デプロイが失敗の手順や奇妙なエラーの絡まり合いになるのを防ぐものです。
12:57
このシステムの出発点はトリガーです。
12:59
初心者の多くは、すべてのプッシュやプルリクエストがメインブランチにマージされるたびに実行されるワークフローを作成します。
13:07
表面上は、それがベストプラクティスのように見えます。
13:10
変更のたびにパイプラインを実行して何が悪いのでしょうか。
13:12
ここに落とし穴があります。
13:14
メインブランチにのみトリガーを設定すると、すべてが単一の経路に集約されてしまいます。
13:17
もし、テスト環境や本番環境ではなく、開発環境だけに反映させたい変更がある場合はどうなるでしょうか。
13:21
もし、本番環境へプッシュする準備ができていても、テスト環境で検証がまだ終わっていない場合はどうなるでしょうか。
13:25
万能なトリガーに固執するチームは、開発環境向けの機能が本番環境に紛れ込んだり、テストのデプロイが本番設定を上書きしてしまったりする問題に直面しがちです。
13:34
ワークフローを開発、テスト、本番の各環境向けに分岐させ、それぞれに非常に具体的なトリガーを設定することができます。
13:42
例えば、開発ブランチへのプッシュ時のみ実行するワークフローを設定したり、本番リリースへのマージ時に別のワークフローを実行したりします。
13:50
このアプローチにより管理能力が高まり、作業中の変更と本番の変更との間に明確な境界線が生まれますが、多くのチームはトリガーを作成した後に見直すことをしません。
13:58
そうすることで、ある環境のシークレットが別の環境に漏れたり、開発用設定が誤って本番環境に入り込んだりします。
14:05
私が以前一緒に仕事をしたチームは、単一のワークフローで全てのアルムプロセスを実行しようとしていました。
14:10
しばらくは問題ないように見えましたが、ある時、本番データベースの接続文字列が開発環境に表示されていることに誰かが気づきました。
14:17
彼らは、シークレットがジョブ間で共有されていることに気づいていなかったのです。
14:21
そしてコードが環境間を移動すると、それらのシークレットも一緒に漏えいしてしまいました。
14:24
それは明らかなクラッシュやエラーではありませんでした。
14:26
密かに進行するものだったのです。
14:28
特にシークレットと環境変数を分離するようにワークフローを設定していない場合、こうしたデータ漏えいは予想以上に頻繁に起こります。
14:35
GitHub Actions Workflowの各ジョブは、プロセスの一部を明確に処理します。
14:39
あるジョブはソース環境からのソリューションのエクスポートを担当し、別のジョブが検証、展開、ソリューションメタデータのスキャン、依存関係のチェック、コネクタ参照の存在確認を行います。
14:52
次に、環境固有の変数を準備し、ソリューションをターゲット環境に合わせて変換するジョブが実行されます。
14:59
最後のジョブがサービスプリンシパルを使用してインポートプロセスを開始し、変更を適切な環境に書き込みます。
15:05
環境変数やシークレットを単なるプレースホルダーと考えるかもしれませんが、実際にはそれらがすべてをつなぎ止める接着剤なのです。
15:12
接続文字列、APIキー、共有パスワードなどはジョブ間で切り替える必要がありますが、境界を越えて漏えいすることは決して許されません。
15:20
パワープラットフォームのARMでは、環境ごとに異なるデータバース接続が必要だったり、対象のフローやパワーアップに応じてエンドポイントを切り替える必要があったりします。
15:29
変数を再利用したり、シークレットをハードコードしたりするとパイプラインが壊れやすくなるか、さらに悪いことに重大なセキュリティリスクを招くことになります。
15:36
インポートプロセスは、適切な保管庫からのみシークレットを抽出することに依存しており、テストや開発でのミスによって本番環境が晒されることはありません。
15:44
GitHub Actionsにおけるシークレットの適切なメンタルモデルは、各環境が独自のデジタル保管庫、つまり適切なジョブだけが見られるロックされた箱を持っていると考えることです。
15:53
GitHubでは、きめ細かな制御が可能です。
15:55
シークレットを環境ごとにスコープ設定できるため、開発環境で実行されるジョブが本番環境の視覚情報にアクセスすることはできず、その逆も同様です。
16:02
これらの保管庫を設定しておけば、誰かがパイプラインを調整してリスクのある操作をしようとしても、環境保護ルールがミスの波及を防いでくれます。
16:09
マイクロソフトとGitHubの両方のドキュメントで、この点が強調されています。
16:13
環境間の漏洩を未然に防ぐために、環境保護ルールとシークレットの厳密なスコープ設定が推奨されています。
16:20
そのような保護なしでは、どんなに優れたアルムワークフローも崩壊してしまいます。
16:24
開発環境の接続文字列を保持したまま本番環境にデプロイするワークフローや、テスト環境から突然本番データにアクセスできてしまう状況を想像してみてください。
16:32
必ずしも目に見える形で問題が起こるとは限りません。
16:35
コンプライアンスの警告が鳴ったり、ログが微妙なエラーで埋め尽くされ、それが徐々に積み重なって大きな問題になることもあります。
16:41
だからこそ、ワークフローの分岐やシークレットのスコープ設定は、単なる高度なトピックではないのです。
16:45
これらは、自動化が人知れず破綻するのを防ぐためのセーフティネットです。
16:49
ワークフローを環境ごとだけでなく、責任ごとに分割することにも価値があります。
16:54
ソリューションをエクスポートして検証する高度は、デプロイやシークレットの切り替え方法を知るべきではありません。
16:59
各ジョブがパズルのピースを一つずつ担当すれば、どこで問題が起きたかを特定し、ロールバックし、事後に変更を監査することがずっと容易になります。
17:08
シークレットは保管庫に止まり、ジョブは明確にスコープされた権限に従いパイプラインが失敗した場合は修正が必要な箇所が直ちに判明します。
17:16
GitHub Actionsがシークレットを厳密に管理し、トリガーを明確に定義した状態でジョブ間でどのように作業を引き継ぐかを理解することこそが、
17:23
アルムを希望的観測に基づく実験から、信頼性と安全性、予測可能性を備えた実践へと昇華させます。
17:28
このワークフローのセグメンテーションは、単にベストプラクティスに従うためのものではありません。
17:33
これは、静かなセキュリティ漏洩や意図しない上書きをブロックし、目に見えないエラーが環境を悩ませ始める前に、それらを根元から断ち切るものです。
17:42
適切にスコープされた自動化によって各パーツが連携できるようになった今、次の摩擦点に取り組む時が来ました。
17:49
コネクタ、サービスプリンシパル、そして地震がついた途端にデプロイを停滞させてしまう、小さくも致命的な落とし穴について。
17:58
またにまつわるトラブル。パワーアップやフローを開発環境から本番環境へ移行しようとしたことがある方なら、その苦労はよくご存知でしょう。
18:05
一つの環境では完璧に動作していたのに、切り替えた途端、すべてが停止したり、謎の接続エラーが発生したりします。
18:13
これは特定のチームだけに起こることではありません。すべてのパワープラットフォーム管理者が、いずれはこの壁にぶつかります。
18:19
問題の根本は、裏側でのコネクタやシークレットの挙動にあります。
18:24
開発環境からソリューションのジップをエクスポートしてそのまま他で動かそうとしても、依存する配線が環境ごとに変わるため、うまくいきません。
18:33
まずはコネクタ参照から見ていきましょう。
18:35
パワープラットフォームにおいて、コネクタは単なる固定の情報としてアプリに組み込まれるものではありません。
18:40
それは動的で可変的であり、環境ごとに異なることがほとんどです。
18:44
ソリューションをエクスポートする際、コネクタ参照はブックマークのような役割を果たします。
18:47
それらは、作成された環境内にしか存在しない接続オブジェクトを指し示しているからです。
18:52
そのため、テスト環境や本番環境にインポートしても、HTTPエンドポイントやデータバースへのリンクが同じように再作成されるとは限りません。
19:01
ここでチームはつまずくのです。
19:03
開発環境でコネクタがテストデータを使っており、その構成が本番環境で完全に再現されていなければ、
19:09
フローやアプリは沈黙したまま失敗するか、接続の最初の思考でハングアップしてしまいます。
19:15
多くの人は、環境間でユーザーの視覚情報を共有することでこれを回避しようとします。
19:21
開発環境で接続を作成したのと同じアカウントやパスワードを使えば、本番環境でも動くのではないかと考えるのです。
19:27
しかし実際には、これは権限拒否からコンプライアンス監査のトリガーまで多くの問題を引き起こします。
19:32
マイクロソフトのガイダンスは明確で、自動デプロイに個人のユーザー視覚情報を使用することは、実行可能でも安全でもありません。
19:39
これでは自動化がパスワードリセットの影響を受けてしまい、監査ログに曖昧な記録を残すことになります。
19:44
明確な説明責任がなく、元のユーザーがフラグを立てられたり、削除されたり、アクセス権を失ったりすると、最終的に権限によってパイプラインがブロックされます。
19:53
そこで登場するのがサービスプリンシパルです。
19:55
まだ使ったことがないなら、サービスプリンシパルを自動化専用のデジタルの手だと考えてみてください。
20:01
通常のユーザーとは異なり、サービスプリンシパルは実在の人物ではなく、Azure Adのアプリ登録に紐付いています。
20:08
デプロイ作業に必要な最小限の権限だけを与えるのです。
20:12
単純に聞こえますが、その恩恵は絶大です。
20:15
組織を去る可能性や役割が変わる可能性のあるユーザーに頼るのではなく、デプロイの一貫性、監査可能性、追跡可能性を維持できるようになります。
20:22
各環境は適切な接続とリソースにのみアクセスでき、あらゆる変更がロボットアカウントの下で記録されます。
20:31
また、修正不能な孤立したフローが残ることもありません。
20:34
コネクタのマッピング問題については、環境間に乖離が生じた場合を考えてみてください。
20:40
開発チームが新しいカスタムコネクタの承認を得たとします。
20:43
それがサンドボックスAPIに接続されるとしましょう。
20:46
本番環境へ移行する際、そのコネクタは単に不足しているだけでなく、組織のデータポリシーで許可されていない可能性もあります。
20:53
再マッピングを忘れると、アプリは誤ったエンドポイントを呼び出すか、完全に機能しなくなります。
20:58
最近、ある医療グループでこれが深刻な事態を招くのを目の当たりにしました。
21:01
コネクタのマッピング漏れが原因で本番環境でテストデータが使用され、コンプライアンス上の重大事故になりかけました。
21:07
自動化されたパイプラインは予定通りエクスポートされましたが、ソリューション内のコネクタ参照は古いテストデータベースを指したままでした。
21:14
パワープラットフォームがそれを警告したのは、誤った経路に実際のデータが流れ始めてからでした。
21:19
環境変数を使えば、こうした苦労をいくらか軽減できます。
21:23
エンドポイントやAPIキーをハードコーディングするのと異なり、環境変数なら環境ごとに変化する要素と固定の要素を分離できます。
21:30
アプリやフローを書き直すことなく、デプロイの度にエンドポイント、APIキー、その他のシークレットを入れ替えられます。
21:37
例えば、開発用のデータバーステーブルを使用するフローを、デプロイプロセス内で環境変数を変えるだけで、インポート時に本番テーブルを使うように再構成できます。
21:47
GitHub Actionsのパイプラインがこれを実用的なものにします。
21:50
各ジョブが適切なタイミングで適切な値を注入できるからです。
21:53
しかし、ここでも規律が重要です。
21:56
変数の更新を忘れたり、シークレットが環境間で漏えいしたりすれば、ワークフローは即座に危険にさらされます。
22:03
マイクロソフトは、シークレットの範囲を慎重に設定し、意図を持ってコネクタ参照をマッピングする必要性を強調しています。
22:09
DLP、データ損失防止、ポリシーには理由があります。
22:12
機密情報が環境間を流出したり、不適切な場所で表示されたりするのを防ぐためです。
22:18
変数や接続を共有してこれを回避しようとすれば、企業のセキュリティやコンプライアンス管理に抵触することになります。
22:26
さらに重要なのは、開発用、テスト用、本番用という境界線が曖昧になり、予測可能性が失われることです。
22:33
これらをすべて正しく管理できた場合のメリットは計り知れません。
22:36
サービスプリンシパルを適切に管理された環境変数やコネクタマッピングと組み合わせることでパイプラインは劇的に変わります。
22:42
デプロイメントが予測可能なものになります。
22:44
障害が発生しても明確な管理責任の所在があり、どこを確認すべきかが正確にわかります。
22:49
コネクタのマッピングか、変数か、それとも権限の不要漏れか。
22:52
監査人は変更を追跡でき、誰かが退職したりパスワードを変更したりしても不安を感じることはありません。
22:57
結局のところ、シークレット、コネクタ、サービスプリンシパルを重要視して扱うことに尽きるのです。