8.1 CI/CDとデリバリー

概要と動機

継続的インテグレーションと継続的デリバリー(CI/CD)は、コードを書くことと、それを安全にユーザーの前に置くことの間の結合組織です。継続的インテグレーションとは、すべての変更が頻繁に共有のメインラインにマージされ、それから自動的にビルドされテストされることを意味し、統合の問題が、長いリリースサイクルの終わりではなく数分以内に表面化します。継続的デリバリーとは、パイプラインを通過したすべての変更がデプロイ可能な状態に保たれることを意味し、本番へのリリースが、エンジニアリングの大慌てではなくビジネスの決定になります。継続的デプロイはさらに一歩進み、人間のゲートなしに、通過したすべての変更を自動的にリリースします。

大きなチームにとって、これらの区別は非常に重要です。数百人のエンジニアが重なるシステムにコミットするとき、手作業の統合と手作業のテストのコストは非線形に増えます。共有で自動化されたパイプラインは、多くの貢献者に速く信頼できるフィードバックを与え、あるチームの変更が別のチームの変更を静かに壊すのを防ぐ唯一の実用的な方法です。パイプラインは、ソフトウェアが健全かについての単一の真実の源になり、どれほど文書や善意があっても、規模では保証できない一貫性を徹底します。

企業と政府の文脈は、もう一つの次元を加えます。監査可能性と変更管理です。規制当局、セキュリティ責任者、監査人は、変更がレビューされ、テストされ、承認されたこと、本番で動いている成果物が、まさに構築され検証されたものであることの証拠を必要とします。よく設計されたCI/CDパイプラインは、これらのコンプライアンスの義務を、書類仕事の負担から、通常のエンジニアリングのワークフローの自動的な副産物に変えます。うまく行えば、デリバリーは同時に速く、安全になり、それがリーダーシップにとって最も重要な成果です。

関連項目: 8.4章(プラットフォームエンジニアリングと開発者体験)、8.5章(テストとプロセスの自動化)、プログレッシブデリバリー(変更を段階的にリリースしながら、ヘルス指標を自動的に監視すること)が可能にするフィーチャーフラグ(再デプロイなしにユーザーに機能を露出する実行時のスイッチ)と実験の実践については、7.4章(プロダクト分析と実験)。

主要原則

小さな変更を頻繁に統合します。長寿命のブランチは継続的インテグレーションの敵です。
成果物を一度構築し、同一の成果物をすべての環境を通じて昇格させます。
パイプラインを権威あるゲートにします。緑なら変更は出荷可能で、赤なら直るまで作業が止まります。
開発者がフローを保ち、文脈が新しいうちに欠陥が捉えられるよう、速いフィードバックのために容赦なく最適化します。
テスト、セキュリティスキャン、プロビジョニング、デプロイを含め、繰り返されるすべてを自動化します。
パイプラインの定義を、クリックするコンソールの設定ではなく、レビューを受けるバージョン管理されたコードとして扱います。
どのデプロイも素早く元に戻せるよう、安全で元に戻せるリリースを設計します。
フィーチャーフラグを使って、デプロイ(コードのインストール)をリリース(ユーザーへの露出)から分けます。

推奨事項

パイプラインを一連の品質ゲートとして設計する

パイプラインを、安く速いものから高価で徹底したものへと進む段階に構造化します。まずコンパイルとユニットテスト、次に統合テスト、セキュリティとライセンスのスキャン、最後にステージングと本番へのデプロイ。各段階は、変更が通過しなければならないゲートです。最も速く最も失敗しやすいチェックが最初に走るようにゲートを並べ、開発者に最短の時間でフィードバックを与えます。可能な所では、コミット段階のフィードバックのループを10分未満に保ちます。それを超えると、開発者はコンテキストを切り替え、生産性が落ちます。

一度構築し、あらゆる所へ昇格させる

構築の段階で単一の不変の成果物を生成し、まさにその成果物をテスト、ステージング、本番を通じて昇格させます。環境ごとに再構築してはいけません。再構築は静かに違いを持ち込みうるからです。環境ごとに変わる設定は、別々のビルドに焼き込むのではなく、デプロイ時に注入します。この実践はまた、本番のバイナリがすべてのゲートを通過したものだと、確信をもって監査人に伝えられるようにするものです。

