卷2：第2章 Firefox發(fā)布工程

原文鏈接：http://www.aosabook.org/en/cmake.html

作者：Chris AtLee,?Lukas Blakk,?John O'Duinn,?Armen Zambrano Gasparian

最近，Mozilla發(fā)布工程組在Firefox的發(fā)布自動化方面取得了非常多的進步。我們已經(jīng)減少了在簽字和發(fā)送通知時對人工參與的要求，并且自動化了許多其它的小的手工步驟，因為流程中每個手工步驟都可能犯錯。盡管仍不算完美，我們始終在盡最大努力自動化發(fā)布過程，最終目標(biāo)是真正的一鍵式發(fā)布；最小化人工干預(yù)將會消除我們在之前那種半人工半自動化的發(fā)布過程中所經(jīng)歷過的重復(fù)勞動和許多令人頭疼的事情。在本章，我們將帶著你走入并領(lǐng)略構(gòu)成完整的Firefox快速發(fā)布系統(tǒng)的腳本和架構(gòu)的世界（到Firefox 10為止）。

你將會看到一個可發(fā)布的Mercurial變更集是如何成為候選發(fā)布，進而成為公開發(fā)布的，此時就對全世界每日高達4億5千多萬的用戶完全開放了。我們將會從構(gòu)建和代碼簽名開始，接下來是定制的合作伙伴和本地化重打包，QA過程，以及如何為每個支持的版本、平臺和本地化生成更新。每一個步驟都必須正確的完成，一個發(fā)布才可以被推送到Mozilla社區(qū)的鏡像網(wǎng)絡(luò)上供用戶下載。

我們將會看到一些旨在改善此流程的決定；例如，健康檢查腳本，幫助消除了許多人工錯誤導(dǎo)致的問題；自動簽名腳本；移動發(fā)布集成到桌面發(fā)布流程；補丁程序，用來創(chuàng)建更新；以及應(yīng)用更新服務(wù)（AUS - Application Update Service），將更新發(fā)送給使用著各種不同版本的用戶。

本章描述了如何產(chǎn)生Firefox發(fā)布構(gòu)建的機制，大部分篇幅都在講解一次構(gòu)建開始后發(fā)布流程的各個關(guān)鍵步驟。但是，在發(fā)布工程開始產(chǎn)生發(fā)布構(gòu)建之前，還需要做足夠的復(fù)雜的跨團隊溝通。因此，我們就從這里開始吧。

2.1 在開始一個發(fā)布之前的N個工作

圖2.2：完整的發(fā)布時間線，以chemspill為例

2.2. 進入構(gòu)建

誰來決定進入構(gòu)建

在發(fā)布開始之前，一個人被指定負(fù)責(zé)協(xié)調(diào)整個發(fā)布過程。他/她需要參加類選會議、理解所有項目背景、公平的仲裁bug嚴(yán)重性上的爭議、批準(zhǔn)最新的變更、做出艱難的放棄決定等等。最后，在發(fā)布日，這個角色在現(xiàn)場負(fù)責(zé)與各個團隊的所有溝通：開發(fā)、QA、發(fā)布工程、網(wǎng)站開發(fā)、公共關(guān)系、市場等等。

這個角色在不同的公司有不同的稱呼：發(fā)布經(jīng)理、發(fā)布工程師、Program Manager、項目經(jīng)理、產(chǎn)品經(jīng)理、產(chǎn)品沙皇、發(fā)布舵手等等。本章將使用“發(fā)布協(xié)調(diào)員”這一稱謂，因為我們覺得這個詞最清楚的表達了該角色在我們的流程里起的作用。重點在于這個角色及其代表的最終權(quán)威能夠被每個人所清楚的理解，無論其背景或之前在其它地方的工作經(jīng)歷。在發(fā)布日，每個人都知道自己應(yīng)該遵守和信任這個角色所做出的協(xié)調(diào)決定。

發(fā)布協(xié)調(diào)員也是發(fā)布工程之外唯一一個有權(quán)在重大問題出現(xiàn)后發(fā)出“停止構(gòu)建”郵件的人。任何疑似重大問題報告也會被發(fā)送到發(fā)布協(xié)調(diào)員，由他/她來評估及做出go/no-go的決定，并及時的將此決定周知到每個人。在發(fā)布日，我們所有人必須遵守和信任這個角色所作出的協(xié)調(diào)決定。

