プレイブック

プルリクエストをマージする前に、コード品質（ビルド、テスト、カバレッジ）を強制する。

→ターゲットブランチで、PR作成時にパイプラインをトリガーするビルド検証ポリシーを設定します。パイプラインはコードカバレッジの結果を公開する必要があります。最小カバレッジのブランチポリシーを設定します。

理由: これにより、マージ前に品質が強制されます。標準のCIトリガーはマージ後に実行されます。リリースゲートはデプロイ用であり、PR用ではありません。

マージの競合を最小限に抑え、本番環境への迅速かつ継続的なデプロイをサポートするGitブランチ戦略を選択する。

→短命のフィーチャーブランチが頻繁に（毎日またはそれ以上）`main`にマージされるトランクベース開発を実装します。

理由: ブランチが大幅に分岐するのを防ぎ、マージの競合を減らし、`main`ブランチが常にリリース可能な状態に近いことを保証します。

マージ前にコードレビュー、成功したビルド、作業項目リンクを強制することにより、重要なブランチ（例：`main`）を保護する。

→Azure Reposの`main`ブランチでブランチポリシーを構成します。最小レビュアー、ビルド検証、作業項目リンクのポリシーを有効にします。

理由: ブランチポリシーは、開発者がバイパスできないサーバーサイドの強制を提供し、一貫した品質とプロセスコンプライアンスを保証します。

スケジュールされたリリース、並行フィーチャー開発、および専用のホットフィックスブランチの必要性があるチーム向けのGitブランチ戦略を選択する。

→`main`、`develop`、`feature/*`、`release/*`、`hotfix/*`ブランチを使用するGitFlowブランチモデルを実装します。

理由: GitFlowは、複雑なリリースサイクルを管理するための堅牢なフレームワークを提供し、新しい開発をリリース安定化および緊急修正から分離します。

シークレットが誤ってコミットされ、プッシュされた。Gitの履歴から完全に削除する必要がある。

→まず、公開されたシークレットをローテーションします。次に、`git-filter-repo`やBFG Repo-Cleanerのようなツールを使用して履歴を書き換え、ファイルを削除します。変更を強制プッシュし、すべての開発者に再クローンするよう通知します。

理由: 単純な`git rm`や元に戻すだけでは、履歴からシークレットは削除されません。永続的なパージには履歴の書き換えが必要です。

並列ステージとステージ間の依存関係を持つ複雑なワークフローをモデル化する。

→YAMLマルチステージパイプラインを使用します。ステージの依存関係には`dependsOn`キーワードを使用し、ステージ内で並列ジョブを設定します。

理由: YAMLは、複雑なオーケストレーションに対して最も柔軟なコードベースのアプローチを提供し、従来のパイプラインや個別のパイプラインを連結する方法よりも優れています。

即時ロールバック機能を備えたWebアプリに対して、ダウンタイムゼロで低リスクなデプロイを実装する。

→Azure App Serviceのデプロイメントスロットを使用します。ステージング（グリーン）スロットにデプロイし、検証後、運用（ブルー）スロットとスロットスワップを実行します。

理由: スロットスワップは、トラフィックをリダイレクトするアトミックでほぼ瞬時の操作です。ロールバックは、スワップバックするのと同じくらい簡単です。

リファレンス↗

共通のビルド/デプロイ手順を共有しつつ、特定のカスタマイズが必要な多数のマイクロサービスに対して、パイプラインの重複を最小限に抑える。

→中央リポジトリにYAMLテンプレートを作成します。各サービス固有のパイプラインで、`extends`キーワードを使用し、カスタマイズ用のパラメーターを渡します。

理由: `extends`はDRY原則を促進し、パラメーターを通じて柔軟性を許容しながら標準を強制します。パイプライン全体の構造に対しては、タスクグループよりも強力です。

パイプラインステージ（例：本番デプロイ）を、特定のブランチ（例：main）へのマージ時のみ実行されるように制限する。

→ステージまたはジョブに`condition`を使用します。例：`condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`。

理由: PR検証ビルドは異なるソースブランチ参照（例：`refs/pull/...`）を使用するため、この条件によりPRライフサイクル中のデプロイが正しく防止されます。

企業ファイアウォールの内側にあるオンプレミスサーバーに、Azure DevOpsからアプリケーションをデプロイする。

