8.6 リリース管理とプログレッシブデリバリー

概要と動機

現代のリリース管理で最も有用な考えは、最も単純でもあります。コードを出荷することと機能を公開することは二つの別々の出来事で、片方を他方なしに行えるべきだ、ということです。8.1章(CI/CDとデリバリー)は、変更を一度構築し、テストし、不変の成果物として昇格させるところまでを扱います。この章は、その次に起こることについてです。デプロイされたコードを、本物のユーザーにとっての稼働中の体験へと、段階的に、安全に、素早い戻り道を備えて、どう変えるか。デプロイとは、サーバーにコードをインストールすることです。リリースとは、ユーザーがある能力に到達できるようにすることです。二つを分けると、デプロイは日常的で退屈なものになり、リリースは制御された、元に戻せる決定になります。

大きなチームにとって、この分離は出荷の感情的な温度を変えます。数十のサービスと数百人のエンジニアが毎日本番を変更するとき、「デプロイはリリース」という結合したモデルは、ユーザー向けのすべての変更が、危険で一度きりの出来事であることを意味します。切り離すことで、未完成の作業をスイッチの背後にマージし、機能をトラフィックの1パーセントに展開し、数字を見て、ビルドに触れずに広げたり退いたりできます。プログレッシブデリバリーはこのための包括的な用語です。自動化されたチェックが続行するかを決めながら、変更を広がる対象に向けてリリースすること。

企業と政府の設定は、調整と証明を加えます。決済プラットフォームは、スキーマで合意しなければならない多くのサービスにわたってリリースします。公的機関は、運用認可と正式な変更管理のもとで運用し、監査人は、正確に誰がいつ何にさらされたかの証拠を求めます。うまく行えば、プログレッシブデリバリーは、速く動きたいという願いと、統制を証明する義務の両方を満たします。影響範囲を限る同じ仕組みが、展開の監査可能な記録も生むからです。

主要原則

デプロイはリリースではない。 コードを暗く出荷し、それから意図して有効にします。
まず小さな影響範囲。 全員に公開する前に、少数に変更を公開します。
すべてのリリースにはバックギアがある。 数秒でロールバックできないなら、リリースの設計は終わっていません。
シグナルに昇格を駆動させる。 カレンダーや楽観ではなく、ヘルス指標とエラーバジェットが、展開が進むかを決めます。
フラグは取り除かれるまで負債である。 すべてのトグルは、保守し、いずれ削除しなければならないコードです。
データベースの変更を両方向で生き延びさせる。 展開とロールバックの両方が、同じスキーマに対して安全でなければなりません。
承認は妨げず記録する。 監査の証拠はパイプラインの副産物であり、毎週の会議ではありません。

推奨事項

フィーチャーフラグでデプロイをリリースから分ける

フィーチャートグル、つまりフィーチャーフラグは、再デプロイなしに、コードの経路が有効かを決める実行時のスイッチです。寿命が異なるので、フラグを型のある語彙として扱います。リリースフラグは進行中の作業を隠し、数日から数週間生きます。運用フラグ(キルスイッチ)は、負荷のもとでサブシステムを無効にでき、無期限に生きることがあります。実験フラグは、管理されたテストのためにトラフィックを分割し、実験の期間だけ生きます。権限フラグは、プランやロールで能力をゲートし、事実上恒久的です。すべてのフラグに、所有者、型、既定、予定された削除日を与えます。既定は安全なものにして、フラグサービスの停止が、テストされていない経路に開くのではなく、既知の良い挙動に閉じるようにします。

サービスの階層ごとにプログレッシブデリバリーのパターンを選ぶ

