パイプラインはいつ人間の承認を待つべきか

こんな状況を想像してみてください。CI/CDパイプラインが新機能のビルドとテストを完了しました。すべてのチェックがパスし、セキュリティスキャンも異常なし。ステージング環境でも新しいバージョンが問題なく動作しています。さて、パイプラインはこの同じバージョンを本番環境にプッシュしようとしています。そのまま進めるべきでしょうか、それとも誰かが「OK」と言うまで止まるべきでしょうか？

この疑問は、複数の環境を持つデプロイパイプラインを構築するすべてのチームに生じます。答えは単純なイエスかノーかではありません。各環境への信頼度と、受け入れ可能なリスクの大きさに依存します。

パイプラインに任せるべきケース

開発環境のような初期環境では、ほとんどのチームがパイプラインに変更を自動でプロモーションさせています。ビルドが成功し、テストがパスし、セキュリティスキャンがクリーンであれば、パイプラインは即座にそのバージョンを次の環境にデプロイします。誰もボタンをクリックする必要はありません。これが自動プロモーションです。

自動プロモーションは高速です。開発者は小さな修正をプッシュするたびに、ステージングへのデプロイ承認を待つ必要がありません。パイプラインは1日に数十もの変更を処理でき、チームがボトルネックになることはありません。ミスのコストが低い初期環境では、このスピードは大きな価値があります。

しかし、自動プロモーションがすべての状況に適しているわけではありません。変更が本番環境に近づくほど、問題が発生したときの影響は大きくなります。ある時点で、チームは一時停止し、ステージングでのテスト結果を確認し、変更を進めるべきかどうかを判断したいと考えるでしょう。

人間の介入が必要なケース

手動プロモーションとは、パイプラインが特定の環境の境界で停止し、続行の許可を誰かが与えるのを待つことを意味します。これは通常、本番環境の前、または実際のユーザーがアクセスする環境の前で行われます。パイプラインはすでにすべての準備を完了しています。新しいバージョンはビルドされ、ステージングでテストされ、セキュリティチェックも済んでいます。しかし、誰かが承認するまで本番環境にはデプロイされません。

チームが手動プロモーションを採用するかどうかは、主に2つの要因で決まります。対象環境の重要度と、変更の規模です。

本番環境では、多くのチームが最終的なセーフティネットとして手動プロモーションを使用します。すべての自動ゲートは通過し、ステージングも正常に動作しています。しかし、変更がユーザーに届く前に、誰かが意識的に確認することをチームは望みます。承認を行うのは通常、シニアエンジニア、テックリード、または変更がシステムに与える影響を完全に理解している人物です。

大規模な変更（データベースマイグレーション、アーキテクチャ変更、主要ライブラリのアップデート）の場合、ステージング環境であっても手動プロモーションがよく使われます。チームは、変更が次の段階に進む前に誰かが注意を払っていることを確認したいのです。

一般的なパターン：初期は自動、後半は手動

最も一般的なアプローチは組み合わせです。初期環境では自動プロモーション、最終環境では手動プロモーションです。パイプラインは開発からステージングまでは自動でプロモーションし、本番ゲートで停止して承認を待ちます。あるいは、ステージングまでは自動でプロモーションし、QAチームが手動で確認した後、本番への承認を行います。

次のフローチャートは、この一般的なパターンと、高リスク変更における判断ポイントを示しています。

flowchart TD Dev[Development] -->|auto-promote| Staging[Staging] Staging -->|auto-promote| PreProd[Pre-Production] PreProd --> IsHighRisk{Is this a high-risk change?} IsHighRisk -->|No| AutoProd[Auto-promote to Production] IsHighRisk -->|Yes| ManualGate[Manual Approval Gate] ManualGate -->|approved| Prod[Production] ManualGate -->|rejected| Stop[Stop / Rollback]

一部のチームは、多層的な手動プロモーションを適用します。たとえば、ステージングへの移行にはシニア開発者の承認が必要で、本番への移行にはテックリードとQAチームの両方の承認が必要です。環境が上位になるほど、同意が必要な人数が増えます。

手動プロモーションがそうではないもの

手動プロモーションは自動ゲートの代替ではありません。自動ゲートはすべての環境で引き続き実行されます。パイプラインは、承認を待つために停止する前に、ビルド、テスト、セキュリティをチェックします。手動プロモーションは、自動チェックの上に人間の判断レイヤーを追加するものです。自動チェックを置き換えるものではありません。

パイプラインが自動チェックをスキップし、完全に手動承認に依存している場合、それは手動プロモーションではありません。それは余計な手順が増えただけの手動デプロイです。手動プロモーションの価値は、厳格な自動検証と、情報に基づいた人間の判断の両方を持つことにあります。

判断のための実践的チェックリスト

パイプラインのプロモーションルールを設定する際は、次の質問を自問してください。

  • この環境は実際のユーザーが使用するものか？ はいの場合、手動プロモーションを検討する。
  • ここでのミスがデータの整合性に影響したり、ダウンタイムを引き起こしたりする可能性があるか？ はいの場合、手動プロモーションの方が安全。
  • チームはこの環境の自動テストに十分な自信を持っているか？ 自信がない場合は、手動レビューを追加する。
  • これはルーチン変更（設定更新、マイナー機能）か、高リスク変更（スキーママイグレーション、ライブラリアップグレード）か？ 高リスク変更はステージングでも手動承認が有効。
  • 手動承認にはどのくらい時間がかかるか？ 数時間かかる場合、チームは頻繁なデプロイを避けるようになるかもしれない。安全性とスピードのバランスを取る。

まとめ

手動プロモーションは意図的な一時停止であり、すべてを遅くするゲートキーパーではありません。ミスのコストが、人間のレビューを待つコストよりも高い場所で使用してください。初期環境ではパイプラインに任せ、本番環境や高リスク変更では人間に判断させましょう。最良のパイプラインは、自動化の厳密さと、適切なタイミングでの人間の判断を組み合わせたものです。