→オンプレミスサーバーにセルフホステッドエージェントをインストールします。それらをAzure DevOpsのエージェントプールに登録します。

理由: セルフホステッドエージェントはAzure DevOpsへのアウトバウンド通信を開始するため、インバウンドファイアウォールルールは不要です。デプロイのためにローカルネットワークリソースにアクセスできます。

本番デプロイに複数人による承認を要求し、特定のメンテナンス時間枠に制限する。

→本番環境用にAzure DevOps Environmentを定義します。必要な承認者で承認を設定します。時間枠を強制するためのゲートとして「営業時間」チェックを追加します。

理由: 環境はデプロイ制御を一元化します。承認とゲートは、ステージが実行される前に堅牢で自動化されたポリシーの強制を提供します。

アプリケーションを再デプロイすることなく、ユーザーへの機能公開を制御し、ほぼリアルタイムで更新する。

→機能管理にAzure App Configurationを使用します。アプリケーションにフラグを読み取る計測を施し、その動的なリフレッシュ機能を有効にします。

理由: 機能リリースをデプロイから切り離します。App Configurationは、アプリケーションの再起動を避けながら、動的な更新のための一元化されたUIとSDKを提供します。

Gitを唯一の真実のソースとし、変更が自動的に適用される、宣言的なKubernetesクラスターの状態管理を行う。

→FluxやArgoCDのようなGitOpsエージェントをAKSクラスターにデプロイします。エージェントを構成して、Kubernetesマニフェストを含むGitリポジトリを監視し、クラスターの状態を自動的に同期させます。

理由: このプルベースのモデルは、GitOpsの中核である継続的な調整とドリフト検出を可能にします。プッシュベースの`kubectl`パイプラインよりも堅牢です。

チームコラボレーションのためにTerraformステートを管理し、セキュリティを確保し、同時変更を防止する。

→TerraformのバックエンドをAzure Storage Accountを使用するように設定します。これによりリモートステートストレージが提供され、ステートロックはAzure Blobリースを介して処理されます。

理由: 同時実行される`apply`操作によるステートファイルの破損を防ぎ、機密性の高いステートデータをソース管理から除外します。

リファレンス↗

モノレポにおいて、特定のディレクトリ（または共有ディレクトリ）内のファイルが変更された場合にのみ、アプリケーションのCIパイプラインをトリガーする。

→パイプラインのYAMLで、`trigger.paths.include`フィルターを使用して関連ディレクトリを指定します。例：`include: ['/apps/frontend/**', '/apps/shared/**']`。

理由: これにより、無関係なコード変更による不要なビルドが回避され、CI時間とコンピューティングリソースを節約できます。

迅速なフィードバックのために、高速（単体）テストと低速（結合）テストの両方を含むテストステージを最適化する。

→同じステージ内で、単体テストと結合テストを並列ジョブで実行します。

理由: 並列実行により、低速テストが同時に実行されている間に単体テストの結果がはるかに速く提供されます。ステージ全体の期間は、合計ではなく最長のジョブによって決定されます。

コミット履歴に基づいてライブラリパッケージを自動的にバージョン管理し、変更の影響（破壊的、機能、修正）を明確に伝える。

→GitVersionのようなツールをCIパイプラインに統合します。これにより、コミットメッセージ、ブランチ、タグを分析してSemVer（Major.Minor.Patch）バージョンを自動的に計算します。

理由: SemVerは、ビルド番号やコミットハッシュとは異なり、コンシューマーが依存関係管理に信頼できる意味のあるバージョン管理を提供します。

アプリケーションを複数の地理的リージョンに1つずつデプロイし、各リージョンデプロイ後に検証を行う。

→`dependsOn`を使用して順序を強制する、リージョンごとに1つのシーケンシャルステージを持つマルチステージYAMLパイプラインを使用します。検証のためにステージ間に環境ゲートを使用します。

理由: このリングベースのデプロイモデルは、単一リージョンへの不良デプロイメントの爆風半径を抑え、すべてのユーザーに影響を与える前にロールバックを可能にします。

trunk-based developmentモデルをサポートするパイプラインを構成し、mainブランチが常にデプロイ可能であることを保証する。

→`main`ブランチにCIトリガーを設定します。高速で包括的なテストを実行するビルド検証ポリシーを持つPRを強制します。ビルドの破損に対して迅速な通知（例：Teams/Slackへの通知）を統合します。