8.1章がデプロイの戦略について論じるように、展開の仕組みを影響範囲に合わせます。カナリアリリースは、トラフィックの小さな一部を新しいバージョンにルーティングし、ヘルスが保たれる場合にだけ広げます。ブルーグリーンデプロイは、二つの本番環境を保ち、即座の切り替えと即座の巻き戻しのために、それらの間でトラフィックを移します。ローリングデプロイは、バッチでインスタンスを置き換えます。リングベースのデプロイは、名前付きの対象を通じて広がります。まず社内のユーザー、次にベータのコホート、次に小さなリージョン、そして全員。リングは、大きな組織にとって最も有用な枠づけです。各段階で誰がさらされるかを名指しし、それはまさに、監査人とインシデント対応者の両方が知りたいことだからです。コンテナのプラットフォームとオーケストレーション(8.3章)は、これらのパターンを安く動かせるトラフィック整形の基本要素を提供します。

ヘルスチェックと自動ロールバックで展開をゲートする

ヘルスの客観的な基準は、インシデントの最中ではなく、リリースの前に定義します。自動化された分析が、エラー率、レイテンシ、飽和でカナリアをベースラインと比較し、人間が気づくのを待たずに昇格あるいは巻き戻しを行います。昇格を、サイトリライアビリティエンジニアリング(9.1章)のサービスレベル目標とエラーバジェットに結びつけます。バジェットが健全なときは自由にリリースし、使い切ったときは、サービスが安定するまでパイプラインが進むのを拒みます。自動ロールバックは、小さな退行を大きな停止に変えるためらいを取り除くので、最も重要です。素早い巻き戻しは、最も安いインシデント統制でもあります。数秒かかるロールバックは、インシデントのプロセス(9.3章)が完全に動き出す前に、影響範囲を縮めます。こうして改善される変更失敗率と回復時間は、デリバリーのパイプラインが追跡するのと同じフローと安定性のシグナルです(11.2章)。

ダークローンチとシャドートラフィックでリスクを下げる

あまりに重大で、最初から全面的な露出で本物のユーザーに会わせられない変更があります。ダークローンチは、機能をオフにして出荷し、誰かが見る前に社内で、あるいは本番の一部に対して試します。シャドートラフィックは、稼働中のリクエストを新しいコードの経路にコピーし、応答を捨てるので、ユーザーへの影響ゼロで、本物の負荷と正しさを測定します。これらの技法は、どのステージング環境も忠実には再現できない本物のトラフィックのもとで、書き直しや新しい依存関係を検証させてくれます。カナリアに使うのと同じヘルス分析と組み合わせます。

同じフラグのシステムを通じて管理された実験を行う

実験フラグは、リリースエンジニアリングがプロダクトの学びに出会う所です。A/Bテストの分割は、比較可能なコホートにバリアントを提供して選んだ成果を測定し、7.4章のプロダクト分析の実践に供給します。安全のための展開と実験の両方に一つのフラグとターゲティングのシステムを再利用し、誰がどのバケットにいるかで食い違う二つの並列のトグルスタックではなく、単一の監査証跡と単一のキルスイッチを持つようにします。

拡張と縮小でデータベースを後方互換に保つ

展開とロールバックは、スキーマが古いコードと新しいコードを同時に許容する場合にだけ安全に保たれ、それは段階的な展開の間は避けられません。拡張と縮小(並行変更)のパターンを使います。まず後方互換なマイグレーションで新しい列やテーブルを追加して拡張し、次に古い形と新しい形の両方に書き込むコードをデプロイし、次にバックフィルし、次に読み取りを移し、実行中のコードがもう依存しなくなってからずっと後に、古い形を取り除いて初めて縮小します。破壊的なマイグレーションを、それを必要とするデプロイと決して組み合わせないでください。この規律が、すでに先へ進んだデータベースなしに、コードをロールバックできるようにするもので、混在バージョンの窓をカバーしなければならない、テスト戦略(2.4章)に直接つながります。

変更管理を妨げず記録するものにする

変更の種類を事前承認することで、監査とフローを調和させます。パイプラインを自動的に流れる、標準で低リスクの変更の種類を定義し、誰が承認したか、どのテストが走ったか、どの成果物がデプロイされたか、各リングでどの対象がさらされたかを捉えます。人間の変更諮問のレビューは、本当に高リスクの変更のために取っておきます。すべての日常のデプロイを検査する従来の変更管理の委員会は、ボトルネックになり、チームをより大きく危険なバッチへと向かわせ、意図とは逆になります。政府では、展開のツールが統制の枠組みが求める証拠を出す場合、運用認可と正式な変更管理は、プログレッシブデリバリーと共存でき、リングベースの記録が監査の成果物になります。

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

