24章 継続的デリバリー
組織の速度は、デプロイまでの時間により律速される。
自分的にここはリリースの時間っておもっていたけど、それはようはデプロイの時間ってことでいいじゃんていわれるとたしかにな。
ここでエリックリースのリーンスタートアップが参照されるとはな。
エリックリース(1978年生まれ)45歳なの若っ!!リンスタ書いたの30代前半か。。。
24.1 Googleでの継続的デリバリーのイディオム
イディオム
ピンとこなかったけど、「慣用表現」「決まり文句」のニュアンスのようだ
継続的デリバリーならびにアジャイル方法論の中心的信条は、長期的には変更のバッチが小さい方が高い品質につながるというものだ。換言すると、より速い方がより安全、となる。
めっちゃわかりやすい!なんかこういうのを言い切れるようになりたいなー。
24.2 速度はチームスポーツである:デプロイを管理可能な部分へ分割する方法
Youtubeの話がめっちゃおもしろい。。。Pythonでつくられているというのは聞いたことがあったが、プロセスもなんともヘビーだな。
リリースが大変になると計画主義にもどっていくっていうのがなんともあるあるというか、辛い話だ。
みんなリリースやりたくない→リリースでトラブりたくない→事前に計画する→計画主義
最も大きな収益が期待できる投資とは、マイクロサービスアーキテクチャーへの移行だ。この移行により、大規模製品チームには積極的(scrappy)かつ革新的な状態を維持できる能力が与えられると同時に、リスクを低減できる
一旦最後まで読んでから戻ると、答え合わせのような箇所
モジュール化、下位チームの分割はマイクロサービスごとに行われていると考えられる
feature flagでの管理は、マイクロサービスごとに行われるのでフラグを大量に管理するコストは小さい
おそらくリリースマネージャーがいて、その人がアプリ全体のフラグ管理やA/Bテスト対象の管理をしている
24.3 変更を分離して評価する:フラグによる機能の保護
全変更を必ず「フラグで保護」
ロールアウト後にフラグを消すプロセスが必要になりそう
そうでないと収集がつかなくなる
1つのコードベースで環境変数を変えることで機能の出し分けをしているアプリを前職でメンテしていたが、誰も環境変数の全容を把握できていなかったために地獄のようになっていた
変数によっては互いに依存関係があったりもした
「システム運用アンチパターン」<E2Eテストの数を制限せよ
feature flag の数を決める
マジカルナンバー5を採用したい
24.4 アジャイル性を目指す:リリーストレインの構成
リリーストレイン
良い例え
定時運行、乗り遅れると取り返しがつかない、天災で遅延する、道を間違えることはない
SAFeの表現かなって思っていたけど「リリーストレイン」って元からあるんだろうか
おなじことおもいました
Bardに聞いてみた ら、The Art of Project Management(2001) が初出で、SAFe(2011)で有名になったと言ってます。が、初出が本当にそうだと確認できる資料は見つからなかった 24.5 品質とユーザー重視:使われるものだけをリリースせよ
毎週、毎日、または毎時間デプロイを行う能力を持つというゴールは、そのような頻繁なデプロイを実行せずに達成しても差し支えない
これは救われる一言
リリース自体はJenkinsおじさんポチーでよくても、リリースノートを書いたり対象チケットを取りまとめたりとそれなりに手間がかかるので、週2のペースにしています
平均デプロイ間隔はFour keys の測定対象でフロー効率は確かに高まるのだけど、リソース効率がさすがに悪すぎる(要はめんどくさい)
PRがマージされるたびにリリースされる仕組みを運用している会社は、監査をどうかわしているのだろう?
1PR 1リリースなら、PRがそのままリリースノートになる
マージする行動が監査上の「上司の承認」になる
あとはデータを取って取りまとめて提出できればOK
動的デプロイのおかげで、ユーザーに価値をもたらすデバイスのみに向けてコードをリリースしつつ、アプリのサイズを小さく維持できる。またA/B実験により、機能のコストと、その機能がユーザーとビジネスへもたらす対価との間の、計画的なトレードオフを行えるようになる。
ネイティブアプリだと余計にこのコストは重要だな。っていうのと、「最短でリリースできる時間」と「定期的なリリースの頻度」は直交しているっていうのは忘れられがちなのかもしれない?
feature flagふくめた機能の分割ってほんとうに大事だな。。。分散システムの設計力の重要性が巨大なサーバーシステムじゃなくて、ちょっとしたWebアプリとかモバイルアプリでもおきている。コード行数が少なくてもバイナリとして大きくなることはたしかにある(翻訳なんかはまさにそのとおり)ので、小規模だから設計がチープでいいってことはあまりないんだなっていうのを改めて思った。
ゆえにこういうのを簡単にしてくれるようなフレームワークとかライブラリとか設計原則が大事なんだろうなー。
24.6 左への移動:データ駆動の決定を早期に行う
問題ではなく事実
このマインドセット大事だなー
変えようがないものを受け入れ、それを前提に仕事を組み立てる。なんなら逆手に取る
プラセボ効果も考えてリリースの比較をできるっていうのが、大規模なユーザーを獲得していることの難しさを逆手につかった戦略でとてもいいなっておもった。大規模なユーザーだから難しいってところを解決するんじゃなくて大規模なユーザーがいるからこそできることをやるっていう。
新機能は全てフラグで保護されているので、ロールアウト中にテストされる変更は唯一、デプロイ自体の安定性だけだ
これ、feature flag の変更は別途デプロイするのだろうか
24.7 チームの文化を変える:デプロイに規律を組み込む
新機能開発のモチベーションは大事なのでリリースできるようにすることが非常に大事。だからこそ、製品を開発者から守ること(関心の分離、厳格なテストなど)で開発者から守り、結果として常にリリースしやすい状態を保てるっていうのはほんとうにいいな。
24.8 結論
より速い方がより安全
より速い方がコストがより安い
言い切れる強さ
リリースを断念するコストがどのリリースでも非常に低くなる
予定通りに出せないと調整がつらくて、無理して出そうとして…みたいなことがあるので、次のタイミングで出せればOKみたいなのは目指していかないと。
そのようなリリースを可能とするために必要なのは、十分にドキュメント化された堅牢な継続的デプロイのプロセス、ユーザーの満足と製品の健全性についての正確かつリアルタイムなメトリクス、何がリリースに入り何が入らないかとその理由についての明確なポリシーを備えたチームの協調
ドキュメントからチームからツールまでっていうのがいいなー
チームの協調っていう部分がいいなと思った
24.9 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
現場でどこまでできているか?
リリース可能なインクリメントをスクラムチームの中では意識しているが、QAチームのテストが必要だったり、リリース判定という従来のルールだったりで結局まとめて何ヶ月かに一回になってしまうことが多い
それでも以前よりは改善できていると思うが
flagによる制御とかは検討できていないので、「従来のルールのせいでー」と他責にするだけではなくて、リリースするための工夫もセットだと状況が前に進むかも
リプレースするシステムでCI/CDをどこまで取り入れられるか検討/検証中(本章を読んでfeature flagもやっぱりいるよなぁと思った次第…)
既存システムについては一部チームで配信をツール化できているところはあるがリリース速度を早めようというよりは必要に迫られてなイメージ。(配信先の数が多いので)
これから取り組むところなんですが、いまの自分のスキルが追いついてなさそうな気がしてきた。
特にfeature flagを前提としたデプロイやデータベース周りも含めたロールバックとロールフォワード。
feature flagとして環境ごとの設定を管理できるライブラリを使っている
「本番環境にだけは表れない」開発中機能がある
この本があるのになぜ実践する企業はすくないのか?
開発者がプロダクトデベロッパーになることの難しさ
考える人と作る人の分断をなくしたいと思っても、開発者が望んで作る人でありたいと思っている場合もある
この例だとマイクロサービスに対応した下位チームの開発者は作る人であって良い。また、作る方面に特化した人の知見がチームを救うこともある
目の前に考える人が参考にしているメトリクスがあると作る人も一緒になって考えてくれることも多い(分断の解消につながる。)
属人性を持った箇所を減らして自動化していくことで、開発の仕事を小さく抑えることで促される側面もあるのでは
既存資産の追加/修正開発が主だと、現行のコードベースの状態が悪くて手を出そうにも出せないという状況はあるのでは。
製品の設計を考える人がビジネスアジリティのためのデプロイパイプラインという観点で設計することに対して意外と議論が足りていないっていうのはありそう。
デプロイと、プロダクトマネジメントやマーケティングの文脈が直結している。少なくとも両者の橋渡しになる人が必要で、関係者全員が開発の事情をある程度は理解していないと難しい
それの乗り越え方はなにか?
DevOpsって目指すところはビジネスアジリティの向上のためのプラクティスがあるんだけど。。。なんか各プラクティスを共通の側面で評価したり、共通の側面に対応するさらに小さなプラクティスや工夫とはなにかっていうのが整理されるといいのかもしれない?
開発は十分なモジュール化をした上でそれに合わせてチームを分割し、初出しの機能にはfeature flagを設ける。テックリードやEMはリリーストレインが構成されるようにすべてのチームをまとめる。プロダクトマネージャーがリリースの司令塔を行い、どの機能をどうやってA/Bテストしていつ出すかを管理する
ステップを小さくするとしたらどうできそうか?
いちばん簡単なのはリリースの定期化かな
CIが十分機能していることとリリースの人的コストが十分小さいことで達成可能
これは開発チーム単独で達成できる。次点がfeature flag