前回は、リリースエンジニアの役割とその哲学について、学びました。
リリースにおいては、成果物に一貫性と再現性を担保する必要があり、またリリースを高速化するためのツールの開発や自動化が行われました。
今回は、継続的ビルドとデプロイメントについてです。
GoogleはRapidという自動リリースシステムを開発しました。これによりスケーラブルで信頼性の高い密閉型リリースを生成できるフレームワークを提供します。
Rapidとその関連ツールによる管理についてみていきます。
ビルド
GoogleはビルドツールにBlazeを使っています。
Blazeはビルドするときに依存対象のターゲットを自動的にビルドします。ビルドターゲットはRapidから指定され、Rapidプロジェクト固有のフラグがBlazeに渡されます。すべてのバイナリはビルド日付、リビジョン番号、ビルド識別子を表示するフラグをサポートするので、あるバイナリから容易にビルドの記録をたどることができます。
ビルドの密封性が高まり、問題の検出速度が早まります。
ブランチ
すべてのコードはメインブランチからチェックアウトされています。しかし、メインブランチから直接リリースが行われるのではなく、メインブランチからプロジェクトのブランチが切られています。そのブランチの変更はメインブランチへマージせず、バグフィックスがメインブランチへチェリーピックされます。これにより、無関係の変更をメインブランチへ取り込まれるのを防ぎ、各リリースの内容が厳密にわかります。
テスト
継続的テストシステムにおいては、変更が投入されるたびにメインブランチに対して、ユニットテストが実行されます。それによりビルドやテストの失敗はすぐに検出されます。
リリースエンジニアリングにおいては、継続的ビルドの際にユニットテストが行われることが推奨されています。このようにすることでリリース時に実行されるビルドが失敗してしまう確率を下げます。
パッケージ化
Googleにおいて、ソフトウェアは、Midas Package Manager（MPM）によって、プロダクション環境へ配布されます。パッケージは名前とユニークなハッシュによるバージョンが正当性の為に与えられます。Rapidは、ビルドIDを含むラベルを付けるので、パッケージ名とラベルを使えば、パッケージを一意に特定できます。
Rapid
Rapidは、blueprintsというファイルで設定されています。ビルドのとテストターゲットの指定、デプロイメントのルール、管理情報を定義します。Rapidのプロジェクトに対して行えるアクションの権限設定は、ロールベースのアクセスコントロールで指定されます。
デプロイメント
Rapidは、単純なデプロイメントを直接行うこともできます。blueprintsのデプロイメント定義と専用のタスクエグゼキュータで、新たにビルドされたMPMパッケージを使うように稼働中のBorgジョブを更新します。
また、複雑なデプロイメントをする場合は、ロールアウト自動化フレームワークのSisyphus（シシファス）が使われます。
Sisyphusにはダッシュボードが付いており、ロールアウトのコントロールと進行状況のモニタリングが行えます。
まとめ
- リリースの主要部分の自動化は、開発を高速化する。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 94-97