パターン	長所	短所	最適な場合
カナリア	データ駆動。小さな影響範囲	良い指標とトラフィック量が必要	大規模なユーザー向けサービス
ブルーグリーン	即座の切り替えとロールバック	切り替えの間、環境のコストが倍	速い巻き戻しを要する重要なサービス
ローリング	安い、単純、追加の環境なし	遅いロールバック。混在バージョンが稼働	ステートレスな社内サービス
リングベース	名前付きの対象。明確な監査証跡	完全な展開が遅い。より多くの調整	規制対象と複数サービスの資産群
フィーチャーフラグ	デプロイをリリースから切り離す。即座のキルスイッチ	フラグの負債。テストの行列が育つ	未完成の作業を安全に出荷するチーム
リリーストレイン	予測可能な周期。容易な調整	多くの変更を結合する。列車を待つ	リリースを共有する多くのチーム
オンデマンドのリリース	小さなバッチ。速いフィードバック	チーム間の調整が難しい	信頼の高い継続的デリバリーのチーム

中心的な緊張は、調整と独立の間にあります。リリーストレインは、多くのチームの変更を固定のスケジュールにまとめ、推論しやすいですが、完成した変更を待たせ、無関係な仕事を一つの出来事に結合します。オンデマンドのリリースは、各チームが準備できたときに出荷できるようにし、より速いですが、サービスが独立にデプロイ可能で後方互換であり続けることを要求します。解決は通常、チームがオンデマンドでリリースできるよう、成果物とスキーマの水準で切り離し、それからフラグとリングを使って、サービスをまたぐ機能が実際に有効になるユーザーに見える瞬間を調整することです。そうすれば、技術的なリリースとプロダクトのローンチは別々の決定で、どちらも他方をブロックしません。

チームで議論すべき問い

