今回から新しい章に入ります。
内容はリリースエンジニアリングになります。
（最初リリースエンジニアリングをリバースエンジニアリングだと誤読してました。）
リリースエンジニアリングとは
リリースエンジニアリングは、最近急速に成長している比較的新しい分野であり、ソフトウェアのビルドとリリースを行います。
リリースエンジニアは、以下について、しっかりと理解していなければなりません。
- ソースコード管理
- コンパイラ
- ビルド設定言語
- 自動ビルドツール
- パッケージマネージャー
- インストーラ
また、リリースエンジニアのスキルセットには、開発、設定管理、テストの統合、システム管理、カスタマーサポートといった、複数の領域に関する深い理解が必要です。
そして、ソースコードからデプロイメントに至るプロセスに注意を払わなければなりません。
リリースエンジニアは、プロダクト開発に関わりながら、SREとリリースに関する規定を行います。
哲学
リリースエンジニアリングは、4つのエンジニアリングとサービスの哲学があります。
-
セルフサービスモデル
Googleのリリースエンジニアは、あらゆるリリースプロセスを網羅したツールとドキュメントを作成しています。これらを使い、チームそれぞれが新バージョンのリリース頻度と時期を規定します。
リリースプロセスは、エンジニアの作業が最小限で済むところまで、自動化可能です。
リリースは完全に自動化され、問題が起きた場合のみリリースエンジニアが対応します。 -
高速化
Googleでは、ユーザーが利用する機能をできるだけ早くリリースするという方針を持っています。これは、リリースを頻繁に行うことでバージョン間の変更を少なくするという考えを持っているからです。
リリースを行うチームの中には1時間ごとにビルドを行い、その中から本番環境へデプロイするものを選んでいるチームやすべてのテストにパスしたものをすべてリリースしているチームもあります。 -
密封ビルド
ビルドツールは、一貫性と再現性を担保する必要があります。
googleのビルドは密封型でビルドマシンにインストールされているライブラリやその他のツールに影響を受けません。代わりにビルドはコンパイラやライブラリの依存関係のバージョンまで指定されます。ビルド環境は自己完結している必要があります。
もし、バグが発生し、それを修復する場合は、オリジナルのビルドの修正をチェリーピックし、それを含めた上でオリジナルの再ビルドをします。この時、新しいバージョンのコンパイラなどは使用しません。新しいコンパイラに互換性がない機能や必要のない機能が含まれているかもしれないからです。 -
ポリシーと手順の強制
Googleにおいて、コードベースの変更は、ほぼすべてコードレビューが行われます。
これは、開発ワークフローの中に組み込まれています。自動化されたリリースシステムによって、リリース中に含まれるすべての変更に関するレポートを生成します。これにより、問題があった際の対応の速度が向上します。
##まとめ
- リリースは、一貫性と再現性を担保しなければならない。
- 高速なリリースの為に、自動化を行う
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 91-94