Site Reliability Engineering #8

SRE

8章 リリースエンジニアリング

リリースエンジニアはソフトウェアをビルドし、リリースするまでの全てに関わる。 リリースエンジニアのスキルセットとして開発、設定管理、テストの統合、システム管理、カスタマサポートといった複数の領域に関する深い理解が必要と述べられている。

Googleではリリースエンジニアを1つの職能として位置づけ、ソフトウェアエンジニアとプロダクト開発を共にしてソースコードのコミットからリリースまでのプロセスを確立する。

リリースエンジニアはリリースエンジニアリング領域のメトリクスをレポートするツールも開発し、Googleのデータ駆動を支えている。

リリースエンジニアリングのガイドとして4つの原理で表されるエンジニアリングとサービスの哲学を持つ。

  • セルフサービスモデル
    • プロダクト開発チームが自身のリリースプロセスをコントロールできるようにプロセス整備と自動化をする
  • 高速性
    • リリースを頻繁に行うことでバージョン間の変更を少なくする

  • 密封ビルド

    • 一貫性と再現性を担保するためビルドプロセスは自己完結し、ビルド環境以外のサービスに依存させない

  • ポリシーと手順の強制

    • コードベースの変更にはほぼ全てのコードレビューが求められる。また、リリースまでに複数のセキュリティとアクセス制御を設け、リリース手順を保護している。

継続的ビルドとデプロイメントはCI/CDについて触れている。 ビルドツールを整備し、特定のリビジョンのメインラインからブランチを作成しチェリーピックするブランチ戦略、継続的テストの導入、プロダクションへのソフトウェア配布をするパッケージ管理システムが提供されている。

以上で述べた各プロセスのサービスを使い、リリースプロセスのワークフローを提供するシステムがRapidになる。

landing.google.com

Rapidは並列実行可能なシステムでプロセスを担当する外部サービスと組み合わせて動作する。 デプロイメントの設定は独自のblueprintsファイルで行い、権限設定も行うことができる。 Rapidの目標はサービスのリスクプロファイルに適合させることで、リリース頻度と安定性のバランスを取ることにある。 例えばリリース頻度を高めたい場合は1時間ごとにビルドしてテストをパスしたものはプッシュされる。 インフラストラクチャの重要な部分の場合、マルチリージョンのインスタンスに並行して交互にロールアウトするなどである。

リリースエンジニアリングは初期の段階で優れたプラクティスやプロセスを適用しておく方がコストは節約できる。