午前2時にリリースがうまく行かなかったとき、元に戻すのに何秒かかり、誰が、あるいは何が引き金を引きますか。 誠実な答えは、デプロイとリリースを本当に分けたのか、結合したプロセスの上に単にフラグを加えただけなのかを明らかにします。再構築を要する、元に戻すデータベースのマイグレーションを要する、あるいは決定のために人間を呼び出すロールバックは、ロールバックではなく、二つ目のインシデントです。上位三つのサービスの実際の仕組みを持ち込んでください。露出を元に戻すフラグあるいはトラフィックの移動、それを自動的に引き起こすヘルスのシグナル、巻き戻しを安全にするスキーマの保証。大きな資産群では、これがあなたの実際の影響範囲を決めます。素早い自動の巻き戻しが、退行が停止になるのを防ぐからです。答えが秒ではなく会議で測られるなら、それが最初に直すべきことです。
フラグを退役させる方針は何で、今どれだけのフラグ負債を抱えていますか。 すべてのフィーチャーフラグは、推論してテストしなければならない状態の数を倍にするコードの分岐で、目的より長生きしたフラグは純粋な負債です。ルールを今決めてください。すべてのリリースフラグに所有者と期限を与え、古いフラグをダッシュボードに表面化させ、削除をいつかの片付けではなく計画された仕事にする。稼働中のフラグの数、その古さ、予定された削除日を過ぎたものの数を持ち込んでください。大きなコードベースでは、管理されないフラグは、誰も削除する勇気のない恒久的な条件分岐の複雑さになり、安全の仕組みがバグの源に変わります。その数に対するチームの許容度は、実のところ、運用の衛生をどれだけ真剣に扱うかの表明です。
変更承認のプロセスは、リリースをより安全にしていますか。それとも単に遅くしていますか。 多くの組織は、すべてのデプロイをレビューする変更諮問委員会を運営しており、不快な問いは、それが悪い変更を実際に止めたことがあるのか、単に遅延を加えただけなのかです。データを持ち込んでください。承認の遅延の中央値、委員会がレビューした変更と事前承認された変更の変更失敗率、レビューが小さな変更をより大きく危険なものにまとめる頻度。目標は、人間のレビューを本当に高リスクの変更のために取っておき、標準の変更が自動的な証拠の捕捉とともにパイプラインを流れるようにすることです。規制対象と政府の文脈では、展開のツールが統制の枠組みの必要とする監査記録を生むことを確かめ、統制がその前のゲートではなく出荷の副産物になるようにしてください。レビューが失敗を減らさずに遅延を加えるなら、それはコンプライアンスの衣装を着た劇場です。
機械に任せて動かしてよい客観的なヘルスのシグナルは何で、最上位のサービスはすべて、本当にゲートできるほど良い指標を持っていますか。 自動化されたカナリア分析とエラーバジェットのゲートは、エラー率、レイテンシ、飽和が、人間なしに昇格やロールバックを信頼できるほどきれいに測定されている場合にだけ機能し、多くのチームは、インシデントの最中に、自分たちのシグナルがうるさすぎるか、まばらすぎて決められないと気づきます。大きな資産群では、これが、手作業の見張りなしにリリースの量のどれだけを安全に流せるかを決めます。それは、スケールするプラットフォームと、すべての展開を見張る人を必要とするプラットフォームの違いです。最も重要な三つのサービスの実際のダッシュボードを持ち込んでください。ゲートに使う指標、カナリアが統計的に意味を持つトラフィック量、自動化された分析の誤検知率。規制対象と政府の設定では、同じシグナルが監査可能な記録に供給されるので、貧しいオブザーバビリティは信頼性の隙間であると同時にコンプライアンスの隙間でもあり、指標の品質への資金は、前提とされる能力ではなく、計画の名指しされた項目であるべきです。
スキーマの変更は実際にロールバックを生き延びますか。そしてリリース前に、混在バージョンの窓が安全だとどう証明しますか。 プログレッシブデリバリーは素早いバックギアを約束しますが、機能に結合された破壊的なマイグレーションは、その約束を静かに無効にします。コードをロールバックすると、すでに先へ進んだデータベースを指したままになるからです。多くのサービスがスキーマを共有する大きな組織では、リスクが複合します。あるチームの縮小のステップが、別のチームのロールバックを取り残しえるので、拡張と縮小の規律は、局所的な習慣ではなく共有の標準でなければなりません。マイグレーションの手引きと、それが守られている証拠を持ち込んでください。拡張と縮小をどう分けるか、二重書き込みとバックフィルが負荷のもとでテストされているか、テストスイートが古いコードを新しいスキーマに対して、新しいコードを古いスキーマに対してどう試すか。長寿命のデータと正式な変更管理を抱える企業と政府の資産群では、不可逆なマイグレーションは、停止のリスクだけでなく、予定されたメンテナンスの窓では救えない、データの完全性と監査の露出です。
異なる速度で出荷するチームにまたがるサービス横断の機能で、有効になる瞬間を誰が所有し、デプロイを結合せずにどう調整しますか。 デプロイをリリースから分ける要点は、各チームが成果物を独立に出荷でき、単一のフラグがユーザーに見えるローンチを制御することですが、それは誰かが、サービスの境界をまたいでローンチの決定とフラグのターゲティングを所有する場合にだけ成り立ちます。大きなチームでは、失敗のモードは、誰も選ばなかった事実上のリリーストレインです。一つの遅いサービスが他のすべてのチームを待たせるか、調整のないフラグの切り替えが配線の半端な機能を公開するか。次の複数サービスのローンチの依存関係の地図、ローンチフラグの所有者、各サービスが自分の時計でデプロイできるようにする後方互換の保証を持ち込んでください。正式なローンチ承認を伴う企業と政府のプログラムでは、サービス横断の有効化を誰が承認し、彼らがどんな証拠を見るかを名指しし、調整されたローンチが、最後にマージした人の偶然ではなく、意図され記録された決定になるようにしてください。

セクター別の視点