如何發(fā)出“進入構(gòu)建”信號？

早先通過IRC或者電話口頭的通知帶來了很多誤解，時常給進行中的發(fā)布造成問題。因此，我們現(xiàn)在要求“go to build”信號通過電子郵件發(fā)送到一個包含了與發(fā)布過程相關(guān)的所有團隊的每個人的郵件列表。郵件標(biāo)題包含“go to build”加上產(chǎn)品名及版本號，例如：go to build Firefox 6.0.1。

類似的，如果出現(xiàn)了問題，發(fā)布協(xié)調(diào)員會發(fā)送一個新的“all stop”郵件給同樣的郵件列表。我們發(fā)現(xiàn)另外一種做法——回復(fù)該發(fā)布的最新的郵件——是不行的，因為一些客戶端的郵件會話功能會造成一些人注意不到藏的很深的“all stop”郵件。

在“Go to Build”郵件里有些什么？

1. 構(gòu)建的代碼；理想情況下，是指向要生成發(fā)布構(gòu)建的源碼庫里的特定變更的URL。

a) 類似“使用最新代碼”這樣的指令是絕對不行的；曾經(jīng)有一個發(fā)布，在“go to build”郵件發(fā)出之后而構(gòu)建開始之前，一個好心的開發(fā)未經(jīng)批準(zhǔn)提交了一個變更到一個錯誤的分支，導(dǎo)致發(fā)布將此變更包括在構(gòu)建中。幸好這個錯誤在交付之前被發(fā)現(xiàn)了，但是，我們因而完全終止、全部重新構(gòu)建，并推遲了發(fā)布。

b) 在象CVS這樣的基于時間的版本控制系統(tǒng)里，要十分明確的使用準(zhǔn)確的時間；精確到秒，并指定時區(qū)。曾經(jīng)有一個發(fā)布，在Firefox還使用CVS的時候，發(fā)布協(xié)調(diào)員指定了一個構(gòu)建的截至?xí)r間但是未說明時區(qū)。當(dāng)發(fā)布工程注意到缺失時區(qū)信息時，發(fā)布協(xié)調(diào)員睡著了。發(fā)布工程正確的猜想應(yīng)該是本地時間（加利福尼亞）。然而，在一次深夜的發(fā)布中，我們將PST看作了PDT，結(jié)果丟了最后一個關(guān)鍵的bug修復(fù)。這個錯誤在交付之前被QA發(fā)現(xiàn)了，但是我們不得不停止并使用新的截至?xí)r間重新構(gòu)建。

2.對于特定發(fā)布的清晰的緊迫感。聽起來顯而易見，但在處理一些重要的特例時非常重要，簡單總結(jié)如下：

a) 一些發(fā)布是例行的，可以在正常工作時間完成。這些都是預(yù)先安排的發(fā)布，也會按時完成，不存在緊急性。當(dāng)然，所有發(fā)布的構(gòu)建都需要及時的創(chuàng)建，只是不需要發(fā)布工程師熬夜趕工去完成。我們會事先做好安排，人們只需要在正常上班時間工作就可保證每件事情都按時完成。這將保持大家的體力，以便更好的應(yīng)對那些意料之外的緊急工作。

b) 一些發(fā)布屬于chemspill這樣緊急性的，需要爭分奪秒。典型的例子包括修復(fù)公開的安全漏洞，或者修復(fù)影響大量用戶的崩潰性問題。Chemspills需要被盡快創(chuàng)建，而不是按預(yù)先的安排。

c) 一些發(fā)布在例行和chemspill之間轉(zhuǎn)換。例如，當(dāng)一個例行發(fā)布的安全修復(fù)意外的泄漏了，就變成了一個chemspill發(fā)布。當(dāng)一個業(yè)務(wù)需求如給即將到來的一次會議公告準(zhǔn)備的“特供預(yù)覽”發(fā)布，由于商務(wù)原因被延遲時，就從chemspill發(fā)布變?yōu)槔邪l(fā)布。

d) 一些發(fā)布的性質(zhì)存在爭議，因為對相同的修復(fù)存在不同角度的理解。

正是發(fā)布協(xié)調(diào)員這個角色，負(fù)責(zé)平衡所有這些事實和觀點，達成決定，并將有關(guān)緊迫性的決定清楚一致的周知到所有團隊。一旦有新的信息，發(fā)布協(xié)調(diào)員會重新評估和周知。一些團隊認(rèn)為一個發(fā)布是chemspill而另外的團隊認(rèn)為是例行的，這種情形對跨團隊的合作是非常有害的。