パイプラインを方針の徹底点にする

必須のチェック(コードレビューの承認、テストカバレッジの閾値、セキュリティスキャンの結果、署名されたコミット)を、パイプラインとブランチ保護のルールに直接符号化します。wikiに住む手作業の方針は、期限の圧力のもとで日常的に迂回されます。パイプラインに符号化された方針は、すべての変更に一様に自動的に適用されます。

メインラインを常にリリース可能に保つ

すべての作業を、長寿命のブランチがほとんどあるいはまったくない単一の共有ブランチに統合するトランクベース開発を使うか、短命のフィーチャーブランチを使い、未完成の作業を隠すために長寿命のブランチではなくフィーチャーフラグに頼ります。これにより、マージの競合が小さく保たれ、メインラインが常にデプロイ可能な状態に保たれ、それは本物の継続的デリバリーの前提条件です。

デプロイの戦略を意図して選ぶ

デプロイの戦略を、サービスのリスクと影響範囲に合わせます。

ローリングのデプロイは、インスタンスを段階的に置き換え、ステートレスなサービスの妥当な既定です。
ブルーグリーン は、二つの同一の環境を保ち、トラフィックを一度に切り替え、即座のロールバックの経路を与えます。
カナリアのリリースは、トラフィックの小さな割合を新しいバージョンにルーティングし、ヘルス指標を観察し、シグナルが良い場合にだけ拡大します。
フィーチャーフラグは、リリースをデプロイから切り離し、再デプロイなしに特定のユーザーやコホートに機能を有効にできるようにします。

自動化されたロールバックを伴うプログレッシブデリバリーを採用する

プログレッシブデリバリーは、カナリアのリリースを、エラー率、レイテンシ、飽和のような指標の自動化された分析と組み合わせます。客観的なヘルスの基準を事前に定義し、それからシステムに、それらのシグナルに基づいて自動的に昇格あるいはロールバックさせます。自動化されたロールバックは、小さなインシデントを大きなものに変える、人間のためらいを取り除きます。

規制対象の環境のためにリリース管理と変更管理を提供する

規制対象の設定では、軽量だが本物の変更管理の記録を保ちます。誰が各変更を承認し、どのテストが走り、どの成果物がデプロイされたかを自動的に捉えます。変更諮問のプロセスは本当に高リスクの変更のために使い、それらのケースのために取っておきます。すべての日常の変更を週次の委員会に通すことは、自動化の価値を破壊します。代わりに、儀式なしにパイプラインを流れる、標準で事前承認された変更の種類を目指します。

トレードオフ: 長所と短所

アプローチ	長所	短所	最適な場合
継続的デリバリー(手作業のリリースゲート)	ビジネスがタイミングを制御。規制対象のリリースの窓に強い	メインラインを出荷可能に保つ規律が必要	変更の窓を持つ企業
継続的デプロイ(完全自動)	最速のフィードバック。最小のバッチ	成熟したテストとオブザーバビリティが必要	信頼が高く頻度の高いチーム
ブルーグリーン	即座のロールバック。単純なメンタルモデル	切り替えの間、環境のコストが倍になる	速い巻き戻しを要する重要なサービス
カナリア + プログレッシブデリバリー	影響範囲を限る。データ駆動	築くのが複雑。良い指標が必要	大規模なユーザー向けシステム
フィーチャーフラグ	デプロイをリリースから切り離す	片付けないとフラグの負債	未完成の作業を安全に出荷するチーム

中心的なトレードオフは速度対制御ですが、それはしばしば偽の選択です。成熟した自動化は両方を届けます。リリースは小さいので速く、それぞれが検証され元に戻せるので安全です。本当のコストは、テストカバレッジ、オブザーバビリティ、パイプラインのエンジニアリングへの前もっての投資と、それらを健全に保つ継続的な規律です。その投資を惜しむ組織は、安全なしの速度を得て、それは遅い手作業のプロセスよりも悪い。

チームで議論すべき問い

