自分の理解を深めるためにまとめてみました。7章の続きです。
8章 リリースエンジニアリング
リリースエンジニアの役割
Googleではリリースに関するデータ（デプロイにかかった時間等）を収集するツールを持っている。
哲学
リリースを頻繁に行うことでバージョン間の変更を極力少なくするという哲学を持っている。1時間毎にビルドしたり、「Push on Green」リリースモデルを使っているチームもある。ビルドは密封型であり、ビルドマシン上にインストールされているライブラリやその他のソフトウェアには影響されない。チェリーピッキングを採用している。基本的にはコードレビューを必須としている。
継続的ビルドとデプロイメント
GoogleはRapidと呼ばれる自動化されたリリースシステムを開発した。ビルドツールとしてBlazeを使用。全てのコードはソースコードツリーのメインブランチにチェックインされる。主要なプロジェクトはメインブランチから直接リリースされるのではなく、特定のリビジョンでメインブランチからブランチを作成し、そのブランチに加えられた変更はメインブランチにはマージしない。バグフィックスはメインブランチにコミットされ、チェリーピックによってリリース時にブランチに取り込まれる。メインブランチに変更が入るたびにユニットテストが走るようになっている。MPMによりパッケージ化され、本番環境に配布される。
まとめ
リリースエンジニアリングは初期の段階からやるべき。
（9章に続く）