作者丨 Hrishikesh Barua
譯者丨劉志勇
不久前有篇關(guān)于縮短 Facebook 發(fā)布流程的文章，闡述了將代碼投入生產(chǎn)的靈活方法。這篇文章著重講述了他們?cè)谝荒曛畠?nèi)如何從“ cherry-picking ”升級(jí)到“ push-from-master ”策略。早些時(shí)候， Facebook 也分享了他們部署過程的細(xì)節(jié)。作者 Chuck Rossi 是 Facebook 的首位發(fā)布工程師，目前是 Facebook 發(fā)布工程的工程總監(jiān)。
Facebook 的發(fā)布周期是“ quasi-continuous ” （準(zhǔn)連續(xù)）——這只是一種委婉的說法，表明并非每次提交都會(huì)部署到生產(chǎn)環(huán)境，實(shí)際上它采用的是對(duì)幾十到幾百個(gè)提交進(jìn)行批處理，每隔幾個(gè)小時(shí)就進(jìn)行推送。這種分層發(fā)布的方式使任何變更的回滾很容易。
這個(gè)新系統(tǒng)從 2016 年 4 月開始，經(jīng)過一年的時(shí)間慢慢地完善。早先的模式是從主干分支的提交中選擇特定的變更放到發(fā)布分支上。發(fā)布分支每天將這些變更推送到生產(chǎn)環(huán)境。這種“ cherry-picking ”的特點(diǎn)是，每天選擇變更的數(shù)量為 500 ~ 1000。剩下的變更就推入到每周發(fā)布分支中。隨著時(shí)間的推移，提交的數(shù)量和參與其中的工程師都有所增加，發(fā)布工程師的手工勞動(dòng)變得過多，以至于無法持續(xù)。
這個(gè) CD 系統(tǒng)的關(guān)鍵組件是一種控制方法，即誰將接收變更，以及用于部署和測(cè)量的自動(dòng)化工具。在第一步中，經(jīng)過一系列自動(dòng)化測(cè)試后，變更就從內(nèi)部推送到 Facebook 員工。在這一階段發(fā)現(xiàn)的任何回歸，都會(huì)被認(rèn)為這一進(jìn)程受阻或者停止。下一步涉及到“ canary deployment ”（金絲雀部署），只推送至生產(chǎn)環(huán)境的 2% 。依靠連續(xù)的監(jiān)測(cè)來檢測(cè)問題。如果一切順利，這些變更將 100% 部署到生產(chǎn)環(huán)境中。名為 Flytrap 的工具收集用戶報(bào)告，并發(fā)送任何異常情況的告警。
圖片來自：
https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale
Facebook 中的 Web 和移動(dòng)產(chǎn)品遵循兩條不同的路徑，原生移動(dòng)變更的部署頻率低于 Web 。這兩個(gè)都由名為 Gatekeeper 的系統(tǒng)控制。除此之外，Gatekeeper 還分離出了部署和發(fā)布。這種分離帶來了挑戰(zhàn)，包括維護(hù)向下兼容性。
由于工具和部署選項(xiàng)的性質(zhì)，移動(dòng)持續(xù)部署面臨著一些特定的挑戰(zhàn)。Web 部署則更為容易，因?yàn)?Facebook 擁有完整的技術(shù)棧和工具。為了解決這些挑戰(zhàn)，F(xiàn)acebook 已經(jīng)構(gòu)建了一些專注于更快的移動(dòng)開發(fā)的工具和庫(kù)，包括 Buck、Phabricator、 Infer、 React 以及 Nuclide 。Facebook 的移動(dòng)部署是以三層來并發(fā)運(yùn)行。
構(gòu)建：合并到移動(dòng)主分支上的所有代碼都會(huì)進(jìn)行構(gòu)建，這會(huì)針對(duì)受影響的所有產(chǎn)品（Instagram、Messenger）并且會(huì)跨各種芯片架構(gòu)。
靜態(tài)代碼分析：Linters 和靜態(tài)分析工具的組合，稱為 Infer ，用于檢查各種問題，包括資源泄漏、未使用的變量、有風(fēng)險(xiǎn)的系統(tǒng)調(diào)用和編碼準(zhǔn)則違規(guī)。
自動(dòng)測(cè)試：包括單元、集成和端到端測(cè)試，會(huì)使用到 Roboelectric、XCTest、JUnit 和 WebDriver 等工具。
在代碼變更的生命周期內(nèi)，每次提交都會(huì)執(zhí)行移動(dòng)構(gòu)建并運(yùn)行測(cè)試棧，這樣就會(huì)運(yùn)行很多次。單單 Android 一天就有 5 萬到 6 萬個(gè)構(gòu)建版本。移動(dòng)部署系統(tǒng)遵循較早的基于 Web 的模式，每周發(fā)布一次，按 cherry-picking 策略隨機(jī)選擇變更。盡管代碼傳輸速度和發(fā)布頻率有所增長(zhǎng)，但工程師的生產(chǎn)率保持不變。然而，本文提到的標(biāo)準(zhǔn)（代碼行和推送次數(shù)），可能并非衡量生產(chǎn)率的最佳標(biāo)準(zhǔn)。
據(jù) 2016 年 IEEE 的論文和相關(guān)討論，F(xiàn)acebook 早在 2005 年就利用了某種形式的 CD。該論文中的一些結(jié)論列出了 CD 成功的先決條件：可觀的持續(xù)投資、高度熟練的開發(fā)人員、強(qiáng)大的技術(shù)管理，開放和平等的文化，風(fēng)險(xiǎn)回報(bào)權(quán)衡管理、客觀回顧失敗以及有專注力的小團(tuán)隊(duì)。
Facebook 的準(zhǔn)連續(xù)部署系統(tǒng)具備這幾個(gè)優(yōu)點(diǎn)：沒有推送熱補(bǔ)丁的手工開銷，對(duì)分布式工程師團(tuán)隊(duì)有更好的支持，為工程師提供了更快的反饋循環(huán)。
本文翻譯已獲授權(quán)，原文鏈接：
http://www.infoq.com/news/2017/09/facebook-release-scale
京公網(wǎng)安備 11010502049343號(hào)