私たちが共に築いたもの：CI/CDの実践的理解
すべては単純な問いから始まりました。アプリケーション、データベース、インフラストラクチャへの変更を、ユーザーの体験を壊さずに、実際に使われる場所に届けるにはどうすればよいのか？
この問いは、聞こえ以上に難しいものです。私が一緒に仕事をしてきたすべてのチームは、素早くリリースすることと安全にリリースすることの間で板挟みになっていました。あるチームは複雑な儀式で解決し、別のチームは一人だけが理解するスクリプトで解決します。どちらのアプローチもスケールせず、デプロイのたびに不安を生み出します。
この記事では、この本で私たちが共に築いた基盤を解説します。これは各章の要約ではありません。CI/CDを単なるツールとして扱うのをやめ、それをケイパビリティとして捉え始めたときに、各ピースがどのように組み合わさるのかを示す地図です。
パイプラインではなく、デプロイから始める
何かを自動化する前に、デプロイが実際に何を意味するのかを理解する必要があります。デプロイとは、新しいバージョンの何かを、ユーザーがアクセスできる環境に配置する行為です。当たり前に聞こえますが、その含意は単純ではありません。
アプリケーションの悪いバージョンをデプロイした場合、完全に置き換えることができます。データベースの悪いマイグレーションをデプロイした場合、データは残ったままで、ロールバックはより複雑です。ネットワークを壊すインフラストラクチャの変更をデプロイした場合、他の何も機能しなくなります。
これら3つ（アプリケーション、データベース、インフラストラクチャ）は、同じように扱うことはできません。それぞれに独自のデプロイ戦略があります。アプリケーションは、2つの同一環境間でトラフィックを切り替えるブルーグリーンデプロイが適しています。データベースは、変更を小さな可逆的なステップで適用する段階的マイグレーションが必要です。インフラストラクチャは、パッチを当てるのではなく環境全体を置き換えるイミュータブルなアプローチが効果的です。
以下の図は、3つの並行トラックと推奨戦略を示しています。
重要なのは、これらの戦略を暗記することではありません。デプロイは単一のアクションではないと認識することです。デプロイとは、変更を安全に移動する方法に関する一連の判断であり、その判断は何を移動するかに依存します。
パイプラインはスクリプトではなく、契約である
デプロイを理解すれば、パイプラインを構築できます。しかし、パイプラインはコマンドを実行するスクリプトではありません。パイプラインとは、すべての変更が本番環境に届く前に、同じチェックを、同じ順序で、一貫した環境で通過しなければならないという契約です。
この区別が重要なのは、チームがしばしばパイプラインを既存の手動プロセスの自動化として扱うからです。手動プロセスにギャップがあれば、パイプラインもそのギャップを自動化してしまいます。優れたパイプラインは、「変更がユーザーに届く前に、何が真実でなければならないか」という問いから始まります。
アプリケーションの変更の場合、答えには単体テスト、統合テスト、セキュリティスキャンの合格が含まれるかもしれません。データベースの変更の場合、マイグレーションが可逆的であること、ロールバックスクリプトが存在することの確認が含まれるかもしれません。インフラストラクチャの変更の場合、実際のステージング環境に対する検証の実行が含まれるかもしれません。
3種類すべての変更を同時に処理するパイプラインを構築することが、本当の課題です。ほとんどのチームは1つから始めて、後で他のものを追加します。それは問題ありません。ただし、どの部分が欠けていて、その理由を理解している限りは。
デプロイとリリースは別物
この本で最も有用な区別の1つは、デプロイとリリースの分離です。
デプロイは、新しいバージョンをサーバーに配置することです。リリースは、そのバージョンを実際にユーザーに使わせることです。この2つのアクションを分離すると、リスクをコントロールできるようになります。バージョンをデプロイし、内部ユーザーで本番テストを行い、自信がついてから全員にリリースすることができます。
この分離こそが、フィーチャーフラグ、カナリアリリース、プログレッシブデリバリーなどの戦略を可能にします。フィーチャーフラグは、再デプロイせずに機能のオン/オフを切り替えられます。カナリアリリースは、まず新しいバージョンに少量のトラフィックを送ります。プログレッシブデリバリーは、メトリクスを観察しながらその割合を徐々に増やします。
これらの戦略には特定のツールは必要ありません。必要なのは、デプロイとリリースをそれぞれ独自のリスクプロファイルを持つ別々の判断として扱うマインドセットです。
プラットフォームエンジニアリングが加速させる
複数のチームがパイプラインを通じて変更をリリースするようになると、パターンが見えてきます。すべてのチームは同じ基本的なものを必要とします：変更をビルド、テスト、デプロイする方法、それらのテストを実行するための一貫した環境、そしてインフラストラクチャへのセルフサービスアクセスです。
プラットフォームエンジニアリングとは、これらのケイパビリティを内部プロダクトとして構築する実践です。プラットフォームは、誰かが使い始める前に完成させなければならない大規模プロジェクトではありません。プラットフォームは、チームが実際に抱えるニーズから始まり、それをうまく解決し、さらに新たなニーズが生まれるにつれて拡大していきます。
ここでの重要な洞察は、プラットフォームエンジニアリングは完璧な抽象化を構築することではないということです。それは、チームが価値の提供に集中できるように、認知負荷を減らすことです。チームがパイプラインのセットアップに2日かかるなら、プラットフォームは機能していません。単一のプルリクエストで新しいサービスを立ち上げられるなら、プラットフォームは機能しています。
ガバナンスはゲートではなく、ガードレール
ガバナンスは、しばしば物事を遅くする層として誤解されています。実際には、CI/CDにおけるガバナンスとは、チームが物事を壊さずに素早く動けるようにする境界を設定することです。
本番変更のレビューポリシー、自動化された監査証跡、リスクベースのデプロイルールはすべて同じ目的を果たします。それは、変更が従うべき明確な経路を作り、チームが何が許可されているかを推測したり、毎回手動承認を待ったりする必要をなくすことです。
ゲートとしてのガバナンスとガードレールとしてのガバナンスの違いは微妙ですが重要です。ゲートは誰かが承認するまで変更をブロックします。ガードレールは安全な経路を定義し、チームがその範囲内で自由に動けるようにします。前者はボトルネックを生み、後者は自律性を生みます。
実践的なチェックリスト
組織でCI/CDケイパビリティを構築しているなら、判断の指針となる短いチェックリストを以下に示します。
- 手動ステップなしで本番に変更をデプロイできますか？
- 5分以内にデプロイをロールバックできますか？
- デプロイ戦略とリリース戦略の違いを理解していますか？
- すべての変更は、誰が行ったかに関係なく、同じチェックを通過しますか？
- 新しいチームメンバーは、初日に権限を申請せずに最初の変更をデプロイできますか？
- データベースマイグレーションを本番に届ける前にテストする方法はありますか？
- インフラストラクチャはスノーフレークサーバーではなく、コードとして扱われていますか？
これらのいずれかに「いいえ」と答えた場合、次にどこに焦点を当てるべきかがわかります。
CI/CDは維持するケイパビリティ
この旅から得た最も重要な教訓は、CI/CDは完了するプロジェクトではないということです。それは維持するケイパビリティです。ツールは変わります。チームは成長します。要件は変化します。今日機能するプラクティスが来年も機能するとは限りません。
変わらないのは、変更を安全にリリースすることが、スクリプトではなくスキルであるという理解です。それは、日々の小さな判断から築かれます：テストの構成方法、障害の処理方法、スピードと安全性のバランスの取り方。これらの判断は時間とともに積み重なり、チームが自信を持ってリリースするか、恐怖とともにリリースするかを決定します。
1つの変更から始めてください。それを安全にしてください。次に、それを繰り返し可能にしてください。そして、それを高速にしてください。残りは自然とついてきます。