【ITニュース解説】CI/CD Quality Gate Mistakes: Approvals and Rollback Pitfalls

CI/CD（継続的インテグレーション／継続的デリバリー）は、ソフトウェア開発において、コードの変更を頻繁にシステムに統合し、自動的にテストし、本番環境へと継続的にデリバリーするプロセスを指す。このプロセスにより、ソフトウェアの品質を維持しながら、迅速かつ安定したリリースが可能になる。しかし、CI/CDパイプラインに導入される品質ゲート、手動承認、ロールバックといった重要な仕組みは、適切な設計と運用がなされない場合、意図した効果を発揮せず、かえって問題を引き起こすことがある。これらの仕組みは、設定上は容易に導入できるが、実際に機能させるためには、しっかりとした設計と運用が不可欠である。設定が存在するだけで、実質的な制限がない状態では、緊急時に何の役にも立たない。

まず、品質ゲートとは、デプロイされるソフトウェアが技術的な要件（例えば、テストの合格、セキュリティ基準の充足、コード品質基準の達成など）を満たしているかを自動的にチェックする仕組みである。これは常に同じ基準で評価されるべきだ。次に、手動承認は、そのソフトウェアを本番環境にリリースしてもよいか、人間がリリース時期、潜在的なリスク、ビジネス上の状況を考慮して判断するステップである。そして、ロールバックとは、リリースされたソフトウェアに問題が発覚した場合に、事前に確認された安定した状態に迅速に戻すための一連の手順を指す。これら三つの仕組みはそれぞれ異なる役割を持つが、しばしば混同され、その結果、期待される効果を発揮できない場合がある。

品質ゲートの一般的な失敗の一つは、それが「必須ではない」状態になっていることだ。例えば、自動テストが失敗したにもかかわらず、デプロイプロセスが続行してしまうケースがある。これは、設定ファイルに「エラーがあっても続行する（continue-on-error: true）」という指定があったり、デプロイジョブの実行条件が正しく設定されていなかったり、あるいはテストとデプロイのワークフローがそれぞれ独立してトリガーされてしまうことが原因となる。このような場合、ダッシュボード上でテスト失敗を示す赤色の表示が出ていても、実際のリリースは止まらない。また、品質ゲートが「間違ったものを測定している」場合も問題を引き起こす。例えば、リポジトリ全体のコードカバレッジを基準にしても、リスクの高い変更がごく一部であっても全体に与える影響が小さいため、ゲートが通過してしまうことがある。より効果的なアプローチは、新しく追加されたコードや変更されたコードに焦点を当て、単体テスト、明確な厳格度基準を持つ脆弱性スキャン、インフラ変更に対するポリシーチェックなど、意味のある少数のチェック項目でゲートすることである。これにより、より正直に実際の品質を評価できる。さらに、「不安定な（flaky）テスト」も品質ゲートの信頼性を損なう要因となる。テストがランダムに失敗するような状況では、チームはテストが赤色になっても、単に再実行して緑色になるまで繰り返すようになり、品質ゲートがノイズとして扱われるようになる。このような不安定なテストは隔離し、再実行が通常のワークフローとならないように管理する必要がある。GitHub Actionsなどのプラットフォームでは、パスフィルターによって必須チェックがスキップされ、マージが保留状態になる問題も発生する。これを回避するためには、軽量で常に実行されるジョブを設計し、必須チェックが正しく機能するようにする必要がある。また、デプロイされる実際のコミットに対して品質ゲートが実行されているかを確認することも重要だ。プルリクエストブランチで実行されたゲートは、メインブランチが更新された後のマージ結果については何も保証しない可能性がある。

次に、手動承認における一般的な失敗について説明する。手動承認は、リスクへの対処として導入されることが多いが、時間が経つにつれて形骸化し、単なる儀式になってしまう傾向がある。承認者は「本番環境へのデプロイが待機中です」という通知を受け取っても、その内容にどのような変更が含まれているのか、テスト結果はどうだったのか、現在稼働中のバージョンと何が違うのかといった情報が不足していることが多い。結果として、最も抵抗の少ないパスとして「承認」ボタンを押すことが習慣となり、承認疲労が蓄積されていく。より根本的な問題は、開発パイプラインの途中のステップを承認しているだけで、最終的に本番環境にデプロイされる「成果物」（実際に動作するソフトウェアのまとまり）自体を承認していないことだ。承認後にビルドが実行されたり、デプロイジョブがソースから再ビルドしたりする場合、承認時に確認した内容と実際にデプロイされる内容が異なる可能性がある。例えば、バージョンが固定されていないベースイメージや依存関係が原因で、承認時とデプロイ時で結果が変わる恐れがある。自己承認や長すぎる待機時間にも注意が必要だ。デプロイをトリガーした人が同時に承認もできる場合、その承認は意味をなさない。GitHubのようなプラットフォームでは「自己レビューの防止」オプションがあり、環境ごとに必須のレビュー担当者を設定できる。また、承認の待機にはタイムアウトが設定されており、週末を挟むようなデプロイでこのタイムアウトを頼りにする前に、その具体的な制限を文書で確認しておくべきだ。承認が全てのリリースに対して一律に適用される傾向があることも問題である。例えば、ドキュメントの変更とデータベーススキーマの変更が同じように承認される場合、その承認が持つ情報価値は低いと学習されてしまう。人間による承認は、巻き戻しが非常に困難な変更や、タイミングが重要な変更に限定し、リスクの低い変更は自動化された品質ゲートのみで進めるべきである。

