WEBVTT 00:00:00.000 --> 00:00:07.220 マイクロソフト365、コパイロット、AI、Azure、そして未来の働き方を形作る人々が集う10日間、準備はいいですか? 00:00:07.360 --> 00:00:12.360 この1月、M365コンが帰ってきます。さらに規模を拡大してお届けします。 00:00:12.620 --> 00:00:18.300 世界中のMVPや業界の専門家によるライブセッション、実践的なデモ、そして貴重な知見を体験してください。 00:00:18.480 --> 00:00:22.100 ありきたりなスライドは使いません。中身のない流行り言葉も排除します。 00:00:22.300 --> 00:00:29.320 コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に切り込みます。 00:00:29.320 --> 00:00:35.040 ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれのニーズに合わせたセッションをご用意しています。 00:00:35.220 --> 00:00:40.680 10日間にわたる充実したプログラムで、多様なテクノロジーを探求し、世界中のコミュニティとつながりましょう。 00:00:40.880 --> 00:00:44.740 ライブで視聴し、組織に持ち帰れる実践的な知見を得てください。 00:00:45.100 --> 00:00:49.280 2027年1月、10日間、一つのマイクロソフトコミュニティ。 00:00:49.460 --> 00:00:51.420 ただいま登録受付中です。 00:00:52.780 --> 00:00:54.880 今すぐお席を確保しましょう。 00:00:54.880 --> 00:00:59.280 サイトはメートル365コンドットネットです。 00:00:59.460 --> 00:01:04.660 メートル365コンドットネットから今すぐご登録を、1月のライブでお会いしましょう。 00:01:04.820 --> 00:01:08.480 パワープラットフォームのデプロイが、ブラックボックスのように感じたことはありませんか? 00:01:08.600 --> 00:01:13.800 アップデートをリリースする際、開発、テスト本番環境でうまくいくことを祈りながら、息を止めて見守っていませんか? 00:01:13.800 --> 00:01:21.200 GitHub Actionsを使ってアルムプロセスの全段階を制御、可視化し、推測や手作業を排除できたらどうでしょうか? 00:01:21.300 --> 00:01:28.220 各コンポーネント、ソース管理、自動化、セキュアな変数がどのように連携しているのか、その舞台裏を明らかにします。 00:01:28.420 --> 00:01:30.360 これは単なる手順の紹介ではありません。 00:01:30.540 --> 00:01:35.080 多くのガイドが省略している理由を解説し、次回のデプロイで迷わないための知識を提供します。 00:01:35.260 --> 00:01:38.560 なぜパワープラットフォームのアルムは迷路のように感じるのでしょうか? 00:01:38.560 --> 00:01:46.020 パワーアップスのデプロイで、何か重要なことが漏れているのではという不安を感じたことがあるなら、それはあなただけではありません。 00:01:46.180 --> 00:01:53.000 パワープラットフォームは手軽なアプリ開発を謳っていますが、その裏側にあるアルムは決して単純ではありません。 00:01:53.200 --> 00:01:59.720 ウェブアプリなら、ソース管理からパイプラインでビルドされ、予測可能な挙動で本番環境へデプロイされます。 00:01:59.900 --> 00:02:08.220 一方パワープラットフォームは、ロジックの半分をドラッグ&ドロップUIやコネクタ画面、Gitリポジトリからは見えない数式の中に隠しています。 00:02:08.220 --> 00:02:17.040 そのため、管理者ガイドのステップをすべて踏んでも、ビジネスクリティカルなアプリが開発環境を離れると、診断困難な奇妙なエラーが発生するのです。 00:02:17.180 --> 00:02:19.660 世の中に出回っているアルムガイドを見てみましょう。 00:02:19.900 --> 00:02:24.000 そのほとんどは、ソリューションのZIPファイルをエクスポートしてインポートする手順を説明するだけです。 00:02:24.160 --> 00:02:25.200 シンプルに見えますよね? 00:02:25.360 --> 00:02:27.540 しかし、方法、Howはあくまで一つの側面にすぎません。 00:02:27.680 --> 00:02:29.740 彼らが飛ばしているのは、理由、ホワイ、です。 00:02:29.740 --> 00:02:33.800 なぜパワープラットフォームのデプロイは、通常のコードではありえないような壊れ方をするのでしょうか? 00:02:33.920 --> 00:02:35.940 それが混乱を招く最大の要因です。 00:02:36.100 --> 00:02:41.960 根本的な問題は、パワーアップスのロジックや接続、構成情報が、従来のコードのように保存されていないことにあります。 00:02:42.140 --> 00:02:45.620 単にリポジトリをクローンしてユニットテストを確認すればいいというわけではありません。 00:02:45.620 --> 00:02:53.820 そのため、アプリを移行しようとすると、アウトルック、シェアポイント、カスタムAPIへの接続といった隠れた依存関係が、必ずしもZIPファイル内に綺麗に収まるとは限りません。 00:02:53.980 --> 00:02:55.540 こんなシナリオを考えてみましょう。 00:02:55.740 --> 00:02:58.280 開発環境で、素晴らしい新しいアプリを完成させたとします。 00:02:58.480 --> 00:03:01.880 ソリューションをエクスポートしてテスト環境にインポートすると、突然フローが動かなくなってしまいます。 00:03:02.020 --> 00:03:04.060 これは単なるファイルの問題であることは稀です。 00:03:04.060 --> 00:03:11.640 その代わり、接続先が間違っていたり、権限が一致していなかったり、先ほどまで問題なかった接続がデータポリシーによってブロックされたりします。 00:03:11.820 --> 00:03:16.540 では、これを開発、テスト、本番という3つの環境で行うことを想像してみてください。 00:03:16.780 --> 00:03:21.600 それぞれ異なる接続、データ保護ポリシー、承認者、管理上のガードレールが設定されています。 00:03:21.780 --> 00:03:23.960 単なるコピー&ペーストでは解決できません。 00:03:24.140 --> 00:03:27.840 調査結果は、管理者や開発者が毎週直面している状況を裏付けています。 00:03:27.840 --> 00:03:34.160 パワープラットフォームのデプロイ失敗の大部分は、コネクタ参照の欠落や環境変数の管理不備によるものです。 00:03:34.260 --> 00:03:40.320 コネクタ参照が欠落しているということは、フローがアウトルックやデータバースへの接続を見つけられないことを意味します。 00:03:40.560 --> 00:03:46.800 そのため、別の環境でアプリやフローを実行しようとした瞬間に、実行時エラーが発生します。 00:03:47.000 --> 00:03:55.280 また、パワープラットフォームの環境変数は他のマイクロソフト365製品とは異なる動作をするため、経験豊富な開発者でさえも苦労します。 00:03:55.280 --> 00:03:59.920 変数は本来、エンドポイントやキー、テナント固有の設定を扱うためのものです。 00:04:00.040 --> 00:04:06.540 しかし、ソリューションをエクスポートした後に更新を忘れると、一見無害な変更でもライブアプリを壊してしまうことがあります。 00:04:06.760 --> 00:04:08.940 多くの人が最初は同じ罠にはまります。 00:04:09.160 --> 00:04:14.880 ソリューションのジップをエクスポートすれば必要なものが全て含まれると思われがちですが、実際には動的なコネクタ参照はスキップされてしまいます。 00:04:15.040 --> 00:04:19.580 例えば、開発環境でサードパーティサービスへのhttpコネクタを使用するアプリがあるとします。 00:04:19.580 --> 00:04:24.060 テスト環境や本番環境にインポートしても、そのコネクタのインスタンスは存在しません。 00:04:24.220 --> 00:04:34.540 アプリ内のコネクタ参照は存在しないオブジェクトを指すことになり、ユーザーや管理者が手動で接続を再作成して再割り当てするまで、ソリューション内のフローは静かに壊れたままになります。 00:04:34.720 --> 00:04:40.200 開発者や管理者が複数人いる場合、どの参照がどこを指しているのか把握するのはさらに難しくなります。 00:04:40.380 --> 00:04:44.160 開発環境では動いていたのに、という事後検証は誰も望んでいません。 00:04:44.380 --> 00:04:47.380 もう一つの複雑な要素は、サービスプリンシパルです。 00:04:47.580 --> 00:04:53.380 多くの人は手っ取り早く始められるため、ユーザーアカウントを使ってソリューションのエクスポートやインポートを行います。 00:04:53.600 --> 00:04:59.940 しかし、GitHub Actionsや他のCIシステムを使って自動化しようとすると、個人の資格情報を使用する方法はすぐに行き詰まります。 00:04:59.940 --> 00:05:10.340 権限の壁にぶつかり、明確なエラーメッセージが出なかったり、自動化のために意図されたアカウントではなく個人アカウントで重要なデプロイを実行しているためにコンプライアンス監査に抵触したりすることもあります。 00:05:10.580 --> 00:05:18.820 サービスプリンシパルは、Azure ADで作成されるアプリのIDのようなものでパイプラインに必要なすべての権限、ログ記録、監査を管理します。 00:05:19.000 --> 00:05:25.220 これがないと、自動化プロセスはバータリ的な手動操作の寄せ集めになり、誰が何を変更したのかわからなくなります。 00:05:25.220 --> 00:05:32.000 ソース管理もまた予測不能な要素になってしまいます。通常のコードであれば、コミット履歴やブラム、ツールが使えます。 00:05:32.180 --> 00:05:37.440 しかしパワープラットフォームのソリューションファイルは単なるスナップショットに過ぎず、細かな変更履歴を追跡できません。 00:05:37.600 --> 00:05:43.960 キャンバスアプリの画面数式やドキュメントが不十分なフローに隠れたロジックは、再エクスポートするまで可視化されません。 00:05:44.200 --> 00:05:50.020 誰かがUIでフローの設定を少し変更しただけで、なぜ下流環境の挙動が突然変わったのかを突き止めるのは困難です。 00:05:50.020 --> 00:05:57.460 結局、パワープラットフォームのアルム管理は、パズルのピースが半分足りない、あるいは箱の下に隠れているような状態を解くようなものです。 00:05:57.620 --> 00:06:06.340 目に見えない依存関係、環境固有のコネクタ、コードからは読み取れない変数など、これらすべてが従来の開発ワークフローを混乱させます。 00:06:07.020 --> 00:06:15.880 さらに、本番環境には開発やテスト環境とは異なる厳しい権限、データポリシー、監査要件が課されることがほとんどです。 00:06:15.880 --> 00:06:20.260 しかし、良い面もあります。この複雑さには理由があります。 00:06:20.480 --> 00:06:27.300 パワープラットフォームがソース、変数、コネクタをこれほど独特な方法で扱うのには、実用的な理由があるのです。 00:06:27.500 --> 00:06:32.200 それは、ビジネスユーザーがコードを気にせずに強力なアプリを作成できるようにするためです。 00:06:32.420 --> 00:06:38.680 その副作用として、自動化を設定する担当者は、裏側で何が動いているかを追跡する必要があります。 00:06:38.680 --> 00:06:46.120 その目に見えない繋がりを理解していれば、パワープラットフォームのアルムを妨げる多くの落とし穴を回避、修正できます。 00:06:46.340 --> 00:06:50.080 これらすべてを管理するのが大変だと感じるなら、それは正しい反応です。 00:06:50.240 --> 00:06:53.740 しかし、この混乱を整理するための4つのアルムの柱が存在します。 00:06:53.940 --> 00:06:56.200 ソース、ビルド、テスト、デプロイです。 00:06:56.360 --> 00:07:02.100 パワープラットフォームではそれぞれに癖がありますが、これらを組み合わせることで、混沌とした状況に秩序を取り戻すことができます。 00:07:02.100 --> 00:07:15.000 アルムの核となるシステムソース、ビルド、テスト、デプロイ、誰かがパワープラットフォームのパイプラインを安定させたいという度に、真っ先に思い浮かぶのが、これら4つの基本となるアルムの柱です。 00:07:15.200 --> 00:07:18.740 従来型の開発の世界では、寝ていてもできるような作業かもしれません。 00:07:18.940 --> 00:07:21.480 しかし、パワープラットフォームはそれほど甘くありません。 00:07:21.660 --> 00:07:24.340 突然、ソースの意味が変わってしまうからです。 00:07:24.340 --> 00:07:33.020 ソリューションファイルを扱い、アプリやフロー、時にはソースの一部になりすますコネクタが詰まったジップバンドルをエクスポートする必要があるのです。 00:07:33.160 --> 00:07:37.940 基本から始めて、この世界で各柱がなぜ少し奇妙に見えるのかを解き明かしていきましょう。 00:07:38.120 --> 00:07:40.160 手元にあるのはソリューションのジップファイルです。 00:07:40.320 --> 00:07:42.360 それは、一般的な意味でのコードではありません。 00:07:42.500 --> 00:07:48.160 ファイルを開くとタイプスクリプトやCナンバーで見られるロジックではなく、XMLやJSONの定義ファイルが目に飛び込んできます。 00:07:48.160 --> 00:07:50.960 しかし、これがパワープラットフォームのソースコードなのです。 00:07:51.100 --> 00:07:53.080 チームはここでつまずくことがよくあります。 00:07:53.300 --> 00:08:02.280 移植性が高いように見えますが、画面の数式更新やフローのロジック調整といった変更のほとんどは、新しいソリューションジップをエクスポートするまで反映されません。 00:08:02.480 --> 00:08:10.400 Gitでソリューションファイルのバージョン管理は可能ですが、編集の度にエクスポートを徹底しなければ、履歴に大きな穴が開いてしまいます。 00:08:10.600 --> 00:08:12.200 次は構成設定です。 00:08:12.200 --> 00:08:21.380 通常のアプリなら、接続文字列を構成ファイルに保存して完了ですが、パワープラットフォームは環境固有のデータをソリューション内に隠し持っています。 00:08:21.560 --> 00:08:29.400 環境変数だけでなく、コネクタ参照、動的エンドポイント、ロール、権限などがビジネスロジックと一緒にバンドルされているのです。 00:08:29.560 --> 00:08:36.340 開発環境やテスト環境からエクスポートする前にこれらを更新し忘れると、間違った場所を指したまま固定されてしまいます。 00:08:36.340 --> 00:08:48.180 チームが懸命にジップファイルをコミットしていても、いざデプロイすると、誰もコネクタ参照を再設定しなかったせいで、アプリの半分が本番環境ではなく開発環境のデータバースを参照していたという事態を何度も見てきました。 00:08:48.360 --> 00:08:49.440 次はビルドです。 00:08:49.640 --> 00:08:55.640 ビルドという言葉は通常、コードのコンパイルやCIジョブで緑色のチェックマークが付く様子を連想させます。 00:08:55.800 --> 00:09:02.360 パワープラットフォームにおけるビルドプロセスは、ジップバンドルを保存し、スキーマを再確認し、依存関係を検証することです。 00:09:02.360 --> 00:09:11.600 GitHub Actionsのパイプラインでは、ビルドジョブがコミットされたソリューションファイルを取得し、マイクロソフトのパワープラットフォームCLIを使用して展開、検証、再パッケージ化を行います。 00:09:11.760 --> 00:09:14.760 検証のステップこそが、成功か混沌かの分かれ道です。 00:09:14.900 --> 00:09:18.060 壊れた参照やサポートされていないアクションを検知できるかもしれません。 00:09:18.300 --> 00:09:26.200 さらに悪いことに、フローの変更がソース管理されていないカスタムコネクタに依存している場合、ビルドは不完全なパッケージを黙って作成してしまいます。 00:09:26.400 --> 00:09:28.140 ここからが難しいところです。 00:09:28.140 --> 00:09:35.920 ビルドジョブの役割はコンパイルよりも、確実なエクスポートを調整し、内容が出荷可能な状態であることを確認することにあります。 00:09:36.140 --> 00:09:44.580 これを怠ったり急いだりするチームは、ビルド自体は成功しても、UATや本番環境では本来の機能の半分が失われているという事態に陥ります。 00:09:44.760 --> 00:09:50.200 マイクロソフトはソリューションファイルでARMが移植可能になると主張し続けていますが、常に注釈がついて回ります。 00:09:50.380 --> 00:09:55.220 移植性は、コネクタが適切にマッピングされ、環境全体でロールが設定されているかどうかに依存します。 00:09:55.220 --> 00:09:57.040 次はテストという難所です。 00:09:57.180 --> 00:10:01.940 ウェブアプリのパイプラインでは、自動化テストでユニットテストやUIチェックを実行します。 00:10:02.120 --> 00:10:06.080 パワープラットフォームでは、何をもってテストとするかが議論の的となります。 00:10:06.300 --> 00:10:12.500 ソリューションの検証を指すこともあれば、ソリューションが開けるか、主要な依存関係が解決するかを確認することもあります。 00:10:12.760 --> 00:10:18.220 また、テスト用フローを実行したり、テスト環境でコネクタが応答するかを確認することもあります。 00:10:18.220 --> 00:10:25.300 キャンバスアプリ内のビジネスロジックの検証は自動化パイプラインに組み込まれていないことが多いため、テストは手動で行われることがほとんどです。 00:10:25.480 --> 00:10:33.340 しかし、コネクタの欠落を見つけたり、重要なフローを検証したり、テスト環境へピンを打って視覚情報が有効か確認したりするチェックは自動化できます。 00:10:33.560 --> 00:10:35.980 デプロイを行うと、その苦労が身に染みてわかります。 00:10:36.140 --> 00:10:39.980 標準的なアプリのデプロイなら、AzureにWebアーティファクトをプッシュするだけで済むかもしれません。 00:10:39.980 --> 00:10:49.440 パワープラットフォームの場合、接続のマッピング、権限の割り当て、シークレットの更新、環境変数の入れ替えを行い、最後に通常のユーザーアカウントではなくサービスプリンシパルを使用してインポートを実行する必要があります。 00:10:49.660 --> 00:10:53.080 そうしなければ、監査や権限拒否の問題に悩まされることになります。 00:10:53.280 --> 00:11:00.180 GitHub Actionsはこのプロセスを統合できますが、それには各ジョブがターゲットとする環境と使用すべきシークレットを認識していることが条件となります。 00:11:00.180 --> 00:11:10.340 開発環境と本番環境で同じ資格情報を使い回して近道をしようとするチームを見かけますが、それは混乱やデータ漏洩、権限エラー、そして特定の環境でしか発生しない機能不全を招く原因となります。 00:11:10.540 --> 00:11:13.320 数ヶ月前に私が関わった実際のチームの例を挙げましょう。 00:11:13.500 --> 00:11:18.380 彼らは標準的なGitリポジトリ、バージョン管理されたソリューションジップ、明確なブランチ戦略など、ほとんどの点で正しい手順を踏んでいました。 00:11:18.560 --> 00:11:20.900 しかし彼らのパイプラインはデプロイの度に必ず失敗していました。 00:11:20.900 --> 00:11:21.680 なぜでしょう。 00:11:21.680 --> 00:11:26.900 本番環境へインポートする前に、環境変数の入れ替えやコネクタ参照の更新を全く言っていなかったからです。 00:11:27.080 --> 00:11:31.540 そのせいで、主要なフローが誤ったエンドポイントを指し、データが間違ったシステムへと流れていました。 00:11:31.740 --> 00:11:37.820 解決策は、GitHubパイプライン内にインポート時に変数を入れ替え、すべてのコネクタを再マッピングするスクリプトステップを追加することでした。 00:11:37.960 --> 00:11:41.120 マイクロソフトの公式ガイダンスも、この点について明確に述べています。 00:11:41.120 --> 00:11:48.140 環境間で移行を行うにはソリューションファイルを使用し、コネクタ参照とロールマッピングは必ずパイプラインの一部として処理してください。 00:11:48.300 --> 00:11:54.360 環境のロックダウンが進むにつれ、これらの手順を省略することがアプリを壊す最大の原因になると指摘されています。 00:11:54.580 --> 00:12:06.580 ソース、ビルド、テスト、デプロイを独立したステップではなく、連携した稼働パーツとして扱うようになれば、なぜ多くのアルムの取り組みが失敗するのかが理解でき、運任せではなく実際に問題をトラブルシューティングできるようになります。 00:12:06.580 --> 00:12:17.380 次は、GitHub Actionsがいかにしてこの複雑な連携を調整し、トリガー、ブランチングジョブ分離を通じてパワープラットフォームの自動化を柔軟かつ安全に保つかについて解説します。 00:12:17.580 --> 00:12:20.540 GitHub Actions、トリガーとジョブによる連携 00:12:20.540 --> 00:12:28.940 パワーアップを更新した後にGitHub Actionsのパイプライン完了を待ったことがあるなら、自動化が即時ではなく、決して魔法ではないことをすでにご存知のはずです。 00:12:29.080 --> 00:12:33.820 多くのチームは、最初のワークフローが動いたという興奮の直後に、その壁にぶつかります。 00:12:33.820 --> 00:12:41.320 スクリプトをセットアップし、リポジトリに接続すれば、新しいコミットがすべて自動的にすべての環境へスムーズに展開されると期待してしまいます。 00:12:41.520 --> 00:12:43.320 そこで現実に直面するのです。 00:12:43.520 --> 00:12:50.860 GitHub Actionsは、単にスクリプトを実行するのではなく、トリガージョブ、そして環境間の引き渡しに基づいた論理チェーンを使用します。 00:12:51.100 --> 00:12:56.840 その順序と構造こそが、デプロイが失敗の手順や奇妙なエラーの絡まり合いになるのを防ぐものです。 00:12:57.000 --> 00:12:59.320 このシステムの出発点はトリガーです。 00:12:59.720 --> 00:13:07.500 初心者の多くは、すべてのプッシュやプルリクエストがメインブランチにマージされるたびに実行されるワークフローを作成します。 00:13:07.720 --> 00:13:10.180 表面上は、それがベストプラクティスのように見えます。 00:13:10.340 --> 00:13:12.600 変更のたびにパイプラインを実行して何が悪いのでしょうか。 00:13:12.700 --> 00:13:13.820 ここに落とし穴があります。 00:13:14.040 --> 00:13:16.980 メインブランチにのみトリガーを設定すると、すべてが単一の経路に集約されてしまいます。 00:13:17.140 --> 00:13:21.060 もし、テスト環境や本番環境ではなく、開発環境だけに反映させたい変更がある場合はどうなるでしょうか。 00:13:21.180 --> 00:13:25.000 もし、本番環境へプッシュする準備ができていても、テスト環境で検証がまだ終わっていない場合はどうなるでしょうか。 00:13:25.120 --> 00:13:34.880 万能なトリガーに固執するチームは、開発環境向けの機能が本番環境に紛れ込んだり、テストのデプロイが本番設定を上書きしてしまったりする問題に直面しがちです。 00:13:34.880 --> 00:13:42.140 ワークフローを開発、テスト、本番の各環境向けに分岐させ、それぞれに非常に具体的なトリガーを設定することができます。 00:13:42.320 --> 00:13:50.300 例えば、開発ブランチへのプッシュ時のみ実行するワークフローを設定したり、本番リリースへのマージ時に別のワークフローを実行したりします。 00:13:50.480 --> 00:13:58.580 このアプローチにより管理能力が高まり、作業中の変更と本番の変更との間に明確な境界線が生まれますが、多くのチームはトリガーを作成した後に見直すことをしません。 00:13:58.640 --> 00:14:05.560 そうすることで、ある環境のシークレットが別の環境に漏れたり、開発用設定が誤って本番環境に入り込んだりします。 00:14:05.760 --> 00:14:10.660 私が以前一緒に仕事をしたチームは、単一のワークフローで全てのアルムプロセスを実行しようとしていました。 00:14:10.880 --> 00:14:17.720 しばらくは問題ないように見えましたが、ある時、本番データベースの接続文字列が開発環境に表示されていることに誰かが気づきました。 00:14:17.880 --> 00:14:21.260 彼らは、シークレットがジョブ間で共有されていることに気づいていなかったのです。 00:14:21.340 --> 00:14:24.660 そしてコードが環境間を移動すると、それらのシークレットも一緒に漏えいしてしまいました。 00:14:24.820 --> 00:14:26.740 それは明らかなクラッシュやエラーではありませんでした。 00:14:26.920 --> 00:14:28.520 密かに進行するものだったのです。 00:14:28.520 --> 00:14:35.120 特にシークレットと環境変数を分離するようにワークフローを設定していない場合、こうしたデータ漏えいは予想以上に頻繁に起こります。 00:14:35.320 --> 00:14:39.760 GitHub Actions Workflowの各ジョブは、プロセスの一部を明確に処理します。 00:14:39.960 --> 00:14:52.120 あるジョブはソース環境からのソリューションのエクスポートを担当し、別のジョブが検証、展開、ソリューションメタデータのスキャン、依存関係のチェック、コネクタ参照の存在確認を行います。 00:14:52.120 --> 00:14:58.840 次に、環境固有の変数を準備し、ソリューションをターゲット環境に合わせて変換するジョブが実行されます。 00:14:59.040 --> 00:15:04.900 最後のジョブがサービスプリンシパルを使用してインポートプロセスを開始し、変更を適切な環境に書き込みます。 00:15:05.060 --> 00:15:12.060 環境変数やシークレットを単なるプレースホルダーと考えるかもしれませんが、実際にはそれらがすべてをつなぎ止める接着剤なのです。 00:15:12.060 --> 00:15:20.100 接続文字列、APIキー、共有パスワードなどはジョブ間で切り替える必要がありますが、境界を越えて漏えいすることは決して許されません。 00:15:20.100 --> 00:15:29.340 パワープラットフォームのARMでは、環境ごとに異なるデータバース接続が必要だったり、対象のフローやパワーアップに応じてエンドポイントを切り替える必要があったりします。 00:15:29.500 --> 00:15:36.780 変数を再利用したり、シークレットをハードコードしたりするとパイプラインが壊れやすくなるか、さらに悪いことに重大なセキュリティリスクを招くことになります。 00:15:36.940 --> 00:15:44.240 インポートプロセスは、適切な保管庫からのみシークレットを抽出することに依存しており、テストや開発でのミスによって本番環境が晒されることはありません。 00:15:44.240 --> 00:15:52.900 GitHub Actionsにおけるシークレットの適切なメンタルモデルは、各環境が独自のデジタル保管庫、つまり適切なジョブだけが見られるロックされた箱を持っていると考えることです。 00:15:53.060 --> 00:15:55.500 GitHubでは、きめ細かな制御が可能です。 00:15:55.700 --> 00:16:02.460 シークレットを環境ごとにスコープ設定できるため、開発環境で実行されるジョブが本番環境の視覚情報にアクセスすることはできず、その逆も同様です。 00:16:02.460 --> 00:16:09.780 これらの保管庫を設定しておけば、誰かがパイプラインを調整してリスクのある操作をしようとしても、環境保護ルールがミスの波及を防いでくれます。 00:16:09.920 --> 00:16:13.760 マイクロソフトとGitHubの両方のドキュメントで、この点が強調されています。 00:16:13.940 --> 00:16:20.160 環境間の漏洩を未然に防ぐために、環境保護ルールとシークレットの厳密なスコープ設定が推奨されています。 00:16:20.420 --> 00:16:24.800 そのような保護なしでは、どんなに優れたアルムワークフローも崩壊してしまいます。 00:16:24.800 --> 00:16:32.380 開発環境の接続文字列を保持したまま本番環境にデプロイするワークフローや、テスト環境から突然本番データにアクセスできてしまう状況を想像してみてください。 00:16:32.560 --> 00:16:35.160 必ずしも目に見える形で問題が起こるとは限りません。 00:16:35.340 --> 00:16:40.800 コンプライアンスの警告が鳴ったり、ログが微妙なエラーで埋め尽くされ、それが徐々に積み重なって大きな問題になることもあります。 00:16:41.020 --> 00:16:45.160 だからこそ、ワークフローの分岐やシークレットのスコープ設定は、単なる高度なトピックではないのです。 00:16:45.160 --> 00:16:48.940 これらは、自動化が人知れず破綻するのを防ぐためのセーフティネットです。 00:16:49.060 --> 00:16:53.760 ワークフローを環境ごとだけでなく、責任ごとに分割することにも価値があります。 00:16:54.020 --> 00:16:59.740 ソリューションをエクスポートして検証する高度は、デプロイやシークレットの切り替え方法を知るべきではありません。 00:16:59.920 --> 00:17:08.260 各ジョブがパズルのピースを一つずつ担当すれば、どこで問題が起きたかを特定し、ロールバックし、事後に変更を監査することがずっと容易になります。 00:17:08.260 --> 00:17:15.940 シークレットは保管庫に止まり、ジョブは明確にスコープされた権限に従いパイプラインが失敗した場合は修正が必要な箇所が直ちに判明します。 00:17:16.160 --> 00:17:22.900 GitHub Actionsがシークレットを厳密に管理し、トリガーを明確に定義した状態でジョブ間でどのように作業を引き継ぐかを理解することこそが、 00:17:23.240 --> 00:17:28.940 アルムを希望的観測に基づく実験から、信頼性と安全性、予測可能性を備えた実践へと昇華させます。 00:17:28.940 --> 00:17:33.700 このワークフローのセグメンテーションは、単にベストプラクティスに従うためのものではありません。 00:17:33.860 --> 00:17:42.520 これは、静かなセキュリティ漏洩や意図しない上書きをブロックし、目に見えないエラーが環境を悩ませ始める前に、それらを根元から断ち切るものです。 00:17:42.680 --> 00:17:49.020 適切にスコープされた自動化によって各パーツが連携できるようになった今、次の摩擦点に取り組む時が来ました。 00:17:49.180 --> 00:17:56.600 コネクタ、サービスプリンシパル、そして地震がついた途端にデプロイを停滞させてしまう、小さくも致命的な落とし穴について。 00:17:58.940 --> 00:18:05.500 またにまつわるトラブル。パワーアップやフローを開発環境から本番環境へ移行しようとしたことがある方なら、その苦労はよくご存知でしょう。 00:18:05.660 --> 00:18:12.880 一つの環境では完璧に動作していたのに、切り替えた途端、すべてが停止したり、謎の接続エラーが発生したりします。 00:18:13.080 --> 00:18:19.700 これは特定のチームだけに起こることではありません。すべてのパワープラットフォーム管理者が、いずれはこの壁にぶつかります。 00:18:19.940 --> 00:18:24.360 問題の根本は、裏側でのコネクタやシークレットの挙動にあります。 00:18:24.360 --> 00:18:32.820 開発環境からソリューションのジップをエクスポートしてそのまま他で動かそうとしても、依存する配線が環境ごとに変わるため、うまくいきません。 00:18:33.020 --> 00:18:35.200 まずはコネクタ参照から見ていきましょう。 00:18:35.360 --> 00:18:40.340 パワープラットフォームにおいて、コネクタは単なる固定の情報としてアプリに組み込まれるものではありません。 00:18:40.560 --> 00:18:43.900 それは動的で可変的であり、環境ごとに異なることがほとんどです。 00:18:44.080 --> 00:18:47.980 ソリューションをエクスポートする際、コネクタ参照はブックマークのような役割を果たします。 00:18:47.980 --> 00:18:52.720 それらは、作成された環境内にしか存在しない接続オブジェクトを指し示しているからです。 00:18:52.900 --> 00:19:00.880 そのため、テスト環境や本番環境にインポートしても、HTTPエンドポイントやデータバースへのリンクが同じように再作成されるとは限りません。 00:19:01.060 --> 00:19:02.840 ここでチームはつまずくのです。 00:19:03.040 --> 00:19:09.800 開発環境でコネクタがテストデータを使っており、その構成が本番環境で完全に再現されていなければ、 00:19:09.940 --> 00:19:15.740 フローやアプリは沈黙したまま失敗するか、接続の最初の思考でハングアップしてしまいます。 00:19:15.740 --> 00:19:20.920 多くの人は、環境間でユーザーの視覚情報を共有することでこれを回避しようとします。 00:19:21.080 --> 00:19:27.420 開発環境で接続を作成したのと同じアカウントやパスワードを使えば、本番環境でも動くのではないかと考えるのです。 00:19:27.600 --> 00:19:32.700 しかし実際には、これは権限拒否からコンプライアンス監査のトリガーまで多くの問題を引き起こします。 00:19:32.880 --> 00:19:39.040 マイクロソフトのガイダンスは明確で、自動デプロイに個人のユーザー視覚情報を使用することは、実行可能でも安全でもありません。 00:19:39.040 --> 00:19:44.400 これでは自動化がパスワードリセットの影響を受けてしまい、監査ログに曖昧な記録を残すことになります。 00:19:44.620 --> 00:19:53.160 明確な説明責任がなく、元のユーザーがフラグを立てられたり、削除されたり、アクセス権を失ったりすると、最終的に権限によってパイプラインがブロックされます。 00:19:53.340 --> 00:19:55.480 そこで登場するのがサービスプリンシパルです。 00:19:55.700 --> 00:20:01.500 まだ使ったことがないなら、サービスプリンシパルを自動化専用のデジタルの手だと考えてみてください。 00:20:01.500 --> 00:20:08.640 通常のユーザーとは異なり、サービスプリンシパルは実在の人物ではなく、Azure Adのアプリ登録に紐付いています。 00:20:08.880 --> 00:20:12.340 デプロイ作業に必要な最小限の権限だけを与えるのです。 00:20:12.520 --> 00:20:15.040 単純に聞こえますが、その恩恵は絶大です。 00:20:15.220 --> 00:20:22.120 組織を去る可能性や役割が変わる可能性のあるユーザーに頼るのではなく、デプロイの一貫性、監査可能性、追跡可能性を維持できるようになります。 00:20:22.260 --> 00:20:28.560 各環境は適切な接続とリソースにのみアクセスでき、あらゆる変更がロボットアカウントの下で記録されます。 00:20:31.500 --> 00:20:34.440 また、修正不能な孤立したフローが残ることもありません。 00:20:34.600 --> 00:20:40.120 コネクタのマッピング問題については、環境間に乖離が生じた場合を考えてみてください。 00:20:40.320 --> 00:20:43.460 開発チームが新しいカスタムコネクタの承認を得たとします。 00:20:43.720 --> 00:20:46.380 それがサンドボックスAPIに接続されるとしましょう。 00:20:46.560 --> 00:20:52.740 本番環境へ移行する際、そのコネクタは単に不足しているだけでなく、組織のデータポリシーで許可されていない可能性もあります。 00:20:53.020 --> 00:20:58.080 再マッピングを忘れると、アプリは誤ったエンドポイントを呼び出すか、完全に機能しなくなります。 00:20:58.080 --> 00:21:01.640 最近、ある医療グループでこれが深刻な事態を招くのを目の当たりにしました。 00:21:01.800 --> 00:21:07.260 コネクタのマッピング漏れが原因で本番環境でテストデータが使用され、コンプライアンス上の重大事故になりかけました。 00:21:07.480 --> 00:21:14.720 自動化されたパイプラインは予定通りエクスポートされましたが、ソリューション内のコネクタ参照は古いテストデータベースを指したままでした。 00:21:14.840 --> 00:21:19.780 パワープラットフォームがそれを警告したのは、誤った経路に実際のデータが流れ始めてからでした。 00:21:19.960 --> 00:21:23.300 環境変数を使えば、こうした苦労をいくらか軽減できます。 00:21:23.520 --> 00:21:30.660 エンドポイントやAPIキーをハードコーディングするのと異なり、環境変数なら環境ごとに変化する要素と固定の要素を分離できます。 00:21:30.660 --> 00:21:37.600 アプリやフローを書き直すことなく、デプロイの度にエンドポイント、APIキー、その他のシークレットを入れ替えられます。 00:21:37.760 --> 00:21:47.480 例えば、開発用のデータバーステーブルを使用するフローを、デプロイプロセス内で環境変数を変えるだけで、インポート時に本番テーブルを使うように再構成できます。 00:21:47.480 --> 00:21:50.560 GitHub Actionsのパイプラインがこれを実用的なものにします。 00:21:50.740 --> 00:21:53.800 各ジョブが適切なタイミングで適切な値を注入できるからです。 00:21:53.980 --> 00:21:56.100 しかし、ここでも規律が重要です。 00:21:56.100 --> 00:22:02.860 変数の更新を忘れたり、シークレットが環境間で漏えいしたりすれば、ワークフローは即座に危険にさらされます。 00:22:03.020 --> 00:22:09.220 マイクロソフトは、シークレットの範囲を慎重に設定し、意図を持ってコネクタ参照をマッピングする必要性を強調しています。 00:22:09.420 --> 00:22:12.880 DLP、データ損失防止、ポリシーには理由があります。 00:22:12.880 --> 00:22:18.560 機密情報が環境間を流出したり、不適切な場所で表示されたりするのを防ぐためです。 00:22:18.700 --> 00:22:26.280 変数や接続を共有してこれを回避しようとすれば、企業のセキュリティやコンプライアンス管理に抵触することになります。 00:22:26.540 --> 00:22:33.300 さらに重要なのは、開発用、テスト用、本番用という境界線が曖昧になり、予測可能性が失われることです。 00:22:33.440 --> 00:22:36.700 これらをすべて正しく管理できた場合のメリットは計り知れません。 00:22:36.700 --> 00:22:42.620 サービスプリンシパルを適切に管理された環境変数やコネクタマッピングと組み合わせることでパイプラインは劇的に変わります。 00:22:42.820 --> 00:22:44.780 デプロイメントが予測可能なものになります。 00:22:44.980 --> 00:22:49.140 障害が発生しても明確な管理責任の所在があり、どこを確認すべきかが正確にわかります。 00:22:49.300 --> 00:22:52.640 コネクタのマッピングか、変数か、それとも権限の不要漏れか。 00:22:52.780 --> 00:22:57.800 監査人は変更を追跡でき、誰かが退職したりパスワードを変更したりしても不安を感じることはありません。 00:22:57.800 --> 00:23:02.580 結局のところ、シークレット、コネクタ、サービスプリンシパルを重要視して扱うことに尽きるのです。