理由: トランクベース開発では即時のフィードバックが不可欠です。この組み合わせにより、破損したコードのマージを防ぎ、問題が発生した際に迅速な修正を保証します。

パイプラインステージ間で大規模なアーティファクト（例：MLモデル、5GB超）を効率的に渡す。

→プロデューサーステージで大規模なアーティファクトをAzure Blob Storageにアップロードします。ブロブURIをコンシューマーステージに出力変数として渡します。

理由: Azure Blob Storageは、数ギガバイトのファイルに対して、組み込みのパイプラインアーティファクトよりもコスト効率が高く、パフォーマンスに優れています。

実行ごとに依存関係（例：NuGet、npm）を再ダウンロードするのを避けてビルド時間を短縮する。

→`Cache@2`タスクを使用します。パッケージロックファイル（例：`packages.lock.json`）に基づいてキーを定義します。このタスクは依存関係フォルダを保存および復元します。

理由: 外部リポジトリから取得する代わりに、高速なローカルキャッシュから復元することで、ビルドごとに数分を節約できます。

同じコードを複数のターゲット（例：異なるOS、リージョン）に対して並行してビルドまたはデプロイする。

→YAMLパイプラインジョブで`strategy: matrix`を使用します。各組み合わせの変数を定義し、これにより各マトリックスエントリに対してジョブが生成されます。

理由: マトリックス戦略はパイプライン定義をDRYに保ち、単一の定義から複数のジョブバリエーションを作成し、それらを並列で実行します。

AKS上で、リアルタイムメトリクスに基づいてトラフィックを自動的にシフトし、昇格またはロールバックするカナリアデプロイメントを実装する。

→Flaggerのようなプログレッシブデリバリーコントローラーを、サービスメッシュ（例：Istio）およびメトリクスプロバイダー（例：Prometheus）と統合して使用します。

理由: Flaggerはカナリア分析プロセス全体を自動化し、手動スクリプトよりも安全で信頼性の高いプログレッシブデリバリーを提供します。

アプリケーションのパイプラインは、自身のリポジトリまたは別の共有ライブラリリポジトリのコードが変更されたときにトリガーされる必要がある。

→アプリケーションのYAMLで、`resources.repositories`の下に共有ライブラリを定義し、そのリソースに`trigger`ブロックを構成します。

理由: リポジトリ間に宣言的な依存関係を作成し、アプリケーションが常に最新の共有コンポーネントで再構築されることを保証します。

パイプラインがテスト用の一時的なインフラストラクチャを作成し、テストが失敗した場合でも後で破棄されるようにする必要がある。

→IaC（Terraform/Bicep）用に、適用ステージと破棄ステージを分けたマルチステージパイプラインを使用します。破棄ステージを`condition: always()`で構成します。

理由: `always()`条件により、前のステージの成功または失敗にかかわらずクリーンアップステージが実行されることが保証され、孤立したリソースの発生を防ぎます。

ServiceNowのようなITSMツールで承認された変更リクエストがない限り、本番デプロイが進まないようにする。

→「Query ServiceNow」ゲートを呼び出して変更リクエストのステータスを確認する環境ゲートを構成します。

理由: エンタープライズの変更管理プロセスとの統合を自動化し、手作業なしでコンプライアンスを保証します。

需要に応じて動的にスケールし、キュー時間を短縮しコストを管理するセルフホステッドビルドエージェントのプールを提供する。

→保留中のジョブの数に基づいて自動的にスケーリングするように設定されたAzure Virtual Machine Scale Set (VMSS) を使用して、Azure DevOpsエージェントプールを構成します。

理由: VMSSエージェントは、セルフホステッドエージェントのカスタマイズ性とクラウドホステッドエージェントの弾力性を組み合わせ、パフォーマンスとコストを最適化します。

データ損失を防ぎ、ロールバックをサポートする方法でデータベーススキーマの変更をデプロイする。

→移行ツール（例：Flyway、DbUp）を使用します。スキーマ変更に拡張/縮小パターンを実装して、下位互換性を維持します。

理由: 移行ツールはバージョン管理と制御を提供します。拡張/縮小パターンは、アプリケーションとデータベースのロールバックを分離し、より安全なデプロイを可能にします。

セルフホステッドエージェントが、蓄積されたビルドアーティファクトによってディスク容量不足になっている。

→パイプラインのYAMLで、ジョブレベルで`workspace: clean: all`を構成します。