スタートアップ。 デプロイをリリースから分けることは、3人のエンジニアでも価値がありますが、安く保ってください。新しい作業を既定でオフのリリースフラグで包み、トランクに出荷し、顧客の前にまず自分のために機能を有効にして、未完成の変更がデプロイを決してブロックしないようにします。人員を置けない重いカナリア分析のプラットフォームは飛ばしてください。ホスト型のフラグサービスと固いキルスイッチが安全の大半を買い、毎週のフラグ片付けの習慣を一人が持つことで、負債があなたの速度を飲み込むのを防げます。

小規模事業者。 リリースエンジニアがおらず予算も厳しいので、展開のシステムを築くのではなく、既存のプラットフォームがすでに与えるプログレッシブデリバリーに頼ってください。マネージドなホスティング、フィーチャーフラグのSaaS、あるいはフレームワーク組み込みの段階的な展開が、通常、必要な小さな影響範囲をカバーします。バックギアを、正しく得なければならないものとして扱います。数秒でオフにできる変更は、調整する時間のない洗練された自動分析よりはるかに重要です。

大企業。 問題は、多くのチームとサービスにわたる一貫性です。所有者、型、期限を備えた共有のフラグの語彙、標準のリングベースの展開、どこでも同じように適用されるエラーバジェットのゲート。グループが対抗するトグルスタックを発明するのをやめるようにします。フラグ負債を資産群全体の指標として統治し、一つのチームのスキーマ変更が別のチームのロールバックを取り残さないよう、拡張と縮小のマイグレーションを標準化し、監査可能な展開の記録を、すべてのサービスが同じ形で出す副産物にします。標準の変更を事前承認し、人間のレビューを本当に高リスクのものに取っておくので、統制は、クリティカルパスに委員会なしでスケールします。

政府。 調達規則、透明性、公的な説明責任がすべてのリリースを形づくります。展開のツールを監査の証拠の源にし、各リングの拡張が、承認した権限、走ったテスト、成果物のハッシュ、さらされた正確な母集団を記録するようにして、運用認可がプログレッシブデリバリーと戦うのではなく共存するようにします。監査人とインシデント対応者の両方が読める名前付きの対象を持つ、ブルーグリーンあるいはリングベースのパターンを好み、市民が影響を受ける前に、重大な変更を稼働中のケースに対するシャドートラフィックで検証し、予定された一斉の窓の代わりに統制の枠組みが受け入れる成果物として、監査可能な記録を保ちます。

事例

スタートアップ。 10人のSaaS企業は、一日に何度もトランクに出荷し、すべての新しい能力を既定でオフのリリースフラグで包みます。危険な新しい請求の統合は暗く立ち上がります。1週間それに対してシャドートラフィックを走らせ、顧客への影響なしに本物のリクエストの形を扱うのを観察し、それから自社のアカウントと少数の好意的なベータ顧客から始めて、リングごとに展開します。5パーセントのリングでエラー率が急上昇すると、自動チェックが数秒でフラグをオフにし、彼らは月曜日に落ち着いてデバッグします。一人のエンジニアが毎週のフラグ片付けの習慣を持つので、トグルが決して積み上がりません。

大企業。 世界的な決済企業は、六つのサービスと共有のスキーマにまたがる変更を調整します。各チームは拡張と縮小を使って自分の成果物を独立に、後方互換にデプロイするので、新しい列は、ユーザーが機能を見るずっと前に存在し二重に書き込まれています。ユーザーに見えるローンチは単一の実験フラグで、エラーバジェットのヘルスに結びついたリングを通って展開されます。社内、次に小さな一つの国、次に広がる割合と進み、各段階で自動化されたカナリア分析が昇格あるいは巻き戻しを行います。フラグのガバナンスのサービスが資産群全体で所有者、型、期限を徹底し、事前承認された標準の変更は委員会なしに流れ、スキーマの縮小のステップだけが人間のレビューを受けます。すべてのリングの遷移が記録されるので、監査証跡はひとりでに書かれます。