コミット段階のフィードバック時間の目標は何で、スイートが10分を超えて育ったとき、何を削りますか。 遅いコミット段階は、継続的インテグレーションを静かに殺します。開発者が緑を待つのをやめ、変更をバッチ化し始めるからです。数字を今決め(本章は10分未満を論じます)、それを保つ仕組みを決めてください。並列のワーカー、厳格なテストピラミッド、遅い統合のチェックを後の段階に移すこと。企業の規模では、これはプラットフォームの決定です。数百人のエンジニアが同じパイプラインを共有し、加わる一分一分がすべてのコミットにわたって倍増するからです。本物のデータを会議に持ち込んでください。現在のパイプラインの所要時間のp50とp95、最も遅い十のテスト、人々が待つのではなく再実行する頻度。目標を述べて数字で擁護できないなら、パイプラインは、CIの衣装を着たバッチのプロセスへとずれつつあります。
各サービスはどのデプロイの戦略を使い、その選択に責任を負うのは誰ですか。 ローリング、ブルーグリーン、カナリアは交換可能ではありません。コスト、ロールバックの速度、複雑さを異なって交換し、正しい選択はサービスの影響範囲に依存します。ブルーグリーンは、切り替えの間に環境が倍になる代償に即座のロールバックを買い、決済システムには価値があり、社内のダッシュボードには無駄です。カナリアは露出を限りますが、良いヘルス指標とより多くのパイプラインエンジニアリングを要します。大きなあるいは規制対象の資産群では、これを各チームの習慣に任せると、インシデントの最中に表面化する不整合を生むので、サービスの階層ごとの既定に合意して決定を記録してください。サービスカタログを持ち込み、各サービスに、その戦略、ロールバックの経路、その判断を所有する人のタグを付けます。
本番の成果物が、すべてのゲートを通過したまさにそのものだと、どう証明しますか。 一度構築して同一の成果物を昇格させることは、監査可能性のすべてであり、誰かが環境ごとに再構築したり、動いているボックスにパッチを当てたりした瞬間に壊れます。企業と政府の設定では、監査人は、動いているバイナリをそのコミット、レビュー、承認までたどるよう求め、その答えが、一週間ではなく数秒で済むようにしたい。どう徹底するかを決めてください。不変の成果物、署名されたイメージ、デプロイ時の署名の検証、別々のビルドに焼き込むのではなくデプロイ時に注入される設定。現在のギャップを持ち込んでください。再構築する段階、手作業のホットフィックスの経路、設定が成果物を分岐させる所。答えは、コンプライアンスの証拠が、パイプラインの副産物か、毎回の監査の前の手作業の大慌てかを決めます。
メインラインが赤になったとき、実際に何が止まり、不安定なテストをどう扱いますか。 パイプラインは、赤いビルドが本当に作業を止めるときにだけ権威あるゲートですが、多くの組織は、壊れたメインラインと断続的な失敗の積み残しを静かに容認し、それは開発者に、緑になるまで再実行し、失敗の上に出荷するよう訓練します。大きなチームでは、この腐敗が複合します。あるチームの無視された不安定さが、全員がゲートを迂回する言い訳になり、パイプラインへの信頼は、築き直すより保つほうがはるかに安いからです。相反する引力を量ってください。厳格なストップ・ザ・ラインのルールは品質を守りますが、一つの悪いコミットで数百人のエンジニアをブロックしえ、寛大な方針はスループットを保ちますが、ゲートを侵食します。議論に証拠を持ち込んでください。現在のメインラインが赤だった時間、隔離された、あるいは不安定なテストの数、再実行率、失敗するチェックの上でマージされる頻度。企業と政府の設定では、誰が不安定さのトリアージを所有し、誰がマージを凍結する権限を持つかを名指ししてください。誰も徹底する責任を負わないゲートは、監査人が日常的に覆されてきたと気づくものだからです。
フィーチャーフラグのライフサイクルは何で、それを退役させる責任を負うのは誰ですか。 フラグは、デプロイをリリースから切り離し、未完成の作業を隠せるようにするものですが、すべてのフラグは、自分では片付かないコードの分岐であり、管理されないフラグは、誰も触れる勇気のない条件分岐の複雑さに積み上がります。大きな資産群では、この負債は危険です。古いフラグが、セキュリティの修正を静かにゲートしたり、テストされていないコードの経路を本番に切り替えたりしえ、それを作った人はしばしば去っているからです。緊張のバランスをとってください。フラグは安全で漸進的なデリバリーを買ったので、目標はフラグを減らすことではなく、所有者、期限の期待、古いものを表面化させるツールを備えた規律あるライフサイクルです。現在の目録を会議に持ち込んでください。いくつのフラグが稼働中か、最古のものはどれだけ古いか、所有者のいないものはどれか、長寿命のフラグのうち、今では他の場所に属する恒久的な設定として機能しているものはあるか。規制対象の環境では、本番でフラグを変えられるのは誰で、その変更がデプロイと同じ厳密さで記録されるかを加えてください。パイプラインが一度も走らなくても、フラグの切り替えはリリースだからです。
人間のゲートを伴う継続的デリバリーと完全な継続的デプロイの境界はどこにあり、ロールバックの閾値を設定するのは誰ですか。 継続的デリバリーは、リリースのタイミングを人の制御下に置き、法定の変更の窓や影響範囲の大きいシステムに合い、継続的デプロイは、通過したすべての変更を自動的に出荷し、安全であるために成熟したテスト、オブザーバビリティ、自動化されたロールバックを要求します。大きなあるいは規制対象の組織では、答えが一様であることはまれです。マーケティングのサイトは継続的にデプロイでき、決済の中核は文書化された人間のゲートを保つかもしれず、その線をサービスの階層ごとに引くことが、不要な摩擦と無謀な自動化の両方を防ぎます。相反する考慮は、速度とバッチサイズ対制御と監査可能性、そして自動化されたロールバックが要求するヘルス指標のエンジニアリングのコストです。証拠を持ち込んでください。サービスごとの変更失敗率、平均復旧時間、現在のリリース周期、人間なしに昇格あるいはロールバックするのに信頼するであろう客観的なシグナル(エラー率、レイテンシ、飽和)。政府と企業の設定では、各階層を、誰がロールバックの閾値を所有し、ゲートされたリリースから完全な自動化への移行を誰が承認するかに結びつけ、決定がずれるのではなく意図されたものになるようにしてください。

