Rapid
nobuoka.icon ジョブマネジメントシステムみたいな感じっぽい？
ビルドやテストのターゲットやデプロイルール、所有者などの管理情報の定義
一般的なリリースフロー
Rapid が、要求されたリビジョン番号 (継続的テストシステムから取得されることが多い) でリリースブランチを作成 Rapid が Blaze を使用してバイナリのコンパイルと単体テストを実施 (多くの場合は並行で実施される) nobuoka.icon Borg ジョブではなく、専用の環境で実施されるため、並列化が容易らしい
ビルド成果物は、システムテストとカナリアデプロイに利用できる
典型的なカナリアデプロイでは、システムテストの後に本番環境でいくつかのジョブを実行する
Google におけるソフトウェアライフサイクルと Rapid の関係は以下のとおり ビルド (Building)
バイナリと単体テストのビルドターゲットは、Rapid のプロジェクト構成ファイルで定義される
ブランチ (Branching)
ソースコードは全てメインラインにコミットされる
多くのプロジェクトでは、メインラインを直接リリースすることはしない
特定のリビジョンからブランチをはやして、リリースする
バグ修正は、メインラインにコミットされる → 各リリースのブランチでそれを cherry-pick する
これにより、リリース後にメインラインにマージされた無関係な変更を取り込んでしまうことを回避
テスト (Testing)
パッケージされたビルド成果物 (packaged build artifacts) に対して、独立した環境でのシステムレベルのテスト (system-level test) も実施
手動か Rapid からの起動
パッケージ (Packaging)
パッケージには名前が付けられ、一意のハッシュでバージョン管理されている
信頼性確保のために署名も
MPM ではパッケージにラベルを付けることができ、リリースプロセスで、リリース対象のラベルを指定する、というような使い方ができる
新しいパッケージにリリース対象のラベルを移行することで、自動的に新しいパッケージをリリース対象にできる
デプロイ (Deployment)
単純なデプロイで直接使用されることが多い
複雑なデプロイでは Sisyphus (汎用のロールアウト自動化フレームワーク) が使用される