# 継続的デプロイ ## 定義 継続的デプロイ(continuous deployment)は、コードを書いたらすぐにプロダクションへ反映する開発プラクティスであり、バッチサイズ(→ [[バッチサイズ]])を最小化することで開発チームのプロセスの無駄を減らし、仕事のテンポを速める取り組みである。継続的デプロイでは「リリース」を2つの意味に分ける。1つめはエンジニアが使うもので、コードをプロダクションに統合するプロセスを指す。2つめはマーケティングが使うもので、顧客が見えるものを指す。従来の開発ではソフトウェアをデプロイするとすぐに顧客の目に見えるため2つの意味は関連していたが、継続的デプロイはこの2つを分離し、エンドユーザに見える変更は「フラグ」(→ [[フィーチャーフラグ]])で隠しておき、準備ができたら見せるようにする。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1) 継続的デプロイの導入は、次の5つの手順として漸進的に構築できる。既存のソフトウェアのインストールと設定だけで済むため、長くても1〜2週間以内に基盤を整えられる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.6) 1. **継続的統合サーバ**: 自動テスト(ユニット・機能・統合テスト等)を実行し、すべてのコミットを監視する中心的な場所。テストが少なくても「バグを修正するたびに新しい自動テストを追加する」というルールから始めればよい。 2. **ソース管理コミットチェック**: コミットを受け付ける前に任意のスクリプトを実行できるソース管理サーバ。継続的統合サーバでテストが失敗した場合、そのコードをリポジトリに反映させない「製造ライン」の管理(「ラインを停止」ルール)がこの段階の本質である。 3. **シンプルなデプロイスクリプト**: バージョン番号付きディレクトリへの rsync とシンボリックリンクの張り替えといった単純な仕組みから始め、時間をかけて改善する。IMVU の「[[クラスタ免疫システム]]」のような高度な自動デプロイシステムも、最初はここから育った。 4. **リアルタイムアラート**: Nagios のような監視プラットフォームで、システムの基本統計だけでなく同時ユーザ数や時間あたりの収益といったビジネスメトリクスも監視する。「ポケベルが鳴ったら製造ラインを止める」というルールを併せ持つ。 5. **根本原因分析(5つのなぜ)**: 問題の真の原因を再帰的に「なぜ」を問いかけて掘り起こす。「常に割に合う投資をすること」(分析コストが問題のコストを下回ること)というルールを課し、コードやアーキテクチャの20%に原因が集中する80/20の法則を踏まえて投資先を選ぶ。 継続的デプロイには、デプロイに問題が発生した際に誰もデプロイできなくなり、チーム全体が原因追及と問題解決に当たることになる「スピード調整器」としての役目もある。個人の生産性でチームの進捗を測る組織にはこの仕組みが扱いにくいことがあるが、著者はこれがチーム全体のスループットを重視する考え方だと位置づける。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1) ## 横断的知見 - **同じ『ウェブオペレーション』の4章・10章は、それぞれ独立に「デプロイとリリースの分離」を、フィーチャーフラグという同一の機構で解決している**: 4章(Eric Ries)は「リリース」をエンジニアが使う意味(プロダクションへの統合)とマーケティングが使う意味(顧客に見える変更)に分け、フィーチャーフラグでエンドユーザから機能を隠しながら継続的にデプロイすることを提案する。10章(Paul Hammond)は同じ機構を、インフラ障害時に依存機能を無効化しつつ他の部分のサービスを継続させるという運用上の必要性から独立に導出し、Flickr の実装(主要でないインフラを無効化するフラグ・外部サービス依存を無効化するフラグ等の4分類)を示す。動機づけの軸(4章: エンジニアリングとマーケティングの分離/10章: 障害時のインフラ縮退)は異なるが、両者は同じ2011年の書籍の異なる章として、フィーチャーフラグという1つの機構に別々の角度から到達している。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] §10.4.2) - **IMVU の「クラスタ免疫システム」(1台ずつの段階的展開+健康監視+自動リバート+デプロイロック)は、[[変更起因インシデント]] concept が集約する Gandalf・カナリア分析サービスのような自動化ロールアウト監視システムの、10年近く先行する実務的な原型である**: 変更起因インシデント concept は、カナリアリリースでは変更起因インシデントの76.8%がデプロイ中に顕在化すること、Google の Canary Analysis Service がカナリア/対照母集団のペアごとに統計検定を行い1つでもFAILすれば評価全体を即座にFAILとして返す設計であること、Microsoft の Gandalf が同時多発するロールアウトの中から犯人コンポーネントを時空間相関で特定することを示す。4章のクラスタ免疫システムは、これらの自動化システムが後年に精緻化した「デプロイ中の早期異常検知→自動停止」という考え方を、2011年時点で「1台ずつ展開し健康状態を監視、問題があれば拒否・リバートしロックする」という単純なルールベースの形ですでに実装していた。統計的手法や相関アルゴリズムは持たないが、目的とする効果(問題のある変更をクラスタ全体に広げる前に食い止める)は同型である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.4, §4.6.3) - **ビルド・テスト・デプロイの自動化という同一のプラクティスが、2011年は「トイル削減とテンポの向上」、2020年は「敵対者による改ざんの防止」という異なる動機で独立に要求される**: 4章(既出)の継続的デプロイ導入5手順は、継続的統合サーバ・ソース管理コミットチェック・シンプルなデプロイスクリプトの整備を、開発チームのプロセスの無駄を減らしテンポを速めるための漸進的な基盤づくりとして提示する。[[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] §Best Practices > Rely on Automation は同じ「ビルド・テスト・デプロイ手順の自動化」を、エンジニアが誤って未レビューのコードをビルドしたり、悪意ある敵対者が手作業のビルドを改ざんしたりする機会を減らすためのセキュリティ対策として要求し、さらに「自動化システムの設定変更にもピアレビューを課す」「自動化システム自体を管理者の改ざんからロックダウンする」という、4章には存在しない追加要件を課す。同一の技術的プラクティス(自動化)が、生産性向上の文脈では「あればあるほど良い漸進的改善」として、セキュリティの文脈では「これを怠ると内部者リスクに直結する必須要件」として、異なる重みづけで語られている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.6, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] §Best Practices > Rely on Automation) - **IMVU の「クラスタ免疫システム」と ch14 の「デプロイブレークグラス」は、どちらも人間による緊急時のデプロイ介入を扱うが、介入の方向が正反対である**: 本ページ既出の知見が示すクラスタ免疫システムは、健康監視で異常を検知すると自動的にデプロイを拒否・リバートし「ロック」する——つまり通常のデプロイフローを**止める**方向の安全策である。ch14 のブレークグラス機構は逆に、緊急時にデプロイポリシー(通常のセキュリティ検証フロー)を人間が**迂回**して即座にデプロイを通す方向の安全策であり、障害復旧のような可用性上の緊急性が、通常の変更管理プロセスより優先される場面のために用意される。ch14 はブレークグラスの濫用を防ぐため「必ず警報を上げ迅速に監査される」「発生頻度が稀でなければ悪用と正当な利用を区別できなくなる」という運用要件を課す。両者を並べると、デプロイパイプラインの「人手による介入ポイント」は、品質を守るために流れを止める方向(クラスタ免疫システム)と、可用性を守るために検証を飛ばす方向(ブレークグラス)の両方向に必要であり、どちらも「稀であること」と「監査可能であること」を安全に機能させる条件として共有していることがわかる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.4, §4.6.3, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] §Practical Advice > Include a Deployment Breakglass) - **本ページの「継続的デプロイ」は、Accelerate 第4章が定義する「継続的デリバリ」の一部分であり、両者は本書の訳語上でも明確に区別される**: 本ページ既出の定義(Eric Ries, 2011)は「コードを書いたらすぐにプロダクションへ反映する」という具体的な実践そのものを指すが、[[継続的デリバリ]] concept が扱う Accelerate 第4章の定義は「安全かつ迅速かつ持続可能な形で変更を本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティ」という、より広い能力の集合を指す。Accelerate 第4章が2017年の追加分析で測定した一次的構成概念の1つは「本番デプロイをオンデマンドで行える」能力であり、これは「常に自動的に実行する」ことではなく「いつでも実行できる」ことを要求するにとどまる。両概念はバージョン管理・CI・自動化テストという技術的基盤を共有するが、継続的デプロイはその基盤の上に立つ具体的な運用方針の1つであり、継続的デリバリはその基盤自体を含むケイパビリティの総称である点で、上位概念と下位概念の関係にある。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.1, §4.2) - **2019年の学術サーベイのDelivery概念地図(図7)は、本ページと[[継続的デリバリ]] concept が『ウェブオペレーション』4章・Accelerate 第4章から抽出する上位/下位の区別を採らず、継続的デプロイと継続的デリバリを単一ノードとして描く**: 本ページ既出の知見は、継続的デプロイ(具体的実践)と継続的デリバリ(能力の集合)を上位/下位概念として整理してきたが、Leite et al.(2019)第5章の図7は「Continuous Delivery / Continuous Deployment」を1つのノードとして扱い、いずれもFrequent and reliable release processによって実現され(implemented by)、Automationを可能にする(enables)という同一の関係を持つとする。本文(§5.3)もこの2語を明示的に区別しない。これは、DevOpsの概念地図を文献の系統的分析から構築するという学術的アプローチが、継続的デリバリ/継続的デプロイという語彙レベルの区別よりも、「デプロイメントパイプラインの自動化」という上位の技術的枠組みを重視していることを示す一次資料であり、本ページが依拠する実務書2冊(Accelerate・『ウェブオペレーション』)がこの区別を精緻化しているのとは対照的な粒度である。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5.3 図7, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1) ## 未解決の問い - 4章は「デプロイの準備ができたらすぐにデプロイできる」ことを開発者のモチベーション向上の根拠として挙げるが(§4.8)、この主張を裏付ける定量データ(離職率・生産性指標など)は本章では示されない。他ソースでの検証は可能か。 - Accelerate 第4章は継続的デリバリの実践度がデプロイ関連の負荷とバーンアウトを軽減すると定量的に示すが、これが本ページの継続的デプロイ(コードを書いたらすぐにプロダクションへ反映する運用)にどこまで当てはまるかは、継続的デリバリ(オンデマンドで「できる」)と継続的デプロイ(常に自動で「する」)の違いを踏まえるとそのまま外挿できない。両者の効果の違いを直接比較した後続ソースが必要。 - クラスタ免疫システムの「1台ずつの段階的展開」は、対象システムの規模(クラスタのマシン数)にどこまで依存する設計か。マシン数が極めて多い環境や、少数のインスタンスしかない環境でも同様に機能するかは4章では論じられていない。 - 4章が示す5つの手順は、テストカバレッジがほぼゼロの既存プロジェクトから継続的デプロイへ移行する場合の具体的な移行順序(どのテストから書き始めるべきか等)までは踏み込んでいない。既存の大規模レガシーシステムでの導入事例との突き合わせが必要。 - ch14 が要求する「自動化システムの設定変更へのピアレビュー」「自動化システム自体のロックダウン」は、4章のクラスタ免疫システムやシンプルなデプロイスクリプトのような、2011年時点の継続的デプロイ基盤にどこまで後付けできるか。両ソースを比較するだけでは、セキュリティ要件を後から追加する際の移行コストは判断できない。 - Leite et al.(2019)の概念地図が継続的デプロイと継続的デリバリを単一ノードとして扱う理由は、概念地図の抽象度が単に粗いためか、それとも学術的な定義として両者を同一視すべき論拠があるのか。第5章の現ソース群では判断できない。[[継続的デリバリ]] concept の同種の未解決の問いも参照。 ## 関連 - 概念: [[バッチサイズ]](本概念を支える理論的基盤) / [[フィーチャーフラグ]](デプロイとリリースを分離する具体的機構) / [[ソフトウェア変更管理]] / [[変更起因インシデント]] / [[ソフトウェアサプライチェーンセキュリティ]](自動化・ブレークグラスをセキュリティ脅威モデルの観点から扱う) / [[継続的デリバリ]](本概念を包含する上位のケイパビリティ群) - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] / [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](継続的デプロイ/継続的デリバリを単一ノードとして扱う概念地図との対比) - 実体: [[Eric Ries]] / [[IMVU]] / [[クラスタ免疫システム]] / [[Paul Hammond]] / [[Flickr]] ## 出典 - エリック・ライズ, 「継続的デプロイ」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 4章. - ポール・ハモンド, 「開発と運用の協力と連携」, 同書, 10章, §10.4.2. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 14 (Written by Jeremiah Spradlin and Mark Lodato). - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第4章. - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §5.3 図7)— Delivery概念地図が継続的デプロイ/継続的デリバリを単一ノードとして扱う