セクター別の視点

スタートアップ。 初日からマネージドなCI/CDに頼ってください。ホスト型のランナー、一つのパイプライン、一つの不変のイメージ、マージ時のステージングへの自動デプロイ。保守しなければならないパイプラインのインフラストラクチャは築かないでください。フィーチャーフラグにより、二、三人のエンジニアが未完成の作業を安全にマージして一日に数回出荷でき、ワンクリックの本番デプロイと速いフラグオフは、規模がさらに求めるまで必要な変更管理のすべてです。

小規模事業者。 専任のプラットフォームあるいはリリースのエンジニアがいないので、カスタムのものより、ソースのホストが与えるパイプライン(組み込みのActionsなど)とその既定のデプロイの戦略を好んでください。築くか買うかの選択を誠実に枠づけます。マネージドなパイプラインと組み込みのロールバックを備えたホスティングのプラットフォームは、オーダーメイドのセットアップが消費するエンジニアの時間よりコストが低い。本質を保ちます。一度構築する、同じ成果物を昇格させる、簡単な巻き戻し。量が正当化するまで、プログレッシブデリバリーの仕組みは飛ばします。

大企業。 中核の問題は多くのチームにわたる一貫性です。品質がチームごとに変わらないよう、レビュー、スキャン、署名された不変の成果物、階層ごとのデプロイの戦略を徹底する共有のパイプラインのテンプレートを標準化してください。パイプラインの定義をレビューされたコードとして扱い、変更管理の証拠を自動的に捉え、フィーチャーフラグとロールバックの閾値を、各チームの私的な習慣ではなく統治された資産として管理します。見返りは、より速いデリバリーと、四半期ごとの大慌てではなく副産物として生まれる監査の証拠です。

