リリースとデプロイ
Google SRE Book 第8章(リリースエンジニアリング)と DORA のメトリクスガイドを取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
リリースエンジニアリングという役割
開発と運用の橋渡し。 ソースコントロール、コンパイラ、ビルドツール、 システム管理の知識をまたいで持つ。
やることは、バイナリと設定が再現可能かつ自動的に作られる状態を作ること。
そして最も重要な助言が最後に来る。 リリースエンジニアリングはプロジェクトの最初から組み込む。後付けにしない。 開発者・SRE・リリース担当が、製品ライフサイクルの早い段階から一緒に動く。
4つの原則
セルフサービス
標準化されたツールと手順を用意して、各チームが自分でリリース時期を決められるようにする。 専門家が毎回関与しないと出せない状態にしない。
高頻度
頻繁に出す。 1時間ごとにビルドして、テスト結果を見て出すバージョンを選ぶチームもある。 長い開発サイクルを回さない。
これはトランクベース開発と同じ方向の話。
密閉ビルド(hermetic build)
同じリビジョンのコードを再ビルドしたら、どのマシンでも同じ結果になる。 ビルドを外部の依存や環境変数から隔離することで実現する。
なぜ重要か。再現性がないと本番の問題をデバッグできないし、 古いリリースブランチへ特定の修正だけをチェリーピックしたときに 関係ない変更が紛れ込んでいないと言い切れない。
ビルドの「冪等性」「外部依存関係の決定性」と同じことを言っている。
ポリシーの強制
コードレビュー、リリース承認、デプロイ、設定変更のそれぞれにアクセス制御をかける。 できてしまう状態を残さない。
設定管理
どれにも欠点があるので、選ぶときにトレードオフを意識する。
| 方式 | 利点 | 欠点 |
|---|---|---|
| メインラインで管理 | 単純 | バイナリと設定のバージョンがずれる |
| バイナリに同梱 | デプロイが単純 | 結合が強くなり、設定だけ変えられない |
| 別パッケージにする | 設定を独立して更新できる | 組み合わせの管理が要る |
| 外部ストアに置く | 動的に変えられる | 実行時の依存が増える |
何を測るか(DORA)
DORA は現在5つの指標を挙げている。前半3つがスループット、後半2つが安定性。
| 指標 | 定義 |
|---|---|
| 変更のリードタイム | コードをコミットしてから本番にデプロイされるまでの時間 |
| デプロイ頻度 | 一定期間のデプロイ回数、またはデプロイ間の時間 |
| 失敗したデプロイからの復旧時間 | 介入が必要になったデプロイから復旧するまでの時間 |
| 変更失敗率 | 即座の介入(ロールバックやホットフィックス)を要したデプロイの割合 |
| デプロイ手戻り率 | 本番のインシデントに起因する、計画外デプロイの割合 |
速度と安定性はトレードオフではない。 上位の組織は5つすべてで良い成績を出す。
使い方を間違えない
やってはいけないこと。
指標を目標として設定する(ゲーミングを招く。グッドハートの法則)
異なるアプリケーションやチームの間で比較する
組織間の競争に使う
特定のチームだけに閉じて測る
改善そのものより測定を優先する
やること。
アプリケーション・サービス単位で、文脈を踏まえて使う
自分たちの時間経過による変化を追う
開発・運用・リリースをまたいだ共同のオーナーシップを持つ
統合基盤を作り込む前に、まず会話か簡易診断から始める
進め方は、ベースラインを取る → 摩擦がどこにあるか話す → 最大の制約を1つ選んで改善する → 先行指標を含む計画を作る → 再評価する、の反復。
これはエンジニアリング生産性の計測の 「何の行動も取られないなら計測する意味がない」と同じ立場。
リリース判断にエラーバジェットを使う
SLO とエラーバジェットは、 リリースするかどうかの入力になる。
バジェットが残っていれば出す。使い切っていれば、信頼性の回復を優先する。 「安全に倒すか、速く出すか」を、その都度の力関係ではなく数字で決めるための仕組み。