最近公開されたFacebookのリリースプロセスのスケールについての記事はプロダクションへのコードの配置についての柔軟な方法について書かれている。この記事には"チェリーピッキング"から"マスターからのプッシュ"という方法に1年以上かけて移行したことについて書かれている。Facebookは以前にも配置プロセスについて詳しく解説していた。この記事を書いたChuck Rossi氏は同社で初めてのリリースエンジニアだった人物であり、現在は同社のエンジニアリングディレクターを務めている。
Facebookのリリースサイクルは"準連続"だ。つまり、全てのコミットが1回でプロダクションに配置されるわけではない。たくさんのコミットがまとめて数時間ごとにプッシュされる。この階層化されたリリース方式は変更のロールバックを簡単にする。
このリリースの仕組みの展開は2016年の4月に始まり、1年かけて徐々に広めていった。以前の方式ではマスターのコミットの中から特定の変更を取り出してリリースブランチに入れていた。この変更はリリースブランチから日次でプロダクションに配置されていた。このようにチェリーピッキングされる変更は1日で500から1000ほどあった。残りの変更は"週次"のリリースブランチに含まれた。時間が経つにつれ、コミットの数もエンジニアの数も増え、リリースエンジニアのマニュアルの作業では持続可能ではない状態になった。
この継続的配置のシステムの中核の部分は変更の受け手が制御できる方法であり、配置と計測のための自動化されたツールだ。まず、一連の自動テストを行ってから、変更がFacebookの従業員によってプッシュされる。この段階で見つかった問題はブロッカーとして認識されプロセスを止める。次はカナリア配置でプロダクションの2%にプッシュされる。ここでも継続的にモニタリングされ問題はけんちされる。全てがうまくいったら、プロダクションに100%配置される。Flytrapと呼ばれるツールがユーザーレポートを収集し、何か例外的なことがあったら警告が発せられる。
画像の引用元 https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale
Facebookのウェブとモバイルの製品は2つの別のパスを通る。ウェブよりもネイティブのモバイルの方が配置の頻度が少ない。両方ともGatekeeperと呼ばれるシステムで制御されている。Gatekeeperは配置とリリース分離する役割も担う。この分離は難しいもので、後方互換性を維持する必要がある。
モバイルでの継続的配置の難しい点は、そのツールと配置の選択肢のおかげで、独特のものとなっている。ウェブの配置は簡単だ。Facebookは全てスタックとツールを握っているからだ。このモバイルの難しさを回避するために、同社はモバイルの配置を高速化するためのツールとライブラリを開発した。Buck、Phabricator、Infer、React、Nuclideといったツールだ。Facebookのモバイルの配置はは3つのレイヤが並列で走る。
- ビルド - 複数のチップのアーキテクチャごとに全ての影響を受ける製品(InstagramやMessenger)のためにモバイルのマスターにマージされた全てのコードをビルドする。
- 静的コード解析 - linterとInferと呼ばれる静的解析ツールとの組み合わせで、リソースのリーくや、未使用の変数、危険なシステムコール、コードガイドラインへの準拠などさまざまなチェックを行う。
- 自動テスト - 単体テスト、結合テスト、エンドツーエンドテストをRoboelectric、XCTest、JUnit、WebDriverのようなツールで実行する。
このモバイルのビルドとテストの実行は全てのコミットに対して、コード変更のライフサイクルの中で複数回行われる。Androidだけで1日に50000回から60000回のビルドが行われる。モバイルの配置の仕組みは週に1度リリースするという古いウェブのリリース方法に従っている。コードのデリバリの速度とリリースの頻度が向上しているものの、エンジニアの生産性は一定のままだ。しかし、記事で言及されている条件、つまり、コードの行数とプッシュの回数は生産性を計測するのに最も良い指標ではないかもしれない。
2016 IEEEのペーパーと関連する講演によれば、Facebookは2005年の段階で継続的配置を実践していた。このペーパーの結論によれば、継続的配置の成功条件は、継続的で思慮深い投資、高いスキルを持つ開発者、強い技術マネジメント、権限を与える文化、失敗に対する目的を持った振り返り、そして小さくて集中しテイルチームだ。
Facebookの準連続な配置システムにはいくつかの利点がある。ホットフィクスをプッシュするのにマニュアルの対応が不要であること。分散されたエンジニアリングチームのサポートを受けられること。ユーザーからのフィードバックが高速になることだ。
Rate this Article
- Editor Review
- Chief Editor Action