Continuous Deployment at Instagramを読んだ
を読んだので、そのまとめと考察を書き残す。
内容まとめ
なぜやるか
- エンジニアが本当に速く行動できるようになる
- 自分の好きな時にコードをデプロイでき、変更に関するイテレートでの時間の浪費が減る
- 悪いコミットの特定がかなり簡単になる
- 多くても2、3個のコミットだけ調べれば良い
- 悪いコミットが検出されて対応されるのが速くなる
- 結果として、無関係の変更を遅らせたることがなくなり、重要な修正を速くリリースできる
実装方法
- 反復的な方法で構築したのがよかった
- このシステムを脇で作って、急に切り替えたのではない
- 現状のシステムを、継続的デプロイメントになるまで、進化させ続けた
以前のやり方
- エンジニアが変更をmasterにマージし、即デプロイが必要ならロールアウトを行うし、そうでなければ他のエンジニアがロールアウトするのを待っていた
- Fabricスクリプトで実装されていた
- 事前の1台での小規模なテスト
- ログの確認
- 全台へのロールアウト
Canaryとテスト
- ターゲットの1台ではなくcanaryマシンにデプロイをする
- テストスイートはあったが、開発者のマシンで行われていた
- Jenkinsでmasterの新しいコミットをテストするようにした
- コードレビューにはPhabricator http://phabricator.org/ を使っている
- SandcastleというCIシステム
- 更新がある度にとテストを走らせ、結果を通知する
自動化
- ロールアウトに状態(running、done、error)を追加した
- 前のロールアウトがdoneでなければ、スクリプトが警告を出す
- UIにabortボタンを追加した
- masterのコミットのテストのログを全て記録するようにした
- 最初は、自分たちがデスクで見ている時だけこの機能が有効であるように
- もはや監視する必要がなくなるまでは、
問題
テストの失敗
- あるコミットでテストが壊れると後続のコミットは全てデプロイできなくなる
- 溜まったコミットを全てテストしてデプロイし直すことになるので、ロールアウトごとのコミットが増えてしまう
- テストが遅いことと信頼性がないことが問題
- テストが5分以内に動くように最適化した
- テストが信頼できない原因になっていたインフラの問題を解決した
バックログ
- デプロイが必要なコミットが常に溜まっていた
- 全てのコミットが30分以内にデプロイされるというゴールを決めた
- キューに溜まったコミットの残り時間を計算して複数のコミットの自動デプロイをする
原則
- テスト
- 速くする
- 完全でなくて良いがかなりのカバレッジにする
- 頻繁にテストする:
- コードレビュー中
- masterへのマージ前(失敗時はマージされないようにする)
- masterへのマージ後
- Canary
- 全台にひどいコミットがデプロイされないようにカナリアテストを自動化する
- 正常ケースの自動化
- 正常な状況だけ自動化する
- 異常は何であれ、自動処理が停止して人間が介入するようにする
- 人々を快適にすること
- 人々がコントロールを失ったような気になる時が自動化の最大の障壁である
- 完了したこと、処理中のこと、処理直前のことを可視化する
- 悪いデプロイも予期すること
- 悪い修正は起こりうるが、問題ではない
- 直ぐに検知して素早くロールバックすること。
今後やること
- 速さを保つ
- ロールアウトあたりのコミットをほんの少しずつにしておくためにロールアウトを速く保つ
- カナリアテストを追加する
- masterにマージされてしまう悪いコミットを減らしたいのでLandcastleにカナリアテストを組み込んでいる
- Landcastleは、本番トラフィックで変更をテストして、カナリアテストの閾値を超えなかったらmasterへのマージをしない
- 検知を改善する
- カナリアテストで検知できなかった悪いコミットの影響を減らしたい
- 1台テストからすぐ全台ではなく、その間にもっと段階を追加することが考えられる
考察
- こういったことが実現できるためには、コードが綺麗にかけていることやコミットが綺麗に(アトミックに)作られていること、テストをきちんと書くことなど基礎的な技術力を全員が身に付けることがまずは大事だと思う。
- 定常的に開発の締め切りに追われてしまうと、プロセスの改善が難しい。それを両立できるエンジニアまたはマネージメントをいかに確保できるかという問題のようにも思える。
- エンジニア主導でサービスが回っている会社と営業・企画職主導でサービスが回っている会社では、リリースに関する考え方がかなり違う気がする
- 去年のVelocity Conferenceでこの話をしていたけど、今年はどんな内容が発表されるか?
- この記事の後の展開は公開されているか?
- 見つからない cf Infra – Instagram Engineering
- Phabricatorを採用した理由はなぜか?他を不採用にした理由は?
- そもそもFacebookが社内用に開発したソース管理システム
- Differentialという機能が特徴 cf Phabricatorを使ったワークフローについて
開発者が自発的に適切な粒度でレビュー依頼する助けにはなりそう
- カナリアテストとは具体的にどうやってやるの?
- 「カナリアテストは、いきなり全部の地域でデプロイするのではなく、1つの地域だけでデプロイしてみて、そのあとグローバルにデプロイするやり方。」 cf
- 有料サービスなどで全ユーザーに公平に同じ機能を提供する義務がある場合は、カナリアテストができるのだろうか?
- 信頼性を下げていたテストインフラの問題は何だろうか?
- 作者: ポール・M・デュバル,スティーブ・M・マティアス,アンドリュー・グローバー,大塚庸史,丸山大輔,岡本裕二,亀村圭助
- 出版社/メーカー: 日経BP社
- 発売日: 2009/08/06
- メディア: 単行本
- 購入: 18人 クリック: 388回
- この商品を含むブログ (37件) を見る
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: KADOKAWA/アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (53件) を見る