リリース前になると、なぜかチームが静かになる。
コードフリーズが始まり、結合テストの日程が引かれ、リリース当日は夜に集まる。
そんな進め方を経験したことがある人は多いはずです。
継続的デリバリー（Continuous Delivery、CD）は、この「リリース前の特別な期間」そのものを無くそうとする考え方。
言い換えれば、いつ出せと言われても出せる状態をコードに保たせ続ける取り組み。
私自身もまだ学んでいる途中ですが、CD は「速く出す技術」というより「怖くなく出す技術」だと理解しています。
CDの定義は「安全に・速く・持続可能に届けられる能力」
まずは言葉の定義から。
継続的デリバリーの提唱者ジェズ・ハンブルらによる公式サイトは、CD を「新機能、設定変更、バグ修正、実験といったあらゆる種類の変更を、安全に、素早く、持続可能なやり方で本番環境やユーザーの手元へ届けられる能力」と定義しています。
Continuous Delivery
注目したいのは「能力（ability）」という語。
CD はツールの名前でも、特定の製品を入れれば手に入る状態でもありません。
同サイトは、コードを常にデプロイ可能に保つことで統合フェーズやコードフリーズを丸ごと無くすと説明しています。
つまり CD が消しにいくのは、作業ではなく「リリース前にだけ発生する特別な儀式」のほう。
DORA の記述も同じ方向で、変更を必要なときにいつでも低リスクで本番へ出せる能力を CD と呼び、通常の業務時間中でもデプロイできることを到達点に置いています。
Continuous delivery（DORA）
CIとの違いは「どこまでを常に保つか」
CI と CD は「CI/CD」とまとめて語られがちですが、守備範囲が違います。
継続的インテグレーション（CI）が保証したいのは、全員の変更が毎日ひとつのメインラインへ統合され、壊れていないこと。
継続的デリバリーが保証したいのは、その先の「統合されたものが、いつでもリリース可能な状態にあること」です。
ビルドが通ることと、本番へ出せることの間には距離がある。
その距離を埋めるのが、環境構築・データベース変更・受け入れテストといった、CI だけでは触れない領域。
DORA は CD の説明のなかで、CI を「実装要素のひとつにすぎない」と位置づけ、信頼できるリリースには開発者以外を含む全員の関与が要ると述べています。
ここが CD の一番の難所ではないでしょうか。
CI はツールで買えるが、CD は組織で作るという非対称さがあります。
DevOps という言葉そのものの整理は、こちらでどうぞ。
デプロイパイプラインが「出せる状態」を証明する
では、リリース可能かどうかは誰が判断するのでしょうか。
CD ではこれを人の勘ではなく、デプロイパイプラインという自動化された経路で判定するのです。
公式サイトは、ビルド・デプロイ・環境のプロビジョニング・回帰テストを自動化することで、統合とテストを日々の作業へ組み込めるようになると説明しています。
環境のプロビジョニングをコードで扱う考え方は、IaC として別の記事で整理しました。
パイプラインの各段階は、この変更を本番へ出してよいかを否定する試みだと捉えると分かりやすい。
どの段階も否定できなかった変更だけが、リリース候補として残ります。
だから通過したかどうかが、そのまま「出せる状態」の証明になる。
ここで気をつけたいのが、継続的デプロイメント（Continuous Deployment）との混同です。
CD（デリバリー）は「いつでも出せる状態を保つ」ところまでで、実際に出すかどうかはビジネス側の判断として残します。
パイプラインを通った変更を全部そのまま自動で本番へ流すのが、継続的デプロイメントのほう。
同じ CD という略語でも、リリース判断を人が握るか機械に委ねるかが分かれ目になります。
痛いことほど頻度を上げる
CD の実践で最も反直感的なのが、この原則ではないでしょうか。
公式サイトは「もし痛いなら、もっと頻繁にやって、痛みを前倒しにせよ」という規律を掲げています。
半年に一度のリリースが怖いのは、変更が積み上がって因果関係が追えなくなるから。
毎日出していれば、壊れたときに疑うべき変更は 1 日ぶんに絞られる。
DORA は CD がもたらす効果として、品質向上や手戻りの削減に加えて、デプロイ時の不安や恐怖の軽減、バーンアウトの低下、職務満足度の向上まで挙げています。
技術指標ではなく、働く人の状態が並んでいるところが印象的でした。
DORA が挙げる実践には、テスト自動化・デプロイ自動化・トランクベース開発・バージョン管理・監視と可観測性・データベース変更管理などが含まれます。
どれもいきなり全部はそろわないので、どの実践が自分たちのボトルネックかを先に見立てるのが現実的な入り方。
チームで何を先に決めるかという観点は、こちらとも地続きです。
最後に
継続的デリバリーは、変更を安全・迅速・持続可能に届けられる能力を指す言葉でした。
CI が「壊れていないこと」を保つのに対し、CD は「いつでも出せること」を保つ。
その判定をデプロイパイプラインへ委ね、リリースするかどうかの判断は人の側に残します。
そして痛みを感じる工程ほど頻度を上げ、コードフリーズという特別な期間を消していく。
怖くないリリースを作ることが、結果として速さにもつながる仕組みだと感じます。
出す単位を機能ごとに切り替える段階リリースの組み立ては、別記事にまとめました。
以上です。
コメントを残す