政府。 国の給付機関は、運用認可と正式な変更管理のもとで運用します。プログレッシブデリバリーをコンプライアンスのリスクとして扱うのではなく、展開のツールを監査の証拠の源にします。各リングの拡張が、承認した権限、走ったテスト、成果物のハッシュ、さらされた正確な母集団を記録します。新しい受給資格の計算は暗く立ち上がり、稼働中のケースに対するシャドートラフィックで検証され、それから即座の巻き戻しのためのブルーグリーンの切り替えを伴うフラグの背後で、リージョンごとに展開されます。標準の変更は事前に分類されるので、日常の仕事は委員会の後ろに並びませんが、高リスクの方針変更は依然として正式なレビューを受けます。監査可能な展開の記録は、かつての四半期ごとの一斉リリースが決して満たしたよりも完全に、統制の枠組みを満たします。

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

プログレッシブデリバリーの見返りは、避けられたインシデントと縮んだその深刻さに支配されます。ユーザーの1パーセントに届いて自動的に元に戻る変更は、誤差の範囲のコストですが、同じ欠陥が全面的な露出で起きれば、数時間の停止、緊急対応、評判の毀損を意味しえます。デプロイをリリースから切り離すことは、リリース自体を、予定された高ストレスの出来事から日常的なものに変え、チームの規模とともに非線形に増える調整の税を下げます。ローンチの決定をデプロイから分けることで、プロダクトとエンジニアリングが自分の時計で動け、マーケティングの日付が危険なコードフリーズを決して強いません。

総所有コストは、その上振れに比べて本物ですが控えめです。フラグのプラットフォーム、カナリア分析のツール、ゲートできるほど良いヘルス指標、後方互換のスキーマ変更の規律に投資します。繰り返されるコストは、フラグの衛生と、フラグが作るより大きなテストの行列で、管理されないフラグの資産群が、この実践が高くつく主な道なのはそのためです。採用しないコストは、影響範囲で払われます。すべてのリリースがオール・オア・ナッシングで、ロールバックは遅く、一つの悪いデプロイが全員を一度に落としえます。規制対象の組織にとって、コンプライアンスの配当は決定的です。露出を限る同じ仕組みが、そうでなければ手で組み立てられる監査可能な証拠も生むからです。

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

デプロイがリリース。 二つを結合すると、ユーザー向けのすべての変更が、バックギアのない危険で一度きりの出来事になること。
フラグの負債。 目的より長生きしたトグルは、誰も削除する勇気のない恒久的な条件分岐の複雑さになること。
開いて失敗するフラグ。 新しくテストされていない経路を既定とするフラグサービスの停止は、小さな揺らぎを停止に変えること。
スキーマの取り消しを要するロールバック。 機能とともに出荷された破壊的なマイグレーションは、コードを安全に元に戻せなくすること。
雰囲気による手作業の昇格。 定義されたヘルスの基準とエラーバジェットではなく、「問題なさそう」だからと展開を進めること。
ロールバックの計画のない展開。 機能をオンにする方法を設計して、オフにする方法を設計しないこと。
変更委員会のゴム印。 何も却下しないレビューは、安全を加えずに遅延を加え、チームを大きなバッチへと向かわせること。
別々のシステムにある実験と安全のフラグ。 誰がどのバケットにいるかで食い違う二つのトグルスタックは、監査の面を倍にすること。

成熟度モデル

