ぶれない パイプラインの構築: Power Platform デプロイを段階ごとに進める方法

By Mirko Peters · 2026-08-11

ポッドキャストブログへようこそ。重要な Power Platform のデプロイが、接続参照の破損、期限切れのシークレット、環境変数の欠落などで突然止まり、痛い思いをしたことがある方は少なくないはずです。ローコードとプロコードのソリューションを環境間で移行する作業は、地雷原を歩くように感じられることもあります。しかし、そうである必要はありません。

Automatically translated with AI from the original post. Read the English original

ポッドキャストブログへようこそ。重要な Power Platform のデプロイが、接続参照の破損、期限切れのシークレット、環境変数の欠落などで突然止まり、痛い思いをしたことがある方は少なくないはずです。ローコードとプロコードのソリューションを環境間で移行する作業は、地雷原を歩くように感じられることもあります。しかし、そうである必要はありません。

今回は、Power Platform のソリューション向けに特化した、堅牢な多段階の Azure DevOps パイプラインを構築する方法を詳しく見ていきます。この記事は、最近のエピソードで取り上げた中核的な概念を掘り下げたものです。音声による解説や、実際の現場での体験談をさらに聴きたい場合は、関連エピソードの Implement Power Platform CI/CD with Azure DevOps をぜひご覧ください。

それでは、成功への設計図を順に見ていきましょう。

TL;DR

• ソリューションの ZIP がすべてを含むわけではありません。テーブル、アプリ、フローは含まれますが、環境変数はプレースホルダーであり、接続参照は各ターゲット環境で再バインドする必要があります。
• Azure DevOps を使い、環境ごとにサービス接続を設定し、シークレットは Key Vault で管理し、値のハードコーディングを避けるためにパラメーター化された変数を使用してください。
• パイプラインの構成は次のとおりです。成果物としてエクスポートし、マネージドとしてインポートし、環境変数を設定し、接続をマッピングし、スモーク テストを実行し、通知を送り、必要に応じてロールバックします。
• 監視とフィードバックのループを追加して、リリースのたびに安全性と速度が向上するようにしましょう。

ソリューションに含まれるもの、含まれないもの

自動化されたワークフローを設計する前に、Dataverse のソリューション パッケージに実際に何が含まれているかを明確に理解しておく必要があります。圧縮アーカイブの中にすべてが入っているわけではありません。それを前提にすると、デプロイが壊れる最も早い方法の一つになります。

• 含まれるもの: Dataverse のテーブルと列、モデル駆動型アプリとキャンバス アプリ、フロー、ビジネス プロセス フロー (BPF)、プラグイン、Web リソース。
• プレースホルダー: 環境変数。これらはプレースホルダーとして機能し、環境ごとに特定の値を設定する必要があります。
• ポインター: 接続参照。基盤となるコネクタを参照しますが、ターゲット環境で実際に動作する接続にマッピングする必要があります。
• 含まれないもの: シークレットと資格情報、環境固有のエンドポイントや ID、参照データやルックアップ データ。後者は Configuration Migration tool を使って別途移行する必要があります。

Azure DevOps に必要な構成要素

シームレスなデプロイを実現するには、Azure DevOps 内で適切なツールを正しく構成する必要があります。これらの基本要素を早い段階で設定しておくと、後々のセキュリティ上の問題を防げます。

• サービス接続 (Power Platform): 最小特権の原則に従い、各ターゲット環境に厳密にスコープを限定します。
• 変数グループ: 環境ごとの URL、ID、機能フラグを保存します。クライアント シークレットやサービス プリンシパルのパスワードなどの機密情報は、Azure Key Vault とセキュアにリンクしてください。
• 成果物: エクスポートおよびビルドに成功したソリューション パッケージをすべて保持しておくと、ロールバック時に確実に正常な状態へ戻せます。
• 承認とゲート: コードを本番環境に反映する前に、手動の確認や自動の品質ゲートを実装してください。

参照用パイプラインの設計図 (ステージ)

成熟した CI/CD パイプラインは、明確で論理的なステージに分けて構成する必要があります。ここでは、開発から本番までパイプラインがどのように流れるべきかを示します。

1. ビルド
   • 開発環境から非マネージド ソリューションをエクスポートします。
   • 必要に応じて、上位の環境向けにマネージドとして変換またはエクスポートします。
   • 自動化された Solution Checker を実行し、構造上の問題を早期に検出します。
2. パッケージ化
   • 適切なバージョン管理とタグ付けを行い、ソリューション ZIP をパイプライン成果物として公開します。
3. TEST/PROD へのデプロイ
   • マネージド ソリューション パッケージをインポートします。
   • ターゲットごとの値を環境変数に設定します。
   • 接続参照を、ターゲット環境の実際の接続にマッピングします。
   • 主要なフローの起動、中核となるアプリの表示、API への ping による検証など、スモーク テストを実行します。
   • Microsoft Teams またはメールでチームに通知します。いずれかのエラーでパイプラインが素早く失敗するようにしてください。
4. デプロイ後
   • スケジュールを有効にし、サービスをウォームアップして、受信するテレメトリを監視します。
   • スモーク テストが失敗した場合に備えて、直前の正常なアーティファクトにワンクリックで戻せるロールバックの仕組みを用意します。

変数とシークレットの戦略

値をハードコーディングすることは、現代の DevOps では明確なアンチパターンです。戦略としては、パラメーター、変数グループ、安全なキー コンテナーを適切に組み合わせて使うべきです。

