CI/CDツールの本当の役割：機能別分類で理解する
アプリケーションをビルド、テスト、デプロイするパイプラインは動いている。しかし、何かが壊れたとき、どのツールが何を担当しているのかわからなくなる。CIサーバーがダウンしているのにデプロイは実行された。アーティファクトレジストリには同じビルドのバージョンが3つあり、どれが正しいのか誰も知らない。データベースマイグレーションが2回実行され、スキーマの状態が不明になった。
この混乱は、各ツールの役割を理解せずに、名前や人気だけでツールを選んだときに起こる。CIサーバーはデプロイツールの代わりにはならない。フィーチャーフラグシステムはシークレットマネージャーではない。可観測性プラットフォームは変更管理を行わない。
ここでは、モダンなデリバリーパイプラインを構成する9つのツールカテゴリを機能別に分類する。各カテゴリには、他のカテゴリでは代替できない固有の役割がある。
CIサーバー：パイプラインの頭脳
CIサーバーは、リポジトリを監視し、パイプラインを自動実行するエンジンである。開発者がコードをプッシュすると、CIサーバーが変更を検知し、ビルド手順を実行し、テストを実施し、アーティファクトを生成する。
CIサーバーがなければ、コード変更のたびに開発者が手動でコードをチェックアウトし、ビルドし、結果を確認しなければならない。これでは1人が1つの機能に取り組む規模を超えるとスケールしない。
CIサーバーはパイプライン全体を統制する。何を、どの順序で実行するか、ステップが失敗した場合の処理を決定する。デリバリープロセスの中枢神経系である。
以下の図は、9つのツールカテゴリが典型的なデリバリーパイプラインでどのように連携するかを示している：
アーティファクトレジストリ：ストレージ層
CIサーバーがビルドを完了すると、アーティファクトが生成される。そのアーティファクトには、後でデプロイツールが参照できる永続的な保存場所が必要である。
アーティファクトレジストリは、すべてのバージョンのビルドをメタデータ（バージョン番号、ビルドハッシュ、依存関係、場合によってはセキュリティスキャン結果）とともに保存する。その役割はシンプルだが極めて重要である。すべてのテストに合格したアーティファクトが、デプロイされるアーティファクトと同一であることを保証する。
レジストリがないと、チームはデプロイ時にソースから再ビルドすることになり、リスクが生じる。1時間前に実行したビルドでも、依存関係が変わったり、ビルド環境が同一でなければ、異なる出力になる可能性がある。
デプロイツール：配置エンジン
デプロイツールは、レジストリからアーティファクトを取得し、ターゲット環境に配置する。環境設定を読み込み、正しいアーティファクトを取得し、デプロイプロセスを実行する。
デプロイツールは、ブルーグリーン、カナリア、ローリングアップデートなどの戦略を処理する。旧バージョンから新バージョンへの移行を最小限の中断で管理する。
重要な違いは、デプロイツールはインフラストラクチャを構築しないことである。既存のインフラストラクチャにアプリケーションを配置する。サーバー、ネットワーク、クラウドリソースを作成する必要がある場合は、別のツールの役割である。
IaCツール：インフラストラクチャビルダー
Infrastructure as Codeツールは、インフラストラクチャをプログラムで作成・管理する。サーバー、データベース、ネットワーク、ロードバランサー、クラウドリソースを、バージョン管理、レビュー、一貫性のある適用が可能なコードとして定義する。
IaCツールとデプロイツールは、しばしば順番に動作する。IaCツールが環境を準備し、デプロイツールがその環境にアプリケーションを配置する。この2つの責任を混在させると、インフラストラクチャの変更とアプリケーションのデプロイが絡み合い、脆いパイプラインになる。
データベースマイグレーションツール：スキーママネージャー
データベースマイグレーションは特殊な変更である。アプリケーションが依存するスキーマを変更し、順序通りに実行する必要がある。マイグレーションスクリプトを順序を間違えて実行したり、1つスキップしたりすると、データが破損する可能性がある。
マイグレーションツールは、現在適用されているスキーマのバージョンを追跡する。まだ実行されていないマイグレーションのみを実行する。前方への移動方法と、多くの場合、後方への移動方法を知っている。
マイグレーションツールがないと、チームはSQLスクリプトを手動で実行したり、スキーマ変更をアプリケーションコードに埋め込んだりする。どちらのアプローチも脆弱でエラーが発生しやすく、特に複数の開発者が同じデータベースを操作する場合に顕著である。
フィーチャーフラグシステム：リリースデカップラー
フィーチャーフラグは、デプロイとリリースを分離する。機能をオフにした状態でコードをデプロイし、後で特定のユーザー、リージョン、条件に対して有効にできる。
これにより、きめ細かい制御が可能になる。新機能をまず小規模なグループでテストできる。問題が発生した場合は、デプロイ全体をロールバックせずに機能をオフにできる。問題がなければ、徐々に対象を拡大する。
フィーチャーフラグは設定ファイルではない。再デプロイせずにアプリケーションの動作を変更できるランタイム制御システムである。
シークレット管理：認証情報の保管庫
シークレットとは、パスワード、APIキー、証明書、トークンである。これらは安全に保存され、必要な時に必要なサービスだけがアクセスできるようにしなければならない。
シークレット管理ツールは、保存時と転送時のシークレットを暗号化する。アイデンティティとコンテキストに基づいてアクセスを制御する。認証情報を自動的にローテーションし、すべてのアクセス試行を記録する。
設定ファイルや環境変数にシークレットをハードコーディングすることは、シークレット管理ではない。それは発生待ちのセキュリティインシデントである。
可観測性プラットフォーム：可視性層
可観測性は、実行中のシステムからログ、メトリクス、トレースを収集する。本番環境でアプリケーションが何をしているかを理解する能力を提供する。
これは従来の監視とは異なる。監視はシステムが稼働しているか停止しているかを教える。可観測性は、システムがなぜそのように動作しているのかを教える。問題のデバッグ、パフォーマンスの理解、インシデントになる前の異常の検出に役立つ。
変更管理ツール：監査証跡
パイプラインを通過するすべての変更は痕跡を残す。変更管理ツールは、誰が、何を、いつ、なぜ変更したかを記録する。
これはガバナンスとコンプライアンスに不可欠である。問題が発生した場合、何が変更され、誰が承認したかを正確に知る必要がある。変更管理ツールがなければ、記憶、チャットログ、スプレッドシートに頼ることになる。
実践的なチェックリスト
パイプラインに新しいツールを追加する前に、以下の質問を自問してほしい：
- このツールはどのカテゴリに属するか？
- このカテゴリにはすでにツールがあるか？
- 新しいツールは既存のツールの機能と重複するか？
- 重複する場合、どちらがその機能を担当すべきか？
まとめ
ツールは互換性がない。CIサーバーはデプロイを実行できない。デプロイツールはシークレットを管理できない。アーティファクトレジストリはマイグレーションを実行できない。名前だけでなく機能を理解すれば、どのツールが何をするのか推測する必要がなくなる。問題が発生したときに、明確で、保守可能で、実際に機能するパイプラインを構築できる。