最后，這些郵件對于度量一次發(fā)布中的時間分配非常有用。盡管它們的準(zhǔn)確度不會超過掛鐘的時間粒度，但對于我們判斷下一步應(yīng)該把工作集中在哪里以加快速度來說已經(jīng)是非常有用的了。正如古老的格言所說，先有度量，才能改進。

在Firefox的beta周期里，我們也在做mozilla-beta庫的周發(fā)布。每個這樣的beta發(fā)布都要經(jīng)過我們通常的完整的發(fā)布自動化，與常規(guī)的最終發(fā)布幾乎一模一樣。為了最小化意外，發(fā)布自動化流程或底層架構(gòu)在開始最終發(fā)布構(gòu)建之前不能有任何未經(jīng)測試的變化。

2.3. 打標(biāo)簽，構(gòu)建，源碼壓縮包

圖2.4: 對每一個語言進行Firefox重打包

現(xiàn)在，我們將整個repacks分成六個作業(yè)，放在六臺不同的機器上并行執(zhí)行。這種方法將時間減少到了原來的六分之一。這也使得我們可以在個別repack失敗時重做一部分作業(yè)，而不是全部。我們可以將repacks分成更多、更小的并行的作業(yè)，但發(fā)現(xiàn)這將會占用太多的機器，進而影響到在持續(xù)集成系統(tǒng)上運行的由開發(fā)啟動的無關(guān)作業(yè)。

移動發(fā)布（Andoid）流程稍有不同，因為我們僅產(chǎn)生兩個安裝包：一個英語版的，一個多語言版的將一打語言一塊放進安裝包里而不是每個獨立的構(gòu)建放一個。多語言版本的大小是一個問題，尤其是對移動設(shè)備的慢速下載而言?？赡艿囊粋€改進是其它語言按需請求并從addons.mozilla.org取得。

在圖2.4里，可以看到語言信息依賴三個不同的源：shipped_locales，l10_changesets 和 l10n-changesets_mobile-release.json。（計劃合并成一個統(tǒng)一的JSON文件）這些文件包含不同本地化的信息以及某些平臺例外。特別的，對于某個給定的本地化，我們需要知道對于給定的發(fā)布使用庫的哪個修訂，以及是否它可以用于所有支持的平臺（例如，Mac上的日語來自于一個不同的庫）。Desktop發(fā)布有兩個這種文件，而移動發(fā)布有一個（此JSON文件包含平臺列表和變更集）。

誰來決定發(fā)布哪種語言呢？首先，本地化負(fù)責(zé)人自己提名特定的變更集，然后由Mozilla的本地化小組評審，顯示在一個web儀表盤里，其中列出了每種語言需要的變更集。發(fā)布協(xié)調(diào)員也會在發(fā)出“go to build”郵件前進行評審。發(fā)布的時候就可以獲取變更集列表，加入到重打包中。

除了本地化重打包以為，我們還進行合作伙伴重打包。這是為希望定制其客戶體驗的各個合作伙伴而當(dāng)定制的構(gòu)建。主要的變化是定制的書簽、主頁和搜索引擎，但是很多其它的事情也可以被改變。這些定制的構(gòu)建是為最新的Firefox發(fā)布生成的，不適用于beta版。

2.5. 簽名

為了讓用戶肯定他們下載的Firefox是真實的來自Mozilla且未經(jīng)篡改的版本，我們使用了幾種不同類型的數(shù)字簽名。

第一種簽名用于Windows版本，我們使用了Microsoft Authenticode（signcode）簽名鍵去簽署.exe和.dll文件。Windows可以使用這些簽名來驗證應(yīng)用來自可信賴源。我們還用Authenticode鍵對Firefox的安裝程序進行的簽名。

接下來我們使用GPG為所有平臺上的所有版本生成一系列MD5和SHA1校驗和，為校驗和文件及所有構(gòu)建和安裝程序生成分割的GPG簽名。這些簽名供鏡像網(wǎng)站及其它社區(qū)成員進行下載驗證。

出于安全目的，我們有一個專門的通過防火墻和VPN與外部鏈接隔離的簽名機器。Keyphrases, password和keystores通過安全通道在發(fā)布工程師間傳送，經(jīng)常是親自取送，以最小化泄漏的風(fēng)險。