政府。 調達規則、法定の変更の窓、公的な説明責任がパイプラインを形づくります。重大なシステムには、完全な自動化より、文書化された人間のリリースゲートを伴う継続的デリバリーを好み、日常の作業を事前承認された標準の変更に分類し、狭い年次の窓の間、市民が頼るサービスには即座のロールバックの経路(ブルーグリーンあるいは自動化されたカナリア)を保ちます。パイプラインが、誰が各変更を承認し、どのテストが走り、どの成果物がデプロイされたかを記録することを確認し、透明性と監査の義務が、手作業の書類仕事ではなく通常のワークフローで満たされるようにします。

事例

スタートアップ。 4人のSaaSスタートアップは、ユニットテストを実行し、一つのDockerイメージを構築し、mainへのマージのたびに同じイメージをステージングに自動的にデプロイする、単一のGitHub Actionsのパイプラインを配線します。本番のデプロイはワンクリックで、創業者たちは、数週間ブランチを生かし続ける代わりに、フラグの背後に未完成の作業をマージできるよう、フィーチャーフラグに頼ります。悪いリリースがすり抜けたとき、数秒でフラグをオフにして落ち着いて直せるので、専任の運用担当なしに、小さなチームが一日に数回出荷し続けられます。

大企業。 世界的な銀行は、数十のチーム固有のJenkinsのジョブを、すべてのプロダクトチームが引き継ぐ標準化されたパイプラインのテンプレートに統合します。テンプレートは、静的解析、依存関係のスキャン、署名された不変の成果物を徹底し、エラー率とレイテンシの閾値に結びついた自動化されたロールバックを伴うカナリアでデプロイします。同じ成果物がテストから本番まで昇格され、すべてのゲートが記録されるので、銀行の監査人は、どの本番のバイナリもそのコミット、レビュー、承認まで数秒でたどれ、四半期ごとの手作業の証拠収集に置き換わります。

政府。 申告システムをモダナイズする国の税務当局は、申告期間の法定の変更の窓を尊重できるよう、明示的な人間のリリースゲートを伴う継続的デリバリーを採用します。日常の変更は、ステージングに自動的に流れる、標準で事前承認された変更に分類されます。本番のリリースは、パイプラインが記録する、一つの文書化された承認を要します。ブルーグリーンのデプロイは、欠陥が本番に届いたときの即座のロールバックの経路を機関に与え、それは何百万もの市民が狭い年次の窓の間にサービスに頼るときに決定的です。

ビジネスケース: 動機、ROI、TCO

CI/CDへの投資の見返りは、変更のリードタイムの短縮、変更失敗率の低下、インシデントが起きたときの回復の速さとして現れます。研究が一貫して、デリバリーの性能と組織の成果の両方に結びつける指標です。より速く小さなリリースは、規模でエンジニアリングの容量を消費する調整のオーバーヘッドを削り、自動化された検証は、本番の欠陥を火消しする、高価で士気を削ぐ仕事を削ります。

総所有コストは、採用のコストを採用しないコストと量ります。採用のコストには、パイプラインの構築と保守、テストカバレッジの拡大、オブザーバビリティとプラットフォームの人員への投資が含まれます。採用しないコストはより大きいが見えにくい。遅い手作業のリリース、統合の苦痛、評判を損なう本番のインシデント、そして規制対象の設定では、失敗した監査と是正。リーダーシップには、論拠はリスクの低減と容量の観点で枠づけるのが最善です。自動化は、乏しい上級エンジニアの時間を、繰り返しのリリースの苦役からプロダクトの仕事に変え、障害をまれで短くします。

アンチパターンと落とし穴

雪片のパイプライン。 すべてのチームが独自のパイプラインを手作りし、改善と修正が共有できず、品質が大きくばらつくこと。
環境ごとの再構築。 段階ごとの再構築は「一度構築」の保証を壊し、微妙な違いが本番に届くのを許すこと。
無視された赤いビルド。 壊れ続けるメインラインを容認することは、パイプラインへの信頼を破壊し、失敗の上に出荷することを普通にすること。
放置された不安定なテスト。 断続的な失敗は、開発者に緑になるまで再実行するよう訓練し、ゲートの目的を損なうこと。
手作業の承認の劇場。 すべてにゴム印を押す変更諮問委員会は、安全を加えずに遅延を加えること。
フラグの負債。 決して取り除かれないフィーチャーフラグは、保守できない条件分岐の複雑さに積み上がること。
デプロイがリリース。 二つを結合すると、ユーザー向けのすべての変更が危険な再デプロイを要すること。

