11.2 デリバリーパイプライン
概要と動機
デリバリーパイプラインは、検証されたアイデアを、ユーザーの手の中の動くソフトウェアに(確実に、繰り返し可能に、測定可能に)変え、それから得られた成果のデータをディスカバリー(11.1章)にフィードバックする仕事のフローです。それは、コードのコミットから本番の変更、ユーザーと事業への測定された効果への産業化された道です。ディスカバリーが何を、なぜに答えるのに対して、デリバリーはどう安全に出荷し、どれだけ速く、実際に機能したかに答えます。
この章は意図して統合的です。仕組みは他所に詳しく書かれています。テスト戦略(2.4章)、テストとプロセスの自動化(8.5章)、継続的インテグレーションと継続的デリバリー(CI/CD)とデプロイ戦略(8.1章)、インフラストラクチャ・アズ・コード(8.2章)、信頼性とSLO(サービスレベル目標、9.1章)、実験(7.4章)。ここではそれらを端から端までの一つのパイプラインに組み立て、そして決定的に、機械全体が単にリリースを生んでいるのではなく、価値を生んでいるかを教えるアウトカムの指標を付けます。
大きなチームにとって、デリバリーパイプラインは、エンジニアリングの有効性における、てこが最も効く唯一の投資です。『Accelerate』にまとめられた、最も顕著にはDORA(DevOps Research and Assessment)プログラムの10年にわたる研究は、速く、自動化され、リスクの低いデリバリーパイプラインを持つチームが、スループットと安定性と組織の成果で優れることを示しています。速度と安全がトレードオフになるという古い信念は、経験的に誤りです。企業では、強いパイプラインが、数百人のエンジニアがマージの混沌と手作業のリリースの劇場に崩れることなく統合できるようにするものです。政府では、(歴史的に失敗したプログラムの主因だった)高儀式で四半期ごとの全部かゼロかの「一斉」のリリースを、変更管理の義務に、それに逆らってではなく自動化を通じて応える、小さく、元に戻せ、監査可能な変更に置き換えます。
主要原則
- 繰り返し可能なものはすべて自動化する。 手作業のステップは遅く、間違いやすく、監査できません。
- 小さなバッチ、頻繁なリリース。 小さな変更は、レビュー、テスト、出荷、取り消しが容易です。
- 品質を組み込む。 速い自動テストとゲートが、本番の後ではなく前に欠陥を捉えます。
- デプロイとリリースを分ける。 コードを暗く出荷し、準備ができたらフラグで機能をオンにします。
- すべてを元に戻せるようにする。 速いロールバックと段階的な露出が、デプロイを賭けから実験に変えます。
- パイプラインが真実の源である。 バージョン管理とパイプラインにないなら、起こらなかったことです。
- アウトプットではなくアウトカムを測定する。 デプロイの数はアウトプットで、動かされた指標がアウトカムです。
推奨事項
テストスイートを自動化し、それでゲートする
テストの自動化は、速いデリバリーを安全にする基礎です。バランスのとれた、大部分が自動化されたテストのポートフォリオ(2.4章)を実装します。多くの速いユニットテスト、より少ない統合テストと契約テスト、少数のエンドツーエンドのテスト、加えて自動のセキュリティ(SAST/DAST/SCA:静的、動的、ソフトウェア構成の分析)、アクセシビリティ、パフォーマンスのチェック。それらをパイプラインの品質ゲートとして走らせ、合格しない変更は本番に届かないようにします。スイートを速く信頼できるものに保ちます。遅い、あるいは不安定なスイートは迂回され、目的を損ないます(8.5章)。コミットの数分以内に、開発者に明確な合否のシグナルを与えるパイプラインを目指します。
継続的インテグレーションと継続的デリバリーを実践する
継続的インテグレーション(CI): すべての開発者が小さな変更を頻繁に(理想的には毎日)メインラインにマージし、各マージが自動のビルドとテストの実行を引き起こします。これは、ブランチを短命に保ち、統合を継続的にするトランクベース開発(2.6章)に最もよく支えられます。継続的デリバリー(CD): パイプラインを通過したすべての変更は、常にリリース可能な状態にあり、オンデマンドでデプロイできます。継続的デプロイはさらに一歩進みます。合格したすべての変更が自動的に本番にデプロイされます。リスクの姿勢に合った自動化の水準を選びます。規制対象の環境は、管理された昇格のステップ(8.1章)を伴う継続的デリバリーで止まるかもしれませんが、そのゲートまでのすべてを自動化すべきです。
段階的な戦略で安全にデプロイする
デプロイ(本番で動くコード)をリリース(ユーザーが変更を体験すること)から切り離し、変更を徐々に公開します。
- フィーチャーフラグは、コードを暗くデプロイし、オンデマンドでセグメントにリリースし、切り替えで即座にロールバックできるようにします。
- カナリアリリースは、トラフィックの小さな割合を新しいバージョンにルーティングし、広げる前にヘルス指標を観察します。
- ブルーグリーンデプロイは、二つの環境を保ち、トラフィックを原子的に切り替え、即座のロールバックを可能にします。
- ローリングデプロイは、インスタンスを段階的に置き換えます。
- プログレッシブデリバリーは、フラグ、カナリア、自動分析を組み合わせ、生きたシグナルに基づいて昇格あるいはロールバックします。
すべての戦略を、SLOの違反やエラーバジェットのバーン(失敗が許容される不信頼性のバジェットを消費する率。9.1章)で起動される自動ロールバックと組み合わせます。仕組みは8.1章を参照してください。
アウトカムの指標を計装する: パイプラインとインパクトを測定する
速く出荷するが間違ったものを出荷するデリバリーパイプラインは、速い無駄です。三つの水準で測定します。
デリバリーのフロー、四つのDORA指標:
信頼性と品質、SLIとSLO(サービスレベル指標と目標。9.1章): サービスは、各変更の後、信頼性の目標と品質特性のコミットメント(11.1章)を満たしているか。
事業とユーザーの成果(7.3–7.4章): 変更は、ディスカバリーが定義した主要な結果とKPIを動かしたか。ここでリリースが実験に出会います。フラグの背後で出荷し、対照に対して測定し、勝ったものだけを保つ。
ディスカバリーへのループを閉じる
デリバリーパイプラインの最後の行為はデプロイではなく証拠です。成果の指標(アクティベーションは上がったか、チェックアウト時間は下がったか、サポートチケットは減ったか)は、次のラウンドの賭けの基礎として、ディスカバリーパイプライン(11.1章)にフローバックします。ディスカバリーとデリバリーがこのフィードバックのループで結ばれると、組織は学習するシステムになります。仮説は出荷され、測定され、スケールされるか元に戻される、継続的に。
デリバリーを監査可能で統治されたものにする
企業と政府の設定では、パイプライン自体をコンプライアンスの統制として扱います。すべての変更がバージョン管理と自動のパイプラインを流れるので、不変の監査証跡が「ただで」得られます。誰が何を変更し、どのテストと承認がそれをゲートし、いつデプロイされたか。職務の分離、必須のレビュー、ポリシーのチェックをポリシー・アズ・コード(機械で徹底できるバージョン管理された形で表現されたガバナンスのルール。8.2章)として符号化し、変更管理が自動的に徹底され、監査の前に手作業で再構成されるのではなく、継続的に証拠が示されるようにします(4.6章と10.2章)。
トレードオフ: 長所と短所
| 決定 | 長所 | 短所 |
|---|---|---|
| 継続的デプロイ(本番へ自動) | 最速のフィードバック。最小のバッチ。最少の手作業の苦役 | 成熟したテスト、監視、ロールバックが必要。規制対象のゲートでは難しい |
| 手作業の昇格を伴う継続的デリバリー | 人間/コンプライアンスの制御点。監査に優しい | 遅い。ゲートで変更をバッチ化するリスク |
| フィーチャーフラグ | デプロイ/リリースの分離。即座のロールバック。ターゲティング | 刈り込まなければフラグの負債と組み合わせの複雑さ |
| カナリア/プログレッシブデリバリー | 影響範囲を限る。データ駆動の昇格 | 強いオブザーバビリティとトラフィック管理が必要 |
| ブルーグリーン | 即座の切り替えとロールバック | 環境のコストが倍。ステートフルなデータ移行が難しい |
| 重い手作業のリリースプロセス | 制御されているように感じられる。監査人になじみがある | 遅く、間違いやすく、再現できず、実際にはよく監査されない |
歴史的なトレードオフの信念、速く行けばもっと壊すは、退役させるべき重要なものです。証拠は、速度を高める実践(自動化、小さなバッチ、速いテスト、可逆性)が、安定性を高める同じ実践であることを示します。本物のトレードオフは、速度対安全ではなく、投資と制御の粒度についてです。
チームで議論すべき問い
あなたの実際のリスクの姿勢は何で、それは継続的デプロイではなく継続的デリバリーで止まることを正当化しますか。 自動化の水準を選ぶことは、既定ではなく本物の決定です。継続的デプロイは最速のフィードバックと最小のバッチを与えますが、成熟したテスト、強いオブザーバビリティ、即座のロールバックを要求するので、規制対象の文脈は、管理された昇格のゲートで止まることが合理的でありえます。証拠を持ち込んでください。変更失敗率、復旧時間、テストスイートの信頼性。それらが、本番への自動が今日安全かを教えます。企業と政府では、ゲートまでのすべてを自動化し、ゲート自体をポリシー・アズ・コードにして、人間のステップが手作業の苦役を加えずに制御を加えるようにします。パイプラインが悪い変更を捉えると信頼できないなら、スイッチを入れる前にゲートとオブザーバビリティに投資してください。
パイプラインは、規制当局が尋ねる監査証拠を、誰も手作業で再構成せずに生み出せますか。 パイプライン自体をコンプライアンスの統制として扱います。すべての変更は、誰が何を変更し、どのテストと承認がそれをゲートし、いつデプロイされたかの不変の跡を、自動的に生成して運ぶべきです。企業と政府では、職務の分離と必須のレビューをポリシー・アズ・コードとして符号化し、変更管理が、監査の前にパニックの中で組み立てられるのではなく、継続的に徹底され証拠が示されるようにします。持ち込むべきシグナル。最近の本番の変更を一つ選び、その承認とテストの完全な跡を5分で出してみます。できないなら、手作業の監査準備に払い、自動化が取り除くはずのリスクを抱えています。
リリースが本番で劣化し始めたとき、何がロールバックを起動し、それは自動ですか。 可逆性が速度を無謀ではなく合理的にするので、ロールバックの引き金は明示的な設計に値します。SLOの違反やエラーバジェットのバーンが自動的にロールバックするのか、ユーザーが苦しむ間に人間が気づき、決め、行動しなければならないのかを決めてください。最近のいくつかのインシデントを持ち込み、「指標が劣化し始めた」から「変更が元に戻された」までの隔たりを測ります。その隔たりが本当の影響範囲です。一日に何度も出荷する大きなチームでは、手作業のロールバックはスケールせず、フラグとカナリア分析が生きたシグナルで昇格あるいは巻き戻しできるようにします。答えが「誰かがページングされて何とかする」なら、すべてのデプロイを不可逆な賭けとして扱っています。
機能を出荷したとき、それが動かすはずだった指標を実際に動かしたかを測りますか。それともデプロイを数えて先へ進みますか。 速く出荷するがインパクトを確認しないパイプラインは速い無駄で、アウトプットとアウトカムの隔たりは、ほとんどのデリバリーの投資が静かに漏れる所です。大きな組織では、週に数百のリリースが、デプロイ頻度をスコアボードとして扱いたくさせますが、頻度は価値ではなく動きを測ります。相反する引力は、アウトカムの測定が計装、対照群、負けている機能をオフのままにする規律のコストを要することです。最近出荷した機能をいくつか持ち込み、それぞれについて、ディスカバリーが定義した対象の指標、測定された前後、動かなかったときに何をしたかを示してください。企業と政府のポートフォリオでは、誰が固定の周期で成果をレビューし、出荷されたが元を取らなかった機能を退役させる権限を誰が持つかを名指ししてください。測定する説明責任を誰も負わない変更は、誰も決してオフにしない変更だからです。誠実なテストは、証拠が負けたと言ったために元に戻した機能を指させるかです。
パイプラインが開発者に合否のシグナルを与えるまでどれだけかかり、開発者は迂回しないほどテストを信頼していますか。 フィードバックの速度とスイートへの信頼は、品質ゲートが迂回されるのではなく実際にゲートするようにするもので、コードベースが育つにつれて静かに侵食されます。大きなチームでは、40分かかる、あるいは10回に1回不安定なスイートは、数百のエンジニアに、赤でマージする、チェックを無効にする、緑になるまで再実行するよう訓練し、速く行くことを正当化した安全を静かに取り除きます。相反する考慮は、テストのカバレッジと現実性対フィードバックの速度と安定性で、どちらを押しすぎても他方を損ないます。現在のパイプラインの所要時間、不安定さの再実行率、ゲートが飛ばされたり非ブロッキングに印を付けられたりした証拠を持ち込んでください。それらのゲートがコンプライアンスを満たすSAST、DAST、ポリシーのチェックも運ぶ企業と政府の文脈では、迂回されたゲートは品質のリスクであり、監査の隙間でもあるので、ゲートが本当に必須か単に助言的かを測定してください。開発者が緑のビルドを信頼する理由を言えないなら、ゲートは飾りです。
チーム間でデリバリーの経路を一貫させ、フィーチャーフラグの負債を刈り込むのを誰が所有していますか。それとも、各チームが独自のパイプラインを再発明していますか。 組織が育つにつれ、デリバリーは共有の舗装された道に収束するか、互換性のないゲート、不均一な監査証跡、目的より長生きするフラグを伴う、数十のオーダーメイドのパイプラインに断片化します。緊張は本物です。中央の舗装された道は、一貫性、ガバナンス、規模の経済を与えますが、チームの本物の制約を無視する義務づけは、影のパイプラインと恨みを育てるので、舗装された道は、チームが進んで選ぶほど良くなければなりません。今日いくつの異なるパイプラインが存在するか、フラグの作成と削除がどう統治されているか、最良と最悪のチームの間でリードタイムと監査の質がどれだけ異なるかの目録を持ち込んでください。企業と政府の設定では、コンプライアンスの角度を加えます。一貫しないパイプラインは、職務の分離と変更管理の証拠が各チームで異なる形で(あるいはまったく)証明されることを意味し、ポリシー・アズ・コードを伴う単一の監査された舗装された道は、それをチームごとの賭けから組織の保証に変えます。古いフラグを取り除くのを誰も所有しないなら、組み合わせの負債がいずれシステムをテスト不能にします。
セクター別の視点
スタートアップ。 速度は生存なので、パイプラインは築くのではなく買ってください。トランクベース開発をホスト型のCIランナーに配線し、すべてのマージを速いユニットテストとセキュリティスキャンでゲートし、ホスト型のフィーチャーフラグのサービスの背後で本番に直接デプロイします。プラットフォームチームとオーダーメイドのツールは飛ばしてください。最も乏しい資源はエンジニアリングの注意であり、一人のジェネラリストが保守できるパイプラインは、誰も直す時間のない手の込んだものに勝ります。流れを早期に学び、壊さずに毎日出荷していることを投資家に示せるよう、初日から単純なダッシュボードで四つのDORA指標を追跡します。
小規模事業者。 専任のリリースエンジニアはおらず予算も厳しいので、デリバリーを、人員を置くシステムではなく、マネージドなサービスから組み立てるものとして扱ってください。マネージドなCI/CD、ホスト型のフラグツール、展開とロールバックを代わりに扱うクラウドのプラットフォーム。維持できないカスタムのパイプラインのインフラストラクチャを築くのに抵抗し、経路を、オンコールの人が圧力のもとで理解できるほど単純に保ちます。プログレッシブデリバリーとワンクリックのロールバックをそのまま利用できるツールを好みます。それらの能力こそ、恐ろしい金曜日のデプロイを日常的なものに変えるからです。
大企業。 中核の問題は、多くのチームにわたる一貫性です。チームが再発明するのではなく選んで使う、自動のテスト、セキュリティ、ポリシー・アズ・コードのゲートを備えた、サポートされた舗装された道のパイプライン。DORAとSLOの指標が組織全体で比較可能になるようインターフェースを標準化し、舗装された道を保守するプラットフォームの能力に明示的に予算を付け、フィーチャーフラグとリードタイムの退行を、チームごとの言い伝えではなく統治される資産として管理します。すべての変更が同じバージョン管理されゲートされた経路を流れるとき、ガバナンスと監査は自動的に付いてきます。
政府。 調達規則、透明性、公的な説明責任がパイプラインを形づくるので、職務の分離と必須の承認をポリシー・アズ・コードとして徹底する、自動化された昇格のゲートで止まる継続的デリバリーを好みます。パイプライン自体をコンプライアンスの統制にしてください。すべての変更は、手作業の再構成なしに、変更管理と運用認可の義務を満たす不変の監査証跡を運びます。高儀式の「一斉」のリリースを、小さく、元に戻せ、切り離された変更に置き換えて、公共向けの流れを一つの地域でパイロットし、エラーと完了の率を測り、劣化したら数分でロールバックできるようにします。
事例
スタートアップ。 B2B分析ツールを出荷する3人のエンジニアのチームは、金曜日の午後に手作業でデプロイすることから始め、それは週に一度の恐ろしいリリースと、週末の恐れを意味しました。午後一回で、GitHub Actionsのパイプラインを伴うトランクベース開発を配線します。速いユニットテスト、リンター、セキュリティスキャンがすべてのマージをゲートし、合格したビルドはLaunchDarklyのフラグの背後で本番に直接デプロイされます。デプロイ頻度は週一から一日数回に跳ね上がり、各新機能が暗く出荷されてまず一人の友好的な顧客にオンになるので、壊れたCSVエクスポートは、月曜のインシデントになる代わりに数分で捉えられてオフにされます。投資家にチームが壊さずに毎日出荷していることを示せるよう、単純なダッシュボードで四つのDORA指標を追跡します。
大企業。 世界的な保険会社が、40のチームを共有の舗装された道のパイプライン(チームが選んで使う、サポートされた事前統合の既定のツールチェーン。8.4章)に統合します。トランクベース開発、自動のテストとセキュリティのゲート、SLO違反での自動ロールバックを伴うカナリアデプロイ。デプロイ頻度は月次から日に何度もへ、リードタイムは6週間から1日未満へ、変更失敗率は、バッチが小さくゲートが自動化されているので下がります。決定的に、プロダクトの機能はフラグの背後で出荷され、対照に対して測定されるので、保険会社は各リリースを見積もり完了率への効果に結びつけられ、デリバリーパイプラインを11.1章のディスカバリー側の主要な結果に直接つなげます。
政府。 公的機関が、四半期ごとの「一斉」のリリース(それぞれが手作業のステップの週末で、停止の頻繁な源)を、職務の分離と必須の承認をポリシー・アズ・コードとして徹底する、自動化された昇格のゲートで止まる継続的デリバリーのパイプラインに置き換えます。すべての変更は、機関の変更管理と運用認可(ATO)の義務(4.6章)を満たす不変の監査証跡を運びます。リリースは小さく、頻繁で、元に戻せるようになり、復旧時間は数日から数分に下がり、デプロイがフラグを介してリリースから切り離されているので、機関は全国展開の前に一つの地域で新しい給付の流れをパイロットでき、コミットする前に完了率とエラー率を測れます。
ビジネスケース: 動機、ROI、TCO
デリバリーパイプラインへの投資の見返りは、ソフトウェアで最も証拠に裏づけられたものの一つです。より速いリードタイムとより高いデプロイ頻度は、アイデアがより早くユーザーに届き(そして価値を返し始める、あるいは修正される)ことを意味します。より低い変更失敗率とより速い復旧は、停止、火消し、評判と規制上の損害が少ないことを意味します。DORAの研究は、これらの能力を、エンジニアリングの快適さだけでなく、優れた商業的および組織的なパフォーマンスに結びつけています。複合効果が重要です。毎日出荷して学ぶチームは、毎月出荷するチームより20–30倍頻繁に反復し、その学びの率は、プロダクトの寿命にわたって決定的です。
総所有コストでは、自動化はコストを、永続的な手作業の苦役から、一度きりに保守を加えたパイプラインの投資に移します。手作業のリリースは毎回上級エンジニアの時間を消費し、うまくスケールせず、弱い監査証拠を生みます。自動化されたパイプラインはそのコストを償却し、それから量が増えるにつれて減らし、そのすべてを、継続的により強い証拠を生みながら行います。可逆性は失敗自体のコストを下げます。どんな変更も数秒でロールバックできるとき、悪いデプロイの期待コストは崩れ、それが速く動くことを無謀ではなく合理的にするものです。
リーダーシップに論拠を示すには、四つのDORA指標とリリースあたりの手作業の時間で現在のベースラインを測り、それから取り除かれた苦役と避けられた停止時間を定量化してください。採用のコストは本物です。パイプラインのエンジニアリング、テストへの投資、プラットフォーム/舗装された道の能力(8.4章)ですが、投資しないコストは、遅いフィードバック、リリース日のリスク、エンジニアの燃え尽き、監査の苦痛として継続的に払われます。決め手となる論拠は、ディスカバリーとのつながりです。速く測定されるデリバリーパイプラインこそ、ディスカバリーパイプラインの検証された賭けを、本番で実際にテスト可能にするものです。
アンチパターンと落とし穴
- アウトカムではなくアウトプットを測る: 対象の指標が横ばいのまま、デプロイの数を祝うこと。
- 遅い、あるいは不安定なテストスイート: 開発者が無視する、あるいは迂回することを学ぶゲート。
- 一斉で頻度の低いリリース: 大きなバッチは、リスクが高く、デバッグしにくく、元に戻しにくい。
- デプロイとリリースの混同: フィーチャーフラグがないので、すべてのデプロイがユーザーに見える不可逆な賭けになること。
- 手作業のリリースの劇場: 遅く、一貫せず、監査もまずい手作業のチェックリスト。
- 自動化されたパイプラインでオブザーバビリティなし: 退行を検知も診断もできないまま速く出荷すること。
- フィーチャーフラグの負債: 決して取り除かれないフラグが、テスト不能な組み合わせの複雑さへと積み上がること。
- DORA指標のゲーム化: フローを改善するのではなく、頻度を水増しするためにデプロイを分割すること。
- フィードバックのループがない: 成果が測定されず、デリバリーが次のディスカバリーのサイクルに情報を与えないこと。
成熟度モデル
- レベル1、開始: 手作業で、頻度が低く、高儀式のリリース。テストはほとんどが手作業で手で実行され、成功は「出荷した」で測られ、ロールバックは痛みを伴いその場しのぎで、デリバリーがどう機能すべきかの共有の考えがありません。
- レベル2、発展: 一部のチームが自動ビルドと少数のテストを伴うCIを立ち上げます。リリースは予定され、基本的な監視が存在し、実践はチームごとに異なってDORA指標はまだ追跡されないので、デリバリーは局所的には良いが組織全体で一貫しません。
- レベル3、標準化: 文書化された、舗装された道のパイプラインが組織全体で徹底されます。自動のテストとセキュリティのゲート、ロールバックを伴う段階的なデプロイ、ポリシー・アズ・コードとして徹底される職務の分離を備えた継続的デリバリー。パイプラインは不変の監査証跡を提供し、すべてのチームがオーダーメイドではなく同じバージョン管理された道に従います。
- レベル4、管理: パイプラインが、ベースラインに対して測定され制御されます。四つのDORA指標(デプロイ頻度、リードタイム、変更失敗率、復旧時間)、SLOの達成、エラーバジェットのバーン、サイクルタイムや仕掛かりの仕事のようなフロー指標が目標に対して追跡され、ゲートとロールバックは判断ではなく測定された閾値で起動します。フラグの負債、不安定なテストの率、リードタイムの退行が監視され、各実行か中止かの決定は証拠に基づいて行われます。
- レベル5、オーケストレーション: デリバリーは継続的に改善され、ディスカバリーとリスクの計画と統合されています。継続的デプロイが適切な所で、プログレッシブデリバリーと自動ロールバックとともに動き、機能は、成果の指標が次のラウンドの賭けにループバックする測定された実験として出荷され、エリートのDORA性能は舗装された道を通じてチーム間で維持され、組織は負荷、リスク、プロダクトの構成が移るにつれて、ゲート、閾値、容量を適応的に再調整します。
議論のためのアイデア
- 現在の四つのDORA指標は何で、コミットから本番までのフローで最大のボトルネックはどこですか。
- 今日、デプロイとリリースを分けられますか。できないなら、フィーチャーフラグはリスクをどう変えますか。
- テストスイートにはどれだけかかり、開発者は迂回しないほどそれを信頼していますか。
- 最後に機能を出荷したとき、それが動かすはずだった指標を動かしたかを測りましたか。
- 規制対象の文脈では、変更管理のプロセスはデリバリーを遅くしますか。それともパイプラインを通じて自動的に徹底されていますか。
- コードベースのフィーチャーフラグのうち、何か月も前に取り除かれているべきものはどれですか。
要点
- デリバリーパイプラインは、検証されたアイデアを動く測定されたソフトウェアに変え、成果をディスカバリー(11.1章)にフィードバックします。
- 道全体を自動化します。速いテストゲート、CI/CD、インフラストラクチャ・アズ・コード、真実の源としてのパイプライン。
- デプロイとリリースを分け、自動ロールバックを伴う段階的な戦略(フラグ、カナリア、ブルーグリーン)を使います。
- 三つの水準で測定します。DORA/フロー指標、信頼性/SLO、事業/ユーザーの成果。
- 速度と安定性は補完的で、トレードオフではありません。一方を届ける実践が他方も届けます。
- パイプラインはコンプライアンスの統制でもあります。自動化が不変で継続的な監査証跡を生みます。
- ROIは速く、よく証拠づけられ、複合します。投資しないことの主なコストは継続的に払われます。
参考文献とさらなる読み物
- Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, Gene Kim (the DORA metrics and evidence).
- Continuous Delivery, by Jez Humble and David Farley (the foundational text).
- The DevOps Handbook, by Kim, Humble, Debois, Willis.
- The Phoenix Project, by Gene Kim, Kevin Behr, George Spafford (narrative on flow).
- Site Reliability Engineering, by Beyer, Jones, Petoff, Murphy, eds. (SLIs/SLOs, error budgets).
- Team Topologies, by Matthew Skelton and Manuel Pais (paved roads and delivery-team design).
- Feature Flags / progressive delivery, writings by Pete Hodgson and the LaunchDarkly/Split communities.
- Google DORA, Accelerate State of DevOps reports (annual).
- Kim, Gene, The Unicorn Project (developer-experience view of flow).
- Reinertsen, Donald, The Principles of Product Development Flow (batch size, queues, flow economics).