最後に、ロールバックの失敗について見ていこう。「ロールバック」という言葉が、単に「以前のコミットを再デプロイする」こととして誤解されていることが多いが、これは真のロールバックではない。これは、ビルドシステムが正常に動作し、コンテナレジストリにアクセスでき、依存関係が以前と同じように解決されることに依存する「再ビルド」である。さらに、品質ゲート（または緊急時のバイパス）が、システムに負荷がかかっている状況下でも正常に実行される必要が生じる。真のロールバックとは、以前の変更不能な成果物（例えば、コンテナイメージを識別する一意なダイジェスト値で特定されるもの）を、何も再ビルドすることなく再デプロイすることである。しかし、これだけでも十分ではない。ロールバックは、ツールが追跡している範囲の変更しか元に戻せない。例えばKubernetesのデプロイメントのロールバックは、以前のPodテンプレートを履歴から復元するが、ConfigMap、Secret、CRD（カスタムリソース定義）、あるいは外部リソースへの変更は元に戻さない。履歴が保持される期間もrevisionHistoryLimitによって制限されるため、設定値を確認する必要がある。最も困難なケースは、「状態」に関わる変更だ。もしリリースN+1が、データベースのテーブルからカラムを削除したり、データを書き換えたりといった破壊的なデータベースマイグレーションを含んでいた場合、アプリケーションをNにロールバックすると、古いバージョンのアプリケーションが理解できないスキーマに対して動作することになりかねない。このような問題は、実際にロールバックを試みて初めて発覚することが多い。ロールバックパスが、まさに壊れたものに依存している場合にも注意が必要だ。ロールバックに、壊れたばかりの同じパイプライン、同じ承認者、同じレジストリが必要となる場合、一度の障害がリリースと復旧の両方を妨げてしまう可能性がある。本番環境で実際にロールバックを試みる前に、非本番環境で定期的にリハーサルを行うことが非常に重要である。

より安全なCI/CD品質ゲートの設計は、いくつかの原則に基づいている。第一に、成果物を生成した正確なコミットに対して品質ゲートを実行し、ビルドされたイメージをそのダイジェスト値（コンテンツハッシュ）でスキャンすることだ。第二に、成果物を一度だけビルドし、それをダイジェストで一意に識別すること。第三に、承認は特定のワークフローのステップではなく、デプロイ先の環境全体に紐付けること。そして第四に、デプロイ後にサービスの健全性を検証し、検証が失敗した場合は自動的に元に戻すことだ。例えばGitHub Actionsのようなプラットフォームでは、コミットをゲートし、その時点のコードからイメージを一度ビルドし、その正確なダイジェストのイメージを保護された環境にデプロイし、ロールアウト検証が失敗した場合は自動的に元に戻すワークフローを構築できる。この場合、必須レビュー担当者や自己レビュー防止などの環境保護ルールは、YAMLファイルではなくリポジトリの設定で構成される。ロールバックの条件は意図的に狭く設定すべきである。もしデプロイステップ自体が失敗した場合、新しいリビジョンは存在しないため、無条件のロールアウト取り消しは、さらに古いリリースに戻してしまう可能性がある。また、ロールアウトステータスはPodが準備完了になったことしか証明しないため、ユーザーが利用するサービスについては、実際の健全性チェックやメトリクスによる検証を追加する必要がある。

CI/CDパイプラインが本番環境で利用可能となる前に、以下の点を最終確認する必要がある。品質ゲートについては、保護されたブランチに対して必須チェックが設定されており、パスフィルターによってチェックが保留状態にならないように常に実行されるジョブがあること、そして閾値が変更されたコードに適用され、不安定なテストは再試行されずに隔離されていることを確認する。承認については、環境に紐付けられ、差分やテストサマリーとともに表示され、承認者がデプロイをトリガーした人物ではなく、タイムアウトの挙動が把握されていること、そして再ビルドではなく成果物のダイジェストを承認していることを確認する。ロールバックについては、以前の成果物がコンテナレジストリに残っていること（保持期間を確認）、データベースマイグレーションが「Expand/Contract（拡張／収縮）」パターンに従っており、N-1バージョンのコードがNバージョンのスキーマでも動作すること、ステージング環境でロールバックのリハーサルが実施されており、品質ゲートをバイパスせずに機能すること、そしてデプロイ後の検証によって自動的にロールバックがトリガーされることを確認する。

特にデータベースマイグレーションにおける「Expand/Contract」パターンは重要だ。これは、まず新しいスキーマを追加し、次に新しいスキーマと古いスキーマの両方に対応できるコードをリリースし、そして後のリリースで古いスキーマを削除するという三段階のアプローチである。これにより、以前のアプリケーションバージョンが引き続き有効に保たれ、ロールバックがデータ復旧プロジェクトではなく、日常的な操作となる。

これらの設計と確認事項は、判断の必要性を取り除くものではなく、品質ゲート、承認、ロールバックそれぞれが、導入された本来の目的を確実に果たすための基盤を構築するものである。