成熟度モデル

レベル1: 開始。 ビルドとデプロイは、おおむね手作業で、その場しのぎで反応的です。統合は遅れて行われ、リリースはまれでストレスが多く、ロールバックは古いバージョンを手で再デプロイすることを意味し、パイプラインのゲートという共有の考えはありません。

レベル2: 発展。 自動化されたビルドとユニットテストが各コミットで走りますが、実践はチームごとに異なります。デプロイはスクリプト化されていますが、まだ手作業で起動され監督され、一部の環境は一貫し、成果物は段階ごとに再構築されることがあります。パイプラインが存在する所でも、共有できない雪片であることが多いです。

レベル3: 標準化。 文書化された標準化されたパイプラインのテンプレートが、チーム間で徹底されます。単一の不変の成果物をすべての環境を通じて昇格させ、自動化された品質とセキュリティのゲートを適用し、レビューの承認とスキャンの結果のような必須のチェックを符号化し、変更の記録を自動的に捉えます。カナリアあるいはブルーグリーンのようなデプロイの戦略が、サービスの階層ごとに意図して選ばれます。

レベル4: 管理。 デリバリーが、ベースラインに対して測定され、制御されます。組織は、変更のリードタイム、デプロイの頻度、変更失敗率、平均復旧時間に加え、パイプラインのp50とp95の所要時間、不安定なテストと再実行の率、フィーチャーフラグの経過日数を追跡します。ロールバックの閾値は観察されたエラー率、レイテンシ、飽和のデータから設定され、ゲートは習慣ではなく証拠に基づいて徹底され、各指標には、目標からずれたときに行動する所有者がいます。

レベル5: オーケストレーション。 デリバリーは継続的に改善され、組織全体に統合されています。自動化された指標駆動のロールバックを伴うプログレッシブデリバリーが標準で、リリースはよく統治されたフラグを通じてデプロイから切り離され、コンプライアンスの証拠は副産物として自動的に生成されます。パイプラインは資産群が変わるにつれて適応し、デリバリーの指標はビジネスとリスクの計画に供給されるので、投資が最もてこの効く改善に流れます。

議論のためのアイデア

最も重要なシステムにとって、人間のゲートを伴う継続的デリバリーと完全な継続的デプロイの境界は、どこにありますか。
必須の変更管理のプロセスを、ゴム印の劇場にせずに意味あるものに保つにはどうしますか。
自動化されたロールバックを統治すべき客観的なヘルス指標は何で、その閾値は誰が所有しますか。
プラットフォームチームは、標準化されたパイプラインのテンプレートと、特殊な要件を持つチームの正当なニーズをどうバランスさせるべきですか。
フィーチャーフラグが負債になる前に退役させる方針とツールは何ですか。
より速いデリバリーが、単により多く出荷するのではなく、ビジネスの成果を実際に改善しているかを、どう測りますか。

要点

CI、CD、継続的デプロイは別個のものです。リスク許容度と成熟度に合う自動化の水準を選びます。
成果物を一度構築し、同一の成果物をすべての環境を通じて昇格させます。
パイプラインを、速いフィードバックのために最適化された順序づけられた品質ゲートとして設計し、権威ある出荷の決定として扱います。
デプロイの戦略を意図して選び、影響範囲を限るために、自動化されたロールバックを伴うプログレッシブデリバリーを採用します。
フィーチャーフラグでリリースをデプロイから切り離し、フラグの負債を管理します。
規制対象の環境では、変更管理の証拠を、手作業の書類仕事ではなく自動的に捉えます。

参考文献とさらなる読み物

Jez Humble and David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, “Feature Toggles (Feature Flags)” (essay).
ITIL (Information Technology Infrastructure Library), change management guidance.