第9回のオンライン輪読会に備えて読んだ内容を自分なりにまとめておく。
今回の記事はこちら。
[期待/予想する内容]
この記事の目次は次のとおりである。
- はじめに：継続的な改善とソフトウェアの自動化
- パイプライン: 継続的デプロイツール
- 欠陥によりお客様に影響するリスクの削減
- 実行速度へのアプローチ手法
- まとめ
以前よりは目次が具体的になった。継続的デリバリー（以下、CD）以外の用語もあるし、だいぶ内容を想像しやすい。
「はじめに：継続的な改善とソフトウェアの自動化」……顧客に価値を安定的に、素早く提供するために、CDが必要ですよ、とかそういう前振りがあるものと思われる。で、高速化が必要ですよ、という問題提起もあるかな？
「パイプライン: 継続的デプロイツール」……ツールの紹介、例えばJenkinsとか、AWSのCodePipelineとかCodeDeployとか。他に何かあるだろうか……あまり知らないことに気づいた。
「欠陥によりお客様に影響するリスクの削減」……欠陥、すなわちバグ。バグの内容にもよるが、基本的には顧客になんらかの悪影響を与えるものである。ので、継続的インテグレーション（以下、CI）をCDと組み合わせて実行し、バグによる顧客への悪影響を最小化しようとする努力が必要、とかそういうことだろうか。
しかし、CDやCIを組むのって時間がかかる割には、顧客に提供する目に見える画面の変更とか、新しい機能とかと比べるとどうしてもイメージがしづらいので、「偉い人」への説明にこういう言い方（顧客への悪影響のリスクを削減する）をして、工数や人員を獲得するのはアリかも。覚えておこう。
「実行速度へのアプローチ手法」……タイトルにある「高速化」の本題がようやく登場した、と考えるべきだろうか。それとも、「継続的デリバリーによる」高速化、だから、スピードが上がるのはCDそのものではなくて、例えば顧客への価値提供とか、そういう文脈だろうか。しかし、実行速度というからにはやはりCDそのものの高速化と思われる。
並列化とか、デプロイ単位の分割とか、これまでのABL輪読会で読んできた記事にも出てきたようなアプローチ手法が改めて紹介される、という内容な気がする。まだ見ぬ高速化アプローチに出会えるだろうか。
[記事の要約]
次に、実際に記事を読んだ内容を箇条書きでまとめる。
はじめに：継続的な改善とソフトウェアの自動化
- 2010年以前のAmazon：新サービス実稼働まで9割がビルド、デプロイ、テストの時間
- リーダーシッププリンシプルに基づき最高水準を追求：新サービス稼働までの時間を改善することに
- 独自のホスト型ビルドシステムBrazilとデプロイシステムApollo：開発者が手動実行
- 業界のCD潮流にのり、このプロセスを自動化するパイプライン構築
パイプライン: 継続的デプロイツール
- パイプラインの試作版：最大で新サービス実稼働までの時間を9割削減
- パイプライン：アーティファクトをビルドし、全顧客にリリースする
- リリースプロセスの標準化、簡素化
- パイプライン以前＝バグ修正やメジャーリリースのやり方がチームごと
- パイプラインによる自動配信の成功、他のチームへの波及
- チームが一切テストを行わずリリースプロセスを自動化
- テストに対するソフトウェアチームの姿勢
- 短期的な結果よりも長期的な価値を重視するカルチャー
- 実行速度の向上と本番環境で発生する問題の間のバランス：適切なテストが必要
- テストしすぎると他社に遅れをとる
- チーム間の学びの不足
- デプロイの問題はメーリングリストなどで共有されていた
- 問題1：すべての人がそこから学んでいない
- 問題2：チームに必要な手法が採用されたかどうか不明
- ベストプラクティスをツールに組み込むことで問題解決、ベストプラクティス自体も品質向上
欠陥によりお客様に影響するリスクの削減
- リリースプロセス（パイプライン）の要件
- できるだけ早く欠陥を特定する
- 欠陥が顧客に影響を与えない
- デプロイ後のワークフローによる保証
- 実稼働前のテスト
- テストをパイプラインに組み込む：単体、結合、負荷、セキュリティ
- 製品化前テスト：製品版と全く同じ環境でテスト
- 本番環境でのチェック
- 本番環境では、いきなり全ユーザーにリリースはしない
- 少数のユーザーに公開しフィードバックを集める
- 数分から数時間待って問題なければデプロイ範囲拡大
- 毎分、人工的トラフィックで全依存関係までテスト
- リリース時期の制御
- メトリクス、タイムウィンドウ、安全チェックを利用して時期を制御
- メトリクスによるアラームでデプロイを停止するようパイプラインを設定
- アラームが発生せざるをえないデプロイではアラーム上書きが可能
- エンジニアが多い日中にデプロイするチームもいれば、利用率の低い夜間にデプロイするチームも。
- 既知の問題を含むパッケージのデプロイを停止する機能もある
実行速度へのアプローチ手法
- 自動化の恩恵
- エンジニアの間違いを減らし、顧客価値の増加に集中できる
- 品質にポジティブな影響：変更点は一度に一つなのでデグレ発見が楽
- 複雑なシステムでもメンバーの入れ替わりに耐えられる
- 継続的改善を何年も積み上げた
- 組織内の様々なレベルでリーダーたちが実行
- 例外はある：恒久的あるいは一時的に改善プログラムの対象外となるチームも
- 責任をとるのは担当チーム
- 問題を探し、繰り返し繰り返し改善しつづける
- 自動化がビジネスを継続的に成長させる唯一の道
[予想のふりかえりなど]
アプローチの章、残念ながら具体的な実践はあまり書かれておらず、長い時間をかけて培ってきた物が大事という、割と当たり前のことだけだった。無念。
リスクを減らすための重層的なテストの取組みは参考になる。一番簡単な部分しかやれていないので、パイプラインの中にテストを複数組み込んでいき、顧客への悪影響を最小限に抑える努力をしていきたい。
意外だったのは、リリースの時間帯、タイムウィンドウの部分。顧客への影響が少ない時間帯にやるのが良いとこれまでの経験から思っていたので、トラブルに対応できるエンジニアが多い時間帯のデプロイを好むチームもあると読んでびっくり。驚きはしたけど、確かに深夜にデプロイして問題が起きたら、それはそれで対応も辛いから、一長一短という感じなので、納得できる。
[まとめ]
- 「The Amazon Builder's Library」の『継続的デリバリーによる高速化』を読んだ
- 仕組みを作るだけではだめ、改善サイクルを長く続けることが大事
- 顧客への悪影響リスクを最小限にするためにパイプラインに重層的テストを取り入れたい
- デプロイの時間帯は難しい問題
これで9/13記事を読んだことになる。あと4つ！
引き続きAmazon Builder's Library読んでいくぞ。