• パラメーター: environment、targetEnvUrl、solutionName、connectionRefNames[] などのパラメーターを使うと、YAML テンプレートを再利用しやすくなります。
• 変数グループ: 環境ごとに専用のグループを作成し、ApiBaseUrl、TenantId、DataverseUrl、機能フラグなど、機密ではない構成値を格納します。
• Key Vault: ServicePrincipalSecret やサードパーティ API キーなどの機密情報は安全に保管します。こうしておけば、パイプラインの YAML ファイルを編集せずにシークレットをローテーションできます。

接続参照のマッピング（必須）

Power Platform のデプロイで最もよくある落とし穴の一つが、接続参照のバインドを忘れることです。ソリューションを対象環境にインポートした後は、すべての接続参照を、その特定の環境に実際に存在し、承認されている有効な接続にバインドする必要があります。このプロセスは、Power Platform CLI（PAC CLI）または、環境スコープの変数に紐づけた PowerShell 管理スクリプトを使って自動化してください。

データと構成の移行

ソリューションにはメタデータとロジックが含まれますが、セキュリティ ロール、構成レコード、ルックアップ テーブルなどの参照データはどうすればよいでしょうか。参照データやルックアップ データは、構成移行ツールまたはパッケージ デプロイヤーを使って配布してください。読み込み順序は厳密に守り、親テーブルを子テーブルより先に読み込みます。そして、読み込み直後に行数とルックアップの整合性を検証してください。

重要なスモーク テスト

デプロイが正常に完了したからといって、アプリが実際に動作しているとは限りません。デプロイ タスクが完了した直後に、次の自動スモーク テストを実装してください。

• 合成ペイロードを使って重要なクラウド フローを実行し、成功と期待される出力を検証します。
• テスト用の Dataverse レコードを作成または更新し、ビジネス プロセス フローとプラグインが正しく動作したかを確認します。
• 環境固有のエンドポイントに対してカナリア API 呼び出しを実行し、200 OK のステータス コードと正しい応答ペイロードの形式を検証します。

ロールバックと復旧

願うだけでは戦略になりません。本番環境でデプロイがうまくいかなかった場合に備えて、自動化された安全策が必要です。以前のマネージド ソリューション ZIP を Azure DevOps のアーティファクトとして保持し、失敗時のタスクが直前の正常なバージョンを自動で再インポートできるようにしてください。ロールバックを開始する前には、必ずアクティブなトリガーとスケジュールを無効にし、検証が成功した後にのみ再度有効にしてください。

最小構成の YAML スケルトン（概念）

パイプラインの YAML は、数千行にする必要はありません。環境名とソリューション名のパラメーター、環境固有の構成のための変数グループ、そして順番に実行されるタスク（マネージド ソリューションのエクスポート、公開、インポート、環境変数スクリプトの実行、接続のマッピング、スモーク テストの実行、通知の送信）に絞ると、モジュール化されてすっきりした構成になります。

事前チェックリスト

最後のデプロイ ボタンを押す前に、次のチェックリストで問題なく進められるかを確認してください。

• ✅ Solution Checker で重大な問題がゼロであること。
• ✅ 環境変数がすべて文書化されており、対象環境の値が設定されていること。
• ✅ 対象の接続が存在し、サービス接続が承認されていること。
• ✅ 参照データ パッケージの準備ができていること。
• ✅ ロールバック用のアーティファクトが正常に保存され、利用可能であること。
• ✅ 本番環境向けのメンテナンス時間帯と管理者の承認が確定していること。

避けるべきアンチパターン

他者の失敗から学び、次のような悪い習慣が開発ライフサイクルに入り込まないようにしてください。

• URL、資格情報、シークレットを YAML ファイルやクラウド フローに直接ハードコーディングすること。
• 「開発環境では動いていた」という危険な思い込みから、接続のマッピングを省略すること。
• 確実なロールバック計画がないまま、マネージド ではないソリューションを本番環境に直接展開すること。
• 本番環境で手動による構成変更を直接行い、構成ドリフトを招くこと。
• 「すべてを追加」で作った、構造的な階層化のない巨大なモノリシック ソリューションを構築すること。

すぐに効果が出る施策（今週中）

デプロイ戦略を一晩で全面的に書き直す必要はありません。今週中に、次のクイック ウィンから一つか二つを選んで実施してください。

• 環境ごとに専用の変数グループを作成し、Azure Key Vault にリンクします。
• 既存のデプロイパイプラインに、基本的な接続マッピングと環境変数の更新スクリプトを追加します。
• ソリューションの ZIP をバージョン管理されたパイプライン成果物として保存し、基本的なロールバックタスクをスクリプト化します。
• 最も重要で価値の高いクラウドフローを対象とした、単一のスモークテストを追加します。

よくある質問

TESTとPRODで別々のパイプラインが必要ですか？

必ずしもそうではありません。通常は単一のマルチステージパイプラインで十分です。ただし、本番ステージには厳格な手動承認、専用の変数グループ、保護されたブランチポリシーを設けて制御してください。

手動での接続設定は永久に避けられますか？

バインディングのプロセスは完全に自動化できます。ただし、基になる接続自体は各ターゲット環境に存在している必要があります。通常は管理者が一度作成し、その後は参照して使用します。

上位環境へは管理ソリューションと非管理ソリューションのどちらを展開すべきですか？

TESTおよびPRODの環境では、必ず管理ソリューションを使用してください。環境の階層を明確に保ち、簡単にアンインストールでき、予測可能でエラーのないソリューションのアップグレードを実現できます。

堅牢な Power Platform パイプラインを構築するには、事前の計画が必要ですが、デプロイの速度、システムの安定性、開発者の作業効率という長期的な成果は十分に価値があります。これらの戦略をさらに詳しく知りたい方は、関連するポッドキャストエピソードImplement Power Platform CI/CD with Azure DevOpsもぜひお聴きください。それでは次回まで、自動化を続けて、自信を持ってデプロイしてください！