理由: この予防的なパイプライン構成は、手動介入や継続的なインフラ変更を必要とせずに根本原因を解決します。

結合テストでは、パイプライン実行ごとに分離されたデータベースインスタンスが必要である。

→パイプラインYAMLでコンテナリソース（例：SQL Server、Postgres）をサービスとして定義します。その後、テストジョブはこの一時的なサービスに接続できます。

理由: テスト用に高速で隔離され、自動的にクリーンアップされる依存関係を提供し、テストの干渉を防ぎ、セットアップを簡素化します。

パブリックリポジトリ（例：npmjs、nuget.org）からのパッケージ復元の信頼性とパフォーマンスを向上させる。

→Azure Artifactsでフィードを作成し、パブリックリポジトリを指すアップストリームソースを構成します。クライアントがAzure Artifactsフィードからパッケージを消費するようにします。

理由: フィードはアップストリームソースからのパッケージをキャッシュし、パブリックリポジトリの障害から保護し、頻繁に使用されるパッケージの復元を高速化します。

異なる構成値でHelmチャートを複数の環境（開発、本番）にデプロイする。

→各環境に個別の`values-<env>.yaml`ファイルを使用します。`HelmDeploy`タスクで、`valueFile`入力を使用して適切なファイルを指定し、`overrideValues`を使用してイメージタグなどの動的な値を注入します。

理由: このパターンは、静的な環境設定と動的なパイプライン変数を分離し、デプロイをクリーンで保守しやすい状態に保ちます。

パイプラインでシークレット（例：接続文字列）をハードコーディングせずに、安全に管理および使用する。

→Azure Key Vaultにシークレットを保存します。Azure DevOpsで、Key Vaultにリンクされた変数グループを作成します。パイプライン内で変数グループからシークレットを参照します。

理由: シークレット管理を一元化し、パイプラインの変更なしにローテーションを可能にし、Key Vaultを通じて堅牢なアクセス制御と監査を提供します。

CIパイプラインにセキュリティスキャンを実装し、アプリケーションコード（SAST）およびサードパーティの依存関係（SCA）の脆弱性を検出する。

→複数のスキャナーを含むMicrosoft Security DevOps拡張機能を統合します。ネイティブで包括的なスイートとしてGitHub Advanced Security for Azure DevOpsも検討してください。

理由: この「シフトレフト」アプローチにより、開発ライフサイクルの早い段階で脆弱性を特定し、コストとリスクを削減できます。

開発者の本番環境へのアクセスを制限して直接的な変更を防ぎつつ、監査された緊急アクセスを許可する。

→恒久的な共同作成者/所有者ロールを削除します。デプロイにはパイプラインのService Connectionを使用します。緊急時には、Azure AD Privileged Identity Management (PIM) を使用して、Just-In-Time (JIT) の昇格されたアクセスを提供します。

理由: PIMは、最小権限の原則に従い、時間制限付きで承認ゲートを通過し、完全に監査された昇格されたアクセスを提供します。

AKS内のマイクロサービスにシークレットを安全に提供し、自動ローテーションとワークロード固有のアクセスを可能にする。

→Secrets Store CSI Driver for AKSと統合されたAzure Key Vaultを使用します。PodのワークロードIDを使用してKey Vaultに認証します。

理由: Key VaultからPodに直接シークレットをマウントし、Kubernetes Secretsを回避します。PodレベルのIDとシームレスなシークレットローテーションを可能にします。

リファレンス↗

スキャンされ署名されたコンテナイメージのみが本番Kubernetesクラスターにデプロイされるように強制する。

→イメージ署名にはAzure Container Registry (ACR) のコンテンツトラストを使用します。スキャンにはMicrosoft Defender for Containersを使用します。AKSでポリシーを強制するにはAzure Policy for Kubernetesを使用します。

理由: ビルドからランタイムまで、コンテナイメージセキュリティのための包括的でポリシー駆動型の多層防御戦略を提供します。

クライアントシークレットや証明書を使用せずに、Azure PipelinesをAzureリソースに接続する。

→「Workload Identity Federation」を使用してAzure Resource Managerサービス接続を作成します。

理由: シークレットの管理とローテーションの必要性を排除し、CI/CDシステムのセキュリティ態勢を向上させます。

シークレットを交換することなく、Azure DevOps組織から顧客のAzureサブスクリプションにデプロイする。

