<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                > 原文鏈接:[http://www.aosabook.org/en/cmake.html](http://www.aosabook.org/en/cmake.html) > 作者:[Chris AtLee](http://www.aosabook.org/en/intro2.html#atlee-chris),?[Lukas Blakk](http://www.aosabook.org/en/intro2.html#blakk-lukas),?[John O'Duinn](http://www.aosabook.org/en/intro2.html#oduinn-john),?[Armen Zambrano Gasparian](http://www.aosabook.org/en/intro2.html#zambrano-gasparnian-armen) 最近,Mozilla發布工程組在Firefox的發布自動化方面取得了非常多的進步。我們已經減少了在簽字和發送通知時對人工參與的要求,并且自動化了許多其它的小的手工步驟,因為流程中每個手工步驟都可能犯錯。盡管仍不算完美,我們始終在盡最大努力自動化發布過程,最終目標是真正的一鍵式發布;最小化人工干預將會消除我們在之前那種半人工半自動化的發布過程中所經歷過的重復勞動和許多令人頭疼的事情。在本章,我們將帶著你走入并領略構成完整的Firefox快速發布系統的腳本和架構的世界(到Firefox 10為止)。 你將會看到一個可發布的Mercurial變更集是如何成為候選發布,進而成為公開發布的,此時就對全世界每日高達4億5千多萬的用戶完全開放了。我們將會從構建和代碼簽名開始,接下來是定制的合作伙伴和本地化重打包,QA過程,以及如何為每個支持的版本、平臺和本地化生成更新。每一個步驟都必須正確的完成,一個發布才可以被推送到Mozilla社區的鏡像網絡上供用戶下載。 我們將會看到一些旨在改善此流程的決定;例如,健康檢查腳本,幫助消除了許多人工錯誤導致的問題;自動簽名腳本;移動發布集成到桌面發布流程;補丁程序,用來創建更新;以及應用更新服務(AUS - Application Update Service),將更新發送給使用著各種不同版本的用戶。 本章描述了如何產生Firefox發布構建的機制,大部分篇幅都在講解一次構建開始后發布流程的各個關鍵步驟。但是,在發布工程開始產生發布構建之前,還需要做足夠的復雜的跨團隊溝通。因此,我們就從這里開始吧。 ## 2.1 在開始一個發布之前的N個工作 ![enter image description here](http://box.kancloud.cn/2015-08-20_55d58ac287474.jpg) 圖2.1 從代碼到“go to build” 在啟動Mozilla發布過程改進項目之初,我們就有這樣的假設:Firefox變得越普及,用戶就會越多,就會越成為黑帽子黑客尋找安全漏洞進行攻擊的目標;同樣的,我們就必須保護更多的用戶免受新漏洞的影響,因此,有能力盡快交付一個安全修復就變得更加的重要。我們為此專門發明了一個詞叫:chemspill發布(化學泄漏chemical spill的縮寫)。與其被常規發布之間偶爾的chemspill發布弄個措手不及,不如能設計出一種發布自動化機制,能支持每個發布都是chemspill發布。 這種思路帶來三個重要的結果: 1. 我們在每個發布之后進行一次事后分析,看是否存在改進的空間:有什么事情可以變得更加平順、更容易、更快。即使再小的改進,我們也會在下一個發布之前立即實施。這種對發布自動化的持續優化意味著我們總是在尋找新的方法來減少對人工干預的依賴,以及在魯棒性和周轉時間上的改善。大量的工作花在了加強工具和流程使之嚴絲合縫毫無破綻上,能夠盡快的捕獲和處理類似網絡斷續、硬盤空間問題、人工拼寫錯誤這樣的“罕見”事件。雖然處理常規的、非chemspill發布已經夠快了,我們仍然想減少未來發布中可能遇到的任何人工錯誤的風險。在chemspill發布中尤其如此。 2. 當我們真的面臨一個chemspill發布時,發布自動化越魯棒,發布工程中大家的壓力就越小。我們已經習慣了從容不迫而又精準的快速發布,通過開發一系列工具使得這一過程盡可能的安全和魯棒。小的壓力意味著在一個良好預演的流程里更從容不迫和精準地工作,這有助于chemspill發布更加的平穩。 3. 我們在整個Mozilla范圍內建立了一個 “go to build”流程。在一個常規的非chemspill發布中,讓每個人查看同樣的bug類選(triage)查詢,看到最后一個修復生效并測試成功,一致同意何時開始構建是沒有問題的。但是對一個chemspill發布,時間緊迫,爭分奪秒,跟蹤一個問題的所有細節、所有的bug確認和修復變得很復雜、很緊張。為了降低復雜度和出錯的風險,現在Mozilla有一個全職人員負責跟蹤代碼是否準備就緒進入構建過程。在一個chemspill中改變流程是危險的,因此為了保證每個人即使在時間緊迫的情況下對流程也都很熟悉,chemspill發布和常規發布使用同一個流程。 ![enter image description here](http://box.kancloud.cn/2015-08-20_55d58ac2e9aa5.jpg) 圖2.2:完整的發布時間線,以chemspill為例 ## 2.2\. 進入構建 **誰來決定進入構建** 在發布開始之前,一個人被指定負責協調整個發布過程。他/她需要參加類選會議、理解所有項目背景、公平的仲裁bug嚴重性上的爭議、批準最新的變更、做出艱難的放棄決定等等。最后,在發布日,這個角色在現場負責與各個團隊的所有溝通:開發、QA、發布工程、網站開發、公共關系、市場等等。 這個角色在不同的公司有不同的稱呼:發布經理、發布工程師、Program Manager、項目經理、產品經理、產品沙皇、發布舵手等等。本章將使用“發布協調員”這一稱謂,因為我們覺得這個詞最清楚的表達了該角色在我們的流程里起的作用。重點在于這個角色及其代表的最終權威能夠被每個人所清楚的理解,無論其背景或之前在其它地方的工作經歷。在發布日,每個人都知道自己應該遵守和信任這個角色所做出的協調決定。 發布協調員也是發布工程之外唯一一個有權在重大問題出現后發出“停止構建”郵件的人。任何疑似重大問題報告也會被發送到發布協調員,由他/她來評估及做出go/no-go的決定,并及時的將此決定周知到每個人。在發布日,我們所有人必須遵守和信任這個角色所作出的協調決定。 **如何發出“進入構建”信號?** 早先通過IRC或者電話口頭的通知帶來了很多誤解,時常給進行中的發布造成問題。因此,我們現在要求“go to build”信號通過電子郵件發送到一個包含了與發布過程相關的所有團隊的每個人的郵件列表。郵件標題包含“go to build”加上產品名及版本號,例如:go to build Firefox 6.0.1。 類似的,如果出現了問題,發布協調員會發送一個新的“all stop”郵件給同樣的郵件列表。我們發現另外一種做法——回復該發布的最新的郵件——是不行的,因為一些客戶端的郵件會話功能會造成一些人注意不到藏的很深的“all stop”郵件。 **在“Go to Build”郵件里有些什么?** 1. 構建的代碼;理想情況下,是指向要生成發布構建的源碼庫里的特定變更的URL。 a) 類似“使用最新代碼”這樣的指令是絕對不行的;曾經有一個發布,在“go to build”郵件發出之后而構建開始之前,一個好心的開發未經批準提交了一個變更到一個錯誤的分支,導致發布將此變更包括在構建中。幸好這個錯誤在交付之前被發現了,但是,我們因而完全終止、全部重新構建,并推遲了發布。 b) 在象CVS這樣的基于時間的版本控制系統里,要十分明確的使用準確的時間;精確到秒,并指定時區。曾經有一個發布,在Firefox還使用CVS的時候,發布協調員指定了一個構建的截至時間但是未說明時區。當發布工程注意到缺失時區信息時,發布協調員睡著了。發布工程正確的猜想應該是本地時間(加利福尼亞)。然而,在一次深夜的發布中,我們將PST看作了PDT,結果丟了最后一個關鍵的bug修復。這個錯誤在交付之前被QA發現了,但是我們不得不停止并使用新的截至時間重新構建。 2.對于特定發布的清晰的緊迫感。聽起來顯而易見,但在處理一些重要的特例時非常重要,簡單總結如下: a) 一些發布是例行的,可以在正常工作時間完成。這些都是預先安排的發布,也會按時完成,不存在緊急性。當然,所有發布的構建都需要及時的創建,只是不需要發布工程師熬夜趕工去完成。我們會事先做好安排,人們只需要在正常上班時間工作就可保證每件事情都按時完成。這將保持大家的體力,以便更好的應對那些意料之外的緊急工作。 b) 一些發布屬于chemspill這樣緊急性的,需要爭分奪秒。典型的例子包括修復公開的安全漏洞,或者修復影響大量用戶的崩潰性問題。Chemspills需要被盡快創建,而不是按預先的安排。 c) 一些發布在例行和chemspill之間轉換。例如,當一個例行發布的安全修復意外的泄漏了,就變成了一個chemspill發布。當一個業務需求如給即將到來的一次會議公告準備的“特供預覽”發布,由于商務原因被延遲時,就從chemspill發布變為例行發布。 d) 一些發布的性質存在爭議,因為對相同的修復存在不同角度的理解。 正是發布協調員這個角色,負責平衡所有這些事實和觀點,達成決定,并將有關緊迫性的決定清楚一致的周知到所有團隊。一旦有新的信息,發布協調員會重新評估和周知。一些團隊認為一個發布是chemspill而另外的團隊認為是例行的,這種情形對跨團隊的合作是非常有害的。 最后,這些郵件對于度量一次發布中的時間分配非常有用。盡管它們的準確度不會超過掛鐘的時間粒度,但對于我們判斷下一步應該把工作集中在哪里以加快速度來說已經是非常有用的了。正如古老的格言所說,先有度量,才能改進。 在Firefox的beta周期里,我們也在做mozilla-beta庫的周發布。每個這樣的beta發布都要經過我們通常的完整的發布自動化,與常規的最終發布幾乎一模一樣。為了最小化意外,發布自動化流程或底層架構在開始最終發布構建之前不能有任何未經測試的變化。 ## 2.3\. 打標簽,構建,源碼壓縮包 ![enter image description here](http://box.kancloud.cn/2015-08-20_55d58ac34ba85.jpg) 圖2.3:自動化打標簽 我們最近開始使用一個腳本release_sanity.py為啟動自動化做準備,這個腳本最初是發布工程的一個夏季實習生寫的,能輔助發布工程師復核所有的配置與檢入工具和配置庫的內容相一致,還會檢查mozilla-release特定發布的代碼修訂里的內容,以及用來生成構建和語言包的所有語言。 這個腳本的輸入包括要使用的發布配置的buildbot config文件、要檢查的分支(例如mozilla-release)、構建及其版本號,以及要構建的產品名(例如fennec或firefox)。如果發布庫與配置內容不一致,或者語言庫變更集與交付地區和本地化變更集文件不一致,或者發布版本號和構建號與構建工具得到的從產品、版本、構建號生成的標簽不一致,腳本就會失敗。當腳本里的所有測試都通過以后,就會重新配置運行該腳本的buildbot master,觸發發布構建器,生成“send change”信號,啟動自動化發布過程。 在發布工程師啟動構建器之后,Firefox發布過程的第一個自動化步驟是對相關的源代碼庫打標記,記錄該版本和構建號的候選發布所使用的源碼、語言庫和相關工具的修訂。這些標記使我們得以在發布庫里保留Firefox和Fennec(移動版的Firefox)發布的各種版本和構建號的歷史。Firefox發布的一個標記的例子:FIREFOX_10_0_RELEASE FIREFOX_10_0_BUILD1 FENNEC_10_0_RELEASE FENNEC_10_0_BUILD1。 Firefox的一次發布使用來自大約85個版本控制庫的代碼,這些庫包含著產品代碼、本地化串、發布自動化代碼和輔助性部件等。對所有這些庫打標記,是為了保證發布自動化接下來的步驟使用相同的修訂,同時還有很多其它好處:Linux發行版及其它貢獻者能夠用完全相同的代碼和工具重新產生這些構建,并且支持將來做多個發布內容的比較。一旦所有的庫都建好了分支并打了標記,一系列相關聯的構建器自動啟動:每個發布平臺一個構建器,再加上一個包含該發布所用源代碼的源碼包。源碼包及構建安裝程序都被上傳到發布目錄。這使得任何人都能看到發布中的確切代碼,并能在需要時用這個快照重新產生構建,例如,當VCS失敗的時候。對Firefox的構建源代碼來說,有時會需要從一個更早期的庫中導入代碼。例如,就beta發布而言,這意味著從Mozilla-Aurora中取得簽署的修訂,如Firefox10.0.b1。對一個發布而言,這意味著從Mozilla-Beta(一般是與10.0b6相同的代碼)取得批準的變更放到Mozilla-Release庫里。這個發布分支接著就被創建作為一個命名分支,其父變更集設置為發布協調員提供的“go to build”郵件中指明的簽署的修訂。此發布分支可被用于對源代碼做發布相關的修改,例如校正版本號或者最終確定要構建的語言信息。如果將來發現了一個需要立即修復的重大的安全漏洞——一個chemspill——一個最小變更將會在此分支上發生,隨后產生一個新版本的Firefox。當必須得為一個特定的發布做另一輪的構建時,buildN,我們可以從這些分支得到相同的代碼,它們是被簽署允許“go to build”的,也是任何對此發布代碼的變更發生的地方。自動化流程再次啟動并校正標簽到該分支的新變更集上。標記流程對本地和遠程的Mercurial庫完成很多操作,為了能夠自動完成一些最常用的操作,我們寫了幾個輔助工具:retry.py和hgtool.py。retry.py是一個簡單的封裝,能夠運行一個給定的命令,在失敗時重試幾次;還可以捕獲例外輸出然后重試或者報告錯誤。我們發現將最常用的由于外部依賴可能出錯的命令封裝到retry.py里非常的有用。就標記而言,Mercurial操作會由于臨時性的網絡故障、web服務器問題或者后臺Mercurial服務器短暫的超載而失敗。能夠自動重試這些操作然后繼續得以節省大量的時間,因為我們不必進行人工恢復、清理然后再次啟動發布自動化。Hgtool.py是一個封裝了幾種常用的Mercurial操作的小工具,如使用單次調用進行的克隆、拉取和更新。它還支持Mercurial的共享擴展,這個功能使用得非常頻繁以避免在同一機器上把相同的庫克隆多份。增加對共享的本地庫的支持極大的加速了我們的標記流程,因為避免了大多數的對產品和語言庫的完全克隆。開發類似工具的一個重要的動機是使我們的自動化盡可能的可測試。因為類似hgtool.py這樣的工具是很小且功能單一的,用可復用的庫開發,非常易于單獨測試。 今天,我們的標記在兩個并行的作業中完成:一個是桌面Firefox的,花費20分鐘左右,包括了對80+語言庫的標記;另一個是移動Firefox的,花費大概10分鐘,因為現在移動發布的語言還比較少。我們計劃將來進一步優化發布自動化流程,做到并行標記所有的庫。初始的構建可以在產品代碼和工具需求庫標記完成之后立即啟動,不必等待語言庫的標記。到這些構建結束時,其余的庫將會完成標記然后本地化打包和接下來的步驟就可以進行了。我們預計這將把構建完成的總時間減少15分鐘。 ## 2.4\. 本地化重打包和合作伙伴重打包 一旦桌面構建生成并被上傳到ftp.mozilla.org以后,自動化流程就會觸發本地化再打包工作。一次本地化再打包將原來的構建解壓、將en-US字符串替換成在此發布里要使用的另外一種語言,然后重新把所有的文件打包,這就是叫做重打包的原因。對該發布中的每一種語言重復此過程。開始的時候,所有的重打包都是串行的。然而,當語言越來越多時,這將會花費很長的時間,而且一旦出錯必須從頭重啟。 ![enter image description here](http://box.kancloud.cn/2015-08-20_55d58ac39a3ed.jpg) 圖2.4: 對每一個語言進行Firefox重打包 現在,我們將整個repacks分成六個作業,放在六臺不同的機器上并行執行。這種方法將時間減少到了原來的六分之一。這也使得我們可以在個別repack失敗時重做一部分作業,而不是全部。我們可以將repacks分成更多、更小的并行的作業,但發現這將會占用太多的機器,進而影響到在持續集成系統上運行的由開發啟動的無關作業。 移動發布(Andoid)流程稍有不同,因為我們僅產生兩個安裝包:一個英語版的,一個多語言版的將一打語言一塊放進安裝包里而不是每個獨立的構建放一個。多語言版本的大小是一個問題,尤其是對移動設備的慢速下載而言。可能的一個改進是其它語言按需請求并從addons.mozilla.org取得。 在圖2.4里,可以看到語言信息依賴三個不同的源:shipped_locales,l10_changesets 和 l10n-changesets_mobile-release.json。(計劃合并成一個統一的JSON文件)這些文件包含不同本地化的信息以及某些平臺例外。特別的,對于某個給定的本地化,我們需要知道對于給定的發布使用庫的哪個修訂,以及是否它可以用于所有支持的平臺(例如,Mac上的日語來自于一個不同的庫)。Desktop發布有兩個這種文件,而移動發布有一個(此JSON文件包含平臺列表和變更集)。 誰來決定發布哪種語言呢?首先,本地化負責人自己提名特定的變更集,然后由Mozilla的本地化小組評審,顯示在一個web儀表盤里,其中列出了每種語言需要的變更集。發布協調員也會在發出“go to build”郵件前進行評審。發布的時候就可以獲取變更集列表,加入到重打包中。 除了本地化重打包以為,我們還進行合作伙伴重打包。這是為希望定制其客戶體驗的各個合作伙伴而當定制的構建。主要的變化是定制的書簽、主頁和搜索引擎,但是很多其它的事情也可以被改變。這些定制的構建是為最新的Firefox發布生成的,不適用于beta版。 ## 2.5\. 簽名 為了讓用戶肯定他們下載的Firefox是真實的來自Mozilla且未經篡改的版本,我們使用了幾種不同類型的數字簽名。 第一種簽名用于Windows版本,我們使用了Microsoft Authenticode(signcode)簽名鍵去簽署.exe和.dll文件。Windows可以使用這些簽名來驗證應用來自可信賴源。我們還用Authenticode鍵對Firefox的安裝程序進行的簽名。 接下來我們使用GPG為所有平臺上的所有版本生成一系列MD5和SHA1校驗和,為校驗和文件及所有構建和安裝程序生成分割的GPG簽名。這些簽名供鏡像網站及其它社區成員進行下載驗證。 出于安全目的,我們有一個專門的通過防火墻和VPN與外部鏈接隔離的簽名機器。Keyphrases, password和keystores通過安全通道在發布工程師間傳送,經常是親自取送,以最小化泄漏的風險。 ![enter image description here](http://box.kancloud.cn/2015-08-20_55d58ac458753.jpg) 圖2.5:簽名Firefox安裝程序 直到最近這個簽名過程還需要一個發布工程師在一個專用服務器(稱為signing master)上,用接近一個小時手工的下載構建、簽名然后回傳到 ftp.mozilla.org,然后自動化才能繼續。一旦簽名完成及所有文件上傳,一個記錄所有簽名活動的日志文件就會被上傳到 ftp.mozilla.org上候選發布的目錄。ftp.mozilla.org上該日志文件的出現說明了人工簽名的結束,從此開始,監視該日志文件的相關構建器就能繼續自動化過程了。最近,我們增加了一個簽名步驟自動化的封裝程序,現在發布工程師在signing master上打開一個Cygwin shell,設置幾個與發布有關的環境變量,象VERSION, BUILD, TAG, 和RELEASE_CONFIG,幫助腳本在ftp.mozilla.org上找到正確的目錄并取得發布內容被下載的時間以便開始簽名。在獲得簽名工具最新的生產版本之后,發布工程師只需要運行make autosign,然后輸入兩個密碼短語,一個是gpg的,另一個是signcode的。一旦這些密碼短語經過了make腳本的自動校驗,就開始了一個下載循環:監控發布自動化流程上載的構建和repacks,一旦可用就下載它們。當所有內容都被下載之后,自動化流程就立即開始簽名,無需人工干預。 無需人工干預有兩個好處。第一,減少了人工犯錯的風險。第二,使得簽名可以在非工作時間完成,無需發布工程師待在現場。 所有產物都有一個MD5SUM和SHA1SUM,這些哈希值會被寫入同名文件,然后被上傳回候選發布所在的目錄,同時也會被同步到該發布在ftp.mozilla.org上的最終位置,以便每個從某個鏡像下載Firefox安裝包的人可以確信其真實性。當所有簽名的東西都可用且經過驗證后,就與日志文件一起被傳回ftp.mozilla.org,而正在等待之中的自動化流程就可以繼續執行了。 計劃中對簽名流程的下一輪改進,是寫一個在構建/重打包的同時進行簽名的工具。這包括編寫一個簽名服務器應用來接收來自發布構建機器的簽名文件的請求,以及一個簽名客戶端工具,負責聯系簽名服務器,完成合法性認證,才能發送簽名請求、上載文件、等待構建簽名完畢然后下載并將其作為打包的構建的一部分。一旦這些增強上線,就可以放棄現有的整體式的簽名流程和整體式的生成-更新流程(后詳)了。這將會減少幾個小時的發布時間。 ## 2.6\. 更新 通過更新,用戶可以使用瀏覽器內嵌的更新功能快速的、簡單的升級到最新的Firefox版本而無需下載獨立安裝包。從用戶角度看,更新包的下載都是在后臺靜悄悄的完成的。只有當更新文件下載到本地并準備好被應用以后,Firefox才會提醒用戶應用更新并重啟。 我們生成了大量的更新。對生產線上的一系列發布,我們會生成從所有支持的老版本到最新版本的更新。對FirefoxLATEST,來說,這意味著為LATEST-1, LATEST-2, LATEST-3, … 生成各個平臺、各個語言、各個安裝包的更新。同時為幾個不同的生產線完成這些事情。 更新生成自動化修改每個發布的構建的更新配置文件,維護一個需要為哪些版本號、平臺和語言創建更新的權威列表。更新以代碼片段(snippets)的形式提供。在下面的例子里可以看到,這個小腳本不過是一個XML指針文件,位于我們的AUS上,通知用戶的Firefox瀏覽器(完整的或部分的) .mar文件的位置。 **主要更新 vs. 次要更新** ~~~ <updates> <update type="minor" version="7.0.1" extensionVersion="7.0.1" buildID="20110928134238" detailsURL="https://www.mozilla.com/en-US/firefox/7.0.1/releasenotes/"> <patch type="complete" URL="http://download.mozilla.org/?product=firefox-7.0.1-complete&os=osx&lang=en-US&force=1" hashFunction="SHA512" hashValue="7ecdbc110468b9b4627299794d793874436353dc36c80151550b08830f9d8c5afd7 940c51df9270d54e11fd99806f41368c0f88721fa17e01ea959144f473f9d" size="28680122"/> <patch type="partial" URL="http://download.mozilla.org/?product=firefox-7.0.1-partial-6.0.2&os=osx&lang=en-US&force=1" hashFunction="SHA512" hashValue="e9bb49bee862c7a8000de6508d006edf29778b5dbede4deaf3cfa05c22521fc775da126f5057621960d327615b5186b27d75a378b00981394716e93fc5cca11a" size="10469801"/> </update> </updates> ~~~ 圖2.6:更新腳本示例 由圖2.6可見,更新腳本有一個 type 屬性,取值 major 或minor。次要的更新將軟件升級到最新版本;例如將所有3.6.*的發布升級到最新的3.7發布,所有的快速發布beta用戶升級到最新的beta,所有的Nightly用戶升級到最新的Nightly版本,等等。大多數時候,更新是次要的,只需要用戶確認并重啟。 主要更新在我們需要向用戶公告最新發布上線的時候采用,提醒他們“一個新版本的Firefox發布了,你想更新嗎?”,并顯示一個廣告牌展示新版本的主要特性。我們的新快速發布系統意味著我們不再需要這么多的主要更新了;一旦3.6.*發布火車不再支持,我們將會停止產生主要更新。 **完整更新 vs. 部分更新** 構建產生完整更新.mar文件,包含新版本的所有文件,用bz2壓縮然后打包成一個.mar文件。無論是完整更新還是部分更新,都會通過用戶的Firefox注冊的更新通道自動下載。有不同的更新通道(即,發布用戶在發布通道上尋找更新,beta用戶在beta通道上尋找,等等),以便在不同的時間服務發布用戶和beta用戶(一個例子)。 部分更新.mar文件是通過比較新舊發布的完整的.mar文件產生的,只包括了有改動的文件的二進制差異,以及一個manifest文件。正如圖2.6所示,部分更新文件更小一些。這對于那些慢速或撥號Internet用戶非常重要。 在老版的更新自動化流程里,對所有語言和平臺生成部分更新花費6到7個小時,包括完整的.mar文件的下載、比較和打包。最終我們發現,許多部件變化在不同平臺上是一樣的,因此很多差異可以被復用。通過使用一個緩存差異各部分哈希值的腳本,部分更新的創建時間被縮小到40分鐘左右。 在更新文件被上傳并部署到AUS上之后,運行一個更新驗證步驟來a)測試下載該文件 b)用下載的.mar文件運行更新程序,確認更新被正確的應用了。 現在,部分更新.mar文件的生成和所有的更新文件都是在簽名完成之后進行的。這樣做的原因是,部分更新的生成依賴于兩個發布版本的簽名文件,因此更新文件的生成也必須等到簽名的構建可用。一旦我們將簽名集成到構建流程中去,我們就能夠在完成一次構建或重打包后立即生成部分更新。再加上對AUS軟件的改進,這意味著一旦我們完成了構建和重打包,就可以立即推送到鏡像。這有效的并行化了所有更新的創建,從總時間里砍掉了幾個小時。 ## 2.7\. 推送到內部鏡像和QA 驗證發布過程生成了預期的產出是非常關鍵的,這通過QA驗證和簽字過程來實現。 一旦簽名的構建可用,QA就開始手工和自動化的測試。QA依賴于散布在世界各地的社區成員、合同工和正式員工來加速此驗證過程。與此同時,我們的發布自動化產生所有受支持發布的所有語言和平臺的更新。這些更新文件通常在QA結束驗證簽名的構建之前準備好。QA接著就可以驗證用戶能夠安全的從各種老版本升級了。 從機制上看,我們的自動化流程會把二進制代碼推送到內部鏡像(Mozilla負責的服務器)上供QA來驗證更新。只有在QA完成驗證之后,才會推送到社區鏡像上。這些社區鏡像對于滿足全球范圍的用戶流量是必須的,這些用戶可以從本地鏡像節點下載更新,而不是直接請求ftp.mozilla.org。值得指出的是,我們在QA簽名之后才會將構建包和更新包放到社區鏡像上,因為一旦QA在最后時刻發現了嚴重問題,候選構建必須被撤回。 構建和更新可用后的驗證過如下: * QA與其它時區的社區和合同工一起,進行手工測試 * QA觸發自動化系統運行功能測試 * QA獨立的驗證修改了的問題和新特性已經達到了可以交付給用戶的足夠好的質量 * 同時,發布自動化生成更新 * QA簽字確認構建通過 * QA簽字確認更新通過 注意用戶在QA簽字確認以及發布協調員發出上線構建和更新的郵件之前是不會得到更新的。 ## 2.8\. 推送到公共鏡像和AUS上 一旦發布協調員從QA和Mozilla其他各團隊拿到了簽字確認,就會通知發布工程師將文件推送到社區鏡像網絡上,處理接下來幾天內高達幾億用戶的更新下載請求。此時,所有的安裝包以及所有平臺和語言的完整或部分更新已經在內部鏡像網絡上了。推送文件到外部鏡像涉及到為外部鏡像模塊修改一個rsync exclude文件,此修改導致鏡像開始同步新發布的文件。每個鏡像都有一個分值或者權重;我們監視哪個鏡像已經完成了同步并加總各單獨的分值計算出一個總的uptake分值。一旦達到某個uptake閾值,我們就會通知發布協調員鏡像已經有了足夠的uptake處理發布了。 此時這個發布就可以公開了。發布協調員會發送最終的“go live”郵件,而發布工程師會更新web服務器上的鏈接,這樣web和ftp站點的來訪用戶就可以發現最新的版本了,同時還會在AUS上公布Firefox老版本所需的更新文件。 用戶機器上的Firefox會定期的檢查AUS服務器看是否有了更新版本。一旦我們發布了更新文件,用戶就可以自動的升級到最新版本。 ## 2.9\. 教訓 作為軟件工程師,總是會情不自禁的解決自己認為緊迫和明顯的技術問題。然而,發布工程師的工作范圍更寬——既有技術的也有非技術的——因此理解技術和非技術問題都很重要。 **獲得其它干系人認可的重要性** 確保所有干系人理解緩慢的、脆弱的發布工程會使組織和用戶面臨風險是十分重要的。這牽涉到組織的各個級別都承認緩慢脆弱的自動化帶來喪失的商業機會和市場風險。而且,Mozilla采用超級快的發布周轉來保護用戶的能力隨著更多的用戶到來將會變得愈加重要,而這反過來使我們更具吸引力。 有意思的是,有些人在他們的職業生涯中只見過脆弱的發布自動化,所以會帶著“啊,就是這么糟糕”的期望來到Mozilla。將一個魯棒的、可擴展的發布自動化流程能帶來的潛在商業收益解釋給大家,有助于幫助每個人理解現在還不可見但即將展開的發布過程改進工作。 **讓其他團隊也參加進來** 為了使發布過程更有效、更可靠,需要發布工程及Mozilla的其他團隊共同做很多事情。然而,有意思的一點是看到人們經常把“需要很長時間交付一個發布”誤讀成“需要發布工程團隊很長時間交付一個發布”。這個誤解忽略了發布過程團隊之外的其他團隊完成的發布相關的工作,使發布工程師感覺很受傷。消除這個誤解需要讓Mozilla全體人員明白一次發布的時間都花在了不同團隊的那些環節。我們使用了非常低技術方式:跨團隊交割郵件清晰的記錄了各個時間點,blog里詳細的記錄了時間花在了哪里。 * 這有助于理解哪些不同的團隊牽涉在一個發布里 * 這有助于人們贊賞發布工程師的改進,這反過來促進了發布工程師做更多的改進 * 這有助于其他團隊思考他們怎樣做也能幫助改進整體的發布流程——這對整個組織來說是一個很大的思維方式上的轉變。 * 最后,這也消除了團隊之間所有不清楚的交割溝通,這在歷史上造成了許多反復、錯誤的開始,及其它代價巨大的中斷。 **建立清晰的交割** 許多發布工程問題實際上是人的問題:團隊之間的錯誤溝通;缺乏清晰的領導力;以及由此導致的在chemspill發布中的壓力、疲憊和焦慮。通過定義清晰的交割來消除這些人的溝通問題,我們的發布馬上變得更加平順了,跨團隊的交互很快得到了改善。 **管理(人員)周轉** 當開始這個項目的時候,人員流失非常頻繁。這就事情本身而言就夠糟糕的了。然而,更糟糕的是,缺乏準確的最新的文檔意味著絕大多數對發布流程的技術理解是口口相傳的,當人員離開時就丟失了。我們必須盡快改變這種狀況。 我們感覺提振士氣、顯示事情正在好轉最好的辦法就是確保人們看到我們有一個計劃去改善現狀,而人們能掌握自己的命運。我們做到這一點的方式是確保每次發布以后安排時間改進至少一件事情——任何事情!我們要到了發布后1-2天的不受打擾時間。解決最急迫的小問題,此時這些問題在人們的腦袋里還很清晰,也不會被其他事情分心,其他更大的長遠的問題留在以后的發布中解決。更重要的是,這給人們一種感覺,就是我們重新掌握了自己的命運,事情正在好轉。 **管理變化** 在我們正在做改進使,由于市場壓力,Mozilla發布流程的業務和產品需求變了。這并不是什么罕見的事情,我們應該預料到。 我們知道在開發新流程的同時,必須得繼續用老的發布流程交付發布。我們決定抵制住建立一個全新的項目同時支持現有系統的誘惑;我們覺得現有系統太脆弱了,以至于根本沒有時間去做任何新的事情。 我們從開始就假定我們沒有完全了解什么出錯了。通過每個增量式的改進,我們得以在下一次改進之前回顧和發現新的驚訝。貫穿整個項目,每當我們發現新的驚訝時,類似“排干沼澤地”、“剝洋蔥”、“以前竟然是這么做的”的話就不絕于耳。 基于此,我們決定對現有流程做多個小的、持續的改進。每個迭代改進使得下一個發布好一點。更重要的是,每個改進可以釋放更多一點時間,發布工程師用來做下一次改進。這些改進象滾雪球一樣,直到我們發現已經超過了臨界點,可以做更加重大的改進了。此時,發布優化帶來的收益就真正兌現了。 ## 2.10\. 更多信息 對迄今為止所完成的工作,以及它在新的白熱化的全球瀏覽器市場背景下帶給Mozilla的競爭力,我們由衷的自豪。 4年以前,一個月內完成兩次chemspill發布在Mozilla值得稱道。相比之下,上周公布的一個利用第三方庫缺陷的安全漏洞導致了Mozilla在2天之內交付了8個chemspills發布。 同任何事物一樣,我們的發布自動化仍然有足夠的改進空間,需求一直在變化。要了解我們正在進行的工作,參見: * [Chris AtLee的博客](http://atlee.ca/blog) * [Lukas Blakk的博客](http://lukasblakk.com/) * [John O'Duinn的博客](http://oduinn.com/) * [Armen Zambrano Gasparnian's的博客](http://armenzg.blogspot.com/) * 有關基于Mercurial的發布流程的設計和過程的[文檔](https://wiki.mozilla.org/Release%3aRelease_Automation_on_Mercurial%3aDocumentation) * Release Engineering的[構建庫](http://hg.mozilla.org/build)。特別的,buildbotcustom,buildbot-configs,以及工具庫都在發布中大量的使用。 * [Firefox 7.0 Beta 4 Build Notes](https://wiki.mozilla.org/Releases/Firefox_7.0b4/BuildNotes). 除了代碼,我們還記錄了一個發布的各個層面。此鏈接指向我們的7.0b4 release notes,但是通過編輯URL你可以找到所有release notes。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看