レベル1: 開始。 デプロイとリリースが同じ出来事です。変更は一度にすべて出て行き、ロールバックは古いビルドを手で再デプロイすることを意味し、スキーマのマイグレーションは破壊的で機能に結合されています。段階的な露出があるとしても、その場しのぎで、反応的で、文書化されていません。
レベル2: 発展。 フィーチャーフラグは一部のチームにあり、未完成の作業を隠しますが、所有者、型、期限を欠き、負債が積み上がっています。カナリアあるいはブルーグリーンは少数の重要なサービスに使われ、チームごとに一貫せず適用されます。ロールバックはスクリプト化されていますが人間が起動し、スキーマの変更は時々しか後方互換ではありません。
レベル3: 標準化。 デプロイとリリースは、組織全体で既定で分けられています。フラグは型があり、所有され、期限があり、安全な既定を持ち、文書化され徹底された標準に従います。リングベースの展開と自動化されたカナリア分析を伴うプログレッシブデリバリーが規範で、拡張と縮小のマイグレーションが必須で、標準の変更は自動的な証拠の捕捉とともにパイプラインを流れます。
レベル4: 管理。 リリースのプロセスが、データで測定され制御されます。変更失敗率、平均復旧時間、ロールバックの遅延、フラグの古さと数、カナリアの誤検知率が、ベースラインとエラーバジェットに対して追跡され、展開はそれらのSLO(9.1章)でゲートされるので、昇格とロールバックは定義されたヘルスのシグナルで自動的に動きます。フラグ負債は資産群全体の指標として報告され、予定に沿って退役され、展開の標準からの逸脱は、ポストモーテムではなくダッシュボードに現れます。
レベル5: オーケストレーション。 プログレッシブデリバリーは継続的に改善され、組織全体に統合されています。ダークローンチとシャドートラフィックが主要な変更のリスクを日常的に下げ、実験と安全の展開が一つのフラグのシステムと監査証跡を共有し、リリースの方針はエラーバジェットの状況にリアルタイムで適応します。監査可能な展開の記録は副産物として変更管理(9.3章)を満たし、組織は、資産群とリスクの状況が移るにつれて、リング、ゲート、閾値を証拠から調整します。

議論のためのアイデア

最も重要なサービスで、自動のヘルスゲートによるロールバックと人間の決定の境界はどこにあるべきで、機械が単独で行動するのを許すほど信頼できるシグナルは何ですか。
実験フラグとリリースフラグは、一つのプラットフォームと一つのキルスイッチを共有すべきですか。それとも、組み合わせることは取り除くより多くのリスクを生みますか。
機能が異なる速度で出荷する複数のチームにまたがるとき、リリーストレインとオンデマンドのリリースをどう決めますか。
あなたのコードベースで、リリースフラグの誠実な半減期は何で、削除を作成と同じくらい日常的にするには何が必要ですか。
エラーバジェットの状況は、誰がリリースを許されるかをどう変えるべきで、バジェットを使い切ったときにリリースを凍結する決定は誰が所有しますか。
あなたの規制対象の文脈では、統制の枠組みが、予定されたリリースの窓の代わりにプログレッシブデリバリーを受け入れるために、展開はどんな具体的な証拠を出さなければなりませんか。

要点

デプロイをリリースから分ける。 コードを出荷することと機能を公開することは別の決定で、フラグがそれらを切り離します。
段階的に展開する。 カナリア、ブルーグリーン、ローリング、リングベースのパターンが影響範囲を限ります。リスクでサービスの階層ごとに選びます。
ヘルスとエラーバジェットでゲートする。 カレンダーや楽観ではなく、定義されたシグナルとSLO(9.1章)に、自動の昇格とロールバックを駆動させます。
まずバックギアを設計する。 素早く安全なロールバックは、インシデントのプロセス(9.3章)が完全に働く前に影響範囲を縮めます。
すべてのフラグに型、所有者、期限を与える。 リリース、運用、実験、権限のフラグは寿命が異なり、管理されないフラグは負債になります。
スキーマの変更を後方互換にする。 展開とロールバックの両方が混在バージョンの窓(2.4章)で安全に保たれるよう、拡張と縮小を使います。
承認は妨げず記録させる。 標準の変更を事前承認して人間のレビューを高リスクのために取っておき、展開の記録が監査の証拠になるようにします。

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

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.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Pete Hodgson, “Feature Toggles (Feature Flags)” (essay on martinfowler.com).
Danilo Sato, “Canary Release” and Martin Fowler, “BlueGreenDeployment” (essays on martinfowler.com).
Sam Newman, Building Microservices: Designing Fine-Grained Systems (expand-and-contract and independent deployability).
Pramod Sadalage and Scott Ambler, Refactoring Databases: Evolutionary Database Design (parallel-change schema migrations).
Ron Kohavi, Diane Tang, and Ya Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing.
James Governor, “Progressive Delivery” (RedMonk, the coining of the term).