→顧客のAzure環境内にセルフホステッドエージェントをデプロイします。エージェントのVM/VMSSにマネージドIDを割り当て、必要なRBACロールを付与します。

理由: すべての認証プリンシパルを顧客のテナント内に保持し、ゼロトラストモデルに準拠します。シークレットがテナント境界を越えることはありません。

大規模な製品において複数のチームの作業を管理し、チームの自律性を保ちながら、リーダーシップ層にチーム横断的な可視性を提供する。

→各チームにフィルターされたバックログを提供するために、Area Pathを持つ単一のプロジェクトを使用します。Delivery Plansを使用して、チーム間の進捗と依存関係を視覚化します。

理由: 各チームが独自のスプリントと作業項目を独立して管理しながら、ロールアップレポートと依存関係追跡を可能にします。

コミット/PRを作業項目に自動的にリンクし、PRマージ時に作業項目の状態（例：「解決済み」）を遷移させる。

→プロジェクト設定で、「プルリクエストで作業項目を自動的に完了する」を有効にします。開発者はコミットメッセージで`#<ID>`を使用するか、PRをリンクする必要があります。

理由: 開発者の手作業のオーバーヘッドを減らし、作業項目のステータスを最新に保ち、コードと要件間の追跡可能性を向上させます。

バリューストリーム分析のために、サイクルタイム、リードタイム、DORAメトリクスなどの主要なプロセスメトリクスを測定する。

→Azure DevOps AnalyticsサービスとそのODataフィードを使用します。Power BIを接続するか、組み込みのダッシュボードウィジェットを使用してこれらのメトリクスを視覚化します。

理由: Analyticsサービスは、主要なフローおよびSREメトリクスの基盤データを提供し、データ駆動型のプロセス改善を可能にします。

平均パフォーマンスメトリクスに隠れている断続的な応答時間の遅延を調査する。

→Application Insightsで、パフォーマンスブレードをパーセンタイル分析（P95、P99）およびトランザクション検索と共に使用して、特定の遅いリクエストサンプルを深く掘り下げます。

理由: 平均は誤解を招くことがあります。パーセンタイルはパフォーマンス問題の「ロングテール」を明らかにし、それはしばoften、最も不満を抱いているユーザーを表しています。

単一のユーザーリクエストが複数のマイクロサービスを横断する際にトレースし、ボトルネックや障害点を特定する。

→すべてのサービスをApplication Insights SDKで計測します。これにより、W3C Trace Context相関IDがサービスコール間で自動的に伝播されます。

理由: Application Mapで分散トランザクションの統合ビューを提供し、複雑な相互作用をデバッグできるようにします。

アプリケーションのサービスレベル目標（SLO）をプロアクティブに監視し、SLOが侵害される*前に*アラートを受け取る。

→Azure MonitorでKQLクエリを使用してSLIを定義します。エラー予算の消費率（予算が消費されている速度）に基づいてトリガーされるアラートルールを作成します。

理由: バーンレートアラートは予測的であり、SLOが侵害され、ユーザーに大きな影響が出る前に対応する時間を与えます。

パイプラインタスクが完了しただけでなく、ユーザーの視点からデプロイが機能的に成功したことを検証する。

→デプロイ後のステップまたはリリースゲートとして、主要なユーザーフローをシミュレートするApplication Insightsの可用性テスト（合成モニタリング）を実行します。

理由: パイプラインの成功は、ビットが移動したことのみを示します。合成テストは、アプリケーションが実際に機能していることを確認し、設定ミスや依存関係の障害を検出します。

デプロイイベントと、アプリケーションのパフォーマンスおよびエラー率メトリクスの変化を視覚的に関連付ける。

→Azure Pipelinesタスクを使用してApplication Insightsに「リリース注釈」を作成し、メトリックチャートにマーカーを配置します。

理由: 最近のデプロイがパフォーマンスの低下やバグを引き起こしたかどうかを迅速に特定するための即時視覚フィードバックを提供します。

制御された方法で、障害に対するアプリケーションおよびインフラストラクチャの回復力をプロアクティブにテストする。

→Azure Chaos Studioをリリースパイプラインに統合します。障害（例：VMシャットダウン、ネットワーク遅延）を注入し、システム動作を検証する実験を作成します。

理由: 期待される動作のテストを超え、予期せぬ障害のテストを行い、システムの回復力への信頼を構築します。