この記事では、Mozillaが彼らのブラウザーで使用しているリリースプロセスについて提示する。
2004年にMozillaはFirefoxの初期リリースをしてから2010年の7月にバージョン4.0に達した。しかし2011年からは、Googleの例に従ってリリースサイクルを変更し、現在はバージョン30になっている。この間、リリースエンジニアリングチームはブラウザーの新しいバージョンを生成するプロセスを改善した。4人のエンジニアグループ -Chris AtLee, Lukas Blakk, John O'Duinn, Armen Zambrano Gasparian- は、凝縮した形でリリースプロセスの詳細をDr. Dobb's Journalの記事に書いた。
彼らのブラウザーに関する潜在的なセキュリティ侵害を考慮するとMozillaは、既知の脆弱性を修正するために、迅速にユーザーに新しい“chemspill” (化学物質流出)バージョンを生成することができるようにリリースプロセスを設計した。プロセスは「堅牢制と所要時間」を改善するために可能な限り「人間の関与」を少なくし自動化されている。プロセスは、chemspillと通常リリースの両方に使用されている。各リリースの後、Mozillaは改良するべき課題があったかどうかを確認するために事後分析を実施する。問題が見つかると、他のリリースが始まる前に迅速に修正される。
リリースは、“トリアージ会議に出席し、すべての抽出作業の背景のコンテキストを理解氏、バグの深刻度を公平に議論でき、最新の変更の適用を承認して、難しい後退を決断する” ことができるリリースコーディネーターによってトリガーされる。コーディネーターは関連するすべてのチーム– 開発者, リリースエンジニアリング, QA, PR, など–と接触して、必要に応じて組織がビルドを停止することがある。
IRCや電話で新しいビルドを開始するコマンドを発行する問題が発生したら、Mozilla は、プロセスに関わるすべての人にEメールを通じてコマンドを発行することを決定し、Eメールのタイトルは、“go to build + product_name + version”を含むテキストである。Eメールには、ビルドとリリースされるソースコードの詳細情報として、時間ベースのコードリポジトリーに対する時間とタイムゾーンが含まれている。
完全なリリースプロセスは以下のステップで構成されている:
- リリースコーディネーターからGo-to-Buildメールが送信される。
- トリガーが開始される–
FIREFOX_30_0_RELEASEのようなタグが~85リポジトリ–製品, ローカライズ文字列, リリース自動化コード, ユーティリティ - でブラウザーの特定のバージョンを作成するために使用されるソースコードに適用される。リポジトリーが多いため、プロセスはおよそ20分続き、Mozillaは別々のタグ付けプロセスをパラレルで実行することにより、リポジトリーごとに5分削減したいと考えている。 - ビルダー開始 – リリースするプラットフォームごとにいくつかの調整されたビルドが起動され、タグ付けされたすべてのソースコードが含まれるソースバンドルを加え、結果がftp.mozilla.orgにアップロードされる。このステップには、ローカライゼーション“再パック”: en-USロケールビルドはアンパックされ、すべてのen-US文字列は対応するロケールに置き換えられてパックし直される。
- 署名– バイナリが署名される。Windowsの場合、インストーラー自信を含む、すべてのEXEとDLLファイルは署名される。いくつかのMD5とSHA1チェックサムは、ミラーでそのダウンロードを検証するために生成される。署名は、外部の通信からファイアウォール専用サーバーで実行される。パスワード、キーフレーズ、キーストアは、リリースエンジニアと人との間をセキュアなチャンネルのみを通じて転送される。
- テスト– chemspillリリースでは、QAが新しいリリースに必要なセキュリティバグの手動テストを実施する。問題が見つかると、それらは修正され、全体のビルドプロセスが再実行される。
- アップデートの生成 – アップデートパッケージは、ブラウザーのアップデーターによってダウンロードされるために作成される。アップデートパッケージは、各プラットフォーム、言語、以前のリリースごとに作成される。
- QAテスト - コミュニティメンバー、契約者、Mozilla社員は、署名されたビルドが準備できると、なるべく早く手動テストを実施し、また更新パッケージもテストする。自動機能テストプロセスも、このときにトリガーされる。すべてに問題がなければ、ビルドとアップデートのQAは完了する。
- ミラーリング – 更新は世界中の様々なミラーにプッシュされる。プロセスが完了すると、リリースコーディネーターは、新しいバージョンが提供されたという“Go Live” Eメール発表を送信し、リリースエンジニアは、新しいリリースに向くようにWebサイトとFTPサーバーを更新する。
Mozillaは、このリリースプロセスを開発しながら、いくつかの教訓を学んできた:
- 技術、非技術の両方のステークホルダーが、リリースの成功に発言することができるように検討することが重要である
- リリースプロセスはもっとも時間が費やされていると誰もが認識している。当初はMozilla内部の人達は、新しいバージョンのリリース作業がエンジニアのみの仕事であると考えられていたが、それ以外の多くの人がそのプロセスに関与していたことが判明した。
- リリースサイクルに関連した大きな問題は、“チーム間のミスコミュニケーション; 明確なリーダーシップの欠如; chemspillリリース時のストレス、慰労感、不安”であった。これは、“人のミスコミュニケーションを解消する明確なパス”によって改称された。
- チームの安定性は別の問題であった: あまりに多くのエンジニアがリリースチームを去って、その他でそれを置き換える必要があった。“正確な最新ドキュメントがないということは、リリースプロセスの技術的な理解の多くが伝承と口伝によってドキュメント化され、人が去る時には失われる”ということになる。これは全体のリリース問題に真剣に対応して、Mozillaのエンジニアが“ものごとをよりよくしようとし、自分の運命をある程度コントロールしたい”と感じることで変更された。
- 各リリースを以前のリリースよりもよくするという小さなステップによりリリースプロセス全体が改善された。自動化されたプロセスが改善され、チームはそれをさらに改善するためにより多くの時間を利用できるようになった。
著者によると、Firefoxで使われていたサードパーティー製のライブラリで発見された脆弱性に対処するために、Mozillaが2日で8個のchemspillリリースを生成できるところまでリリースプロセスが改善された。