2/16/2017

Googleでのソフトウェア・エンジニアリング (2.8)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.8. リリース・エンジニアリング

いくつかのチームには専任のリリース・エンジニアがいるが、Googleのほとんどのチームでは、リリース・エンジニアリング作業は一般のソフトウェア・エンジニアによって行われる。

ほとんどのソフトウェアのリリースは頻繁に行われる: 毎週あるいは隔週でのリリースが共通目標で、いくつかのチームは毎日リリースを行なっている。これは通常のリリース・エンジニアリング・タスクのほとんどを自動化することで可能となっている。頻繁にリリースを行うと、エンジニアのモチベーションを維持するのに役に立つ(将来に向けて、数ヶ月とか数年とかリリースが無ければ、何かにワクワクするのは難しくなる)、そして一定期間での反復を増やすことで全体の速度を上げ、フィードバックの機会やフィードバックに応答するチャンスが増える。

通常、リリースは未使用のワークスペースで始まり、最新のグリーン・ビルド(例えば、全ての自動テストが合格した最後の変更)の変更番号に同期することで、リリース・ブランチが作られる。リリース・エンジニアはチェリーピックされる。言い換えるとメイン・ブランチからリリース・ブランチにマージされる追加変更を選択できる。その後、ソフトウェアが最初から再構築され、テストが実行される。もし、テストが失敗した場合、追加の変更が加えられて障害が修正され、追加の変更がリリース・ブランチにチェリーピックされる。その後、ソフトウェアが再構築され、テストが再実行される。テストが全て合格すると、ビルドされた実行ファイルやデータファイルがパッケージ化される。これら全ての手順が自動化されるため、リリース・エンジニアはシンプルなコマンドを実行するだけで済むし、メニュー・ドリブンのUIでいくつかの項目を選択して、チェリーピックする変更(もしあれば)を選択できる。

候補ビルドがパッケージ化されると、一般に少数のユーザ(時には開発チームのみ)によってさらなる統合テストのためにステージング・サーバにロードされる。

有用なテクニックは、本番トラフィックからのリクエスト(サブネットの)のコピーをステージング・サーバに送信することと、実際の処理のために現在運用中のサーバに同じリクエストを送信することである。ステージング・サーバからの応答は破棄され、稼働中の本番サーバからの応答はユーザに送り返される。これにより、サーバを本番にする前に、深刻な問題を引き起こすかもしれない問題を確実に検出するのに役に立つ。

次の段階は通常、稼働中の本番トラフィックの一部を処理する一台以上の"カナリア"サーバに公開することである。ステージング・サーバとは異なり、これらは実際のユーザ向けに処理し、応答する。

最後に、リリースが全てのデータセンターの全てのサーバに公開される。非常に高いトラフィック、高品質のサービス向けには、これまでの手順で捕えられなかったバグが新たに取り込まれたことが原因で発生した障害の影響を軽減するため、数日かけて徐々に公開される。

Googleのリリース・エンジニアリングの詳細は、SREブックの第8章を参照して欲しい[7]。[15]も参照して欲しい。