Quora是如何做持續(xù)部署的？工程師如是說

在2013年4月25日中午12點(diǎn)到晚上11點(diǎn)59分之間，Quora站點(diǎn)發(fā)布了46次新版本。這對于我們來說只是普通的一天。我們執(zhí)行非常快的持續(xù)部署周期，代碼變動提交后就直接推送到線上。這使得我們可以在各個層面上實(shí)現(xiàn)平行化開發(fā)。我們希望推送系統(tǒng)足夠快，讓開發(fā)者盡快看到他們對生產(chǎn)環(huán)境的改動（目前生產(chǎn)環(huán)境修訂版上線平均要6、7分鐘），同時也要注意可靠性和靈活性，讓我們可以迅速響應(yīng)問題。

對開發(fā)者而言，只需要一個簡單的命令把代碼推送到到生產(chǎn)環(huán)境：git push

這背后發(fā)生的事情要復(fù)雜很多。每當(dāng)一個開發(fā)者把提交推送到我們的主git倉庫，一個post-receive鉤子會將最新的修訂版加入到發(fā)版申請列表，并記錄到MySQL數(shù)據(jù)庫。（post-receive鉤子也會把提交加到Phabricator，我們用它做代碼評審。更多關(guān)于我們代碼評審的相關(guān)信息參閱這個回答Does Quora engineering use a code review process?）一個內(nèi)部監(jiān)控網(wǎng)站展示每個等待發(fā)布的修訂版的狀態(tài)。

一個后端服務(wù)監(jiān)控發(fā)版申請列表，每當(dāng)提交新的修訂版，服務(wù)收集此版本代碼庫中所有單元測試的名字。我們有上百個測試模塊和上千個獨(dú)立的測試，服務(wù)會將測試分配到一些worker機(jī)器中并行處理。當(dāng)worker運(yùn)行完測試，它們將結(jié)果返回給測試服務(wù)，服務(wù)在發(fā)版申請的列表中標(biāo)記修訂版的綜合結(jié)果（成功或失敗，以及多少個測試失敗了和失敗的詳情）。

同時，另一個服務(wù)監(jiān)控發(fā)版申請列表，等待打包新修訂版。每當(dāng)提交新的修訂版，它將所有需要運(yùn)行在我們服務(wù)器上的代碼進(jìn)行歸檔，并打包上傳到Amazon S3。

當(dāng)修訂版打包好后，一個集成測試服務(wù)將修訂版推送到一臺單獨(dú)的機(jī)器（并不是生產(chǎn)環(huán)境），用新的包開啟web服務(wù)，并向服務(wù)發(fā)送請求。只有每個請求返回200狀態(tài)碼，集成測試才算通過，如果任何請求返回4xx或5xx錯誤碼，測試失敗。

最后，第四個監(jiān)控發(fā)版申請列表的服務(wù)由其他三個服務(wù)調(diào)用，當(dāng)修訂版的測試和打包沒有問題，服務(wù)向S3上傳一個包含版本號的小型元數(shù)據(jù)文件，來標(biāo)記修訂版的部署（發(fā)布）。Web服務(wù)器和其他使用相同代碼的機(jī)器會周期性檢查元數(shù)據(jù)文件中的版本號，如果有變化，它們會立刻從S3上下載最新的包。下載并解壓包大概需要一分鐘，然后運(yùn)行新的代碼只需要幾秒。每臺需要代碼的機(jī)器會獨(dú)立完成上述操作。我們將這個系統(tǒng)命名為Zerg，因?yàn)樵谒行枰臋C(jī)器上進(jìn)行部署過程很像蟲族（zerg）的rush戰(zhàn)術(shù)。

下圖描述了后端架構(gòu)：

這套系統(tǒng)彈性很大，很少出現(xiàn)失敗，但正如其他復(fù)雜的系統(tǒng)一樣，也會出現(xiàn)失敗情況。要么測試worker宕機(jī)，要么測試服務(wù)失敗，要么打包程序出現(xiàn)問題。通過這種架構(gòu)，內(nèi)部的失敗并不會引起一致性問題（比如把未通過單元測試的代碼推送到生產(chǎn)環(huán)境），并且大多數(shù)時候只需要重啟失敗的機(jī)器或服務(wù)便可以讓其正常工作。

對于大多數(shù)修訂版，git push到發(fā)布大約間隔6分鐘，這取決于其中執(zhí)行時間最長的任務(wù)。目前，單元測試是時間最長的任務(wù)；打包需要2-3分鐘，集成測試需要3分鐘多一點(diǎn)。之后10分鐘（發(fā)布之后），機(jī)器下載運(yùn)行新代碼，同時后面的修訂版開始測試和打包。（我們不會同一時間更新所有機(jī)器，這會導(dǎo)致每次我們發(fā)布時，Quora會有幾分鐘處于不可用狀態(tài)?。┻x擇10分鐘的間隔是為了可靠性——如果我們需要響應(yīng)突發(fā)事件，可以立刻覆蓋部署代碼。

我認(rèn)為6分鐘的測試+10分鐘的部署還不夠好。我們可以改進(jìn)測試系統(tǒng)，使其并行測試來提高效率。另外，我們?nèi)コ羝渌?wù)中無用的東西，這讓我們可以將部署時間由10分鐘縮短為5分鐘。

系統(tǒng)的設(shè)計主要基于其他公司部署項(xiàng)目時遇到的問題。我們在公司早期就決定采用持續(xù)部署方案。在公司規(guī)模、代碼庫、基礎(chǔ)架構(gòu)很小時便于使用這種方案，但我們?nèi)耘Χ嗄陙砭S護(hù)這一流程，因?yàn)槌掷m(xù)部署在整個開發(fā)流程和開發(fā)文化中舉足輕重：

·持續(xù)部署讓我們盡可能迅速地將產(chǎn)品的變更展現(xiàn)在用戶面前，包括從bug的修復(fù)到主要特性等一系列東西。

·持續(xù)部署讓我們盡可能迅速隔離并解決出現(xiàn)的問題。當(dāng)出現(xiàn)bug，你傾向于在單個提交中debug，還是從包含一百個提交的整體發(fā)版中debug？

·持續(xù)部署讓我們在改進(jìn)網(wǎng)站時不需要投入過多精力。我們直到經(jīng)歷了這些之后才意識到這點(diǎn)——持續(xù)部署讓我們在幾分鐘之內(nèi)完成發(fā)現(xiàn)問題、快速修復(fù)、推送代碼并部署到生產(chǎn)環(huán)境。如果這些動作時間過長，開發(fā)者可能會想“我難道要花一個小時來坐下跟蹤代碼的推送嗎？”。更糟糕的是，如果隔天部署，開發(fā)者會想“我難道要明天再審查一遍然后測試代碼嗎”

·持續(xù)部署減少了跟蹤不同發(fā)布狀態(tài)的多個版本這一工作上的投入。代碼是在生產(chǎn)環(huán)境還是在發(fā)版列表的未推送狀態(tài)，都一目了然。

·持續(xù)部署讓我們有測試的習(xí)慣。毫無疑問，測試非常重要。伴隨著變更需要立刻上線的壓力，我們沒有之后再寫測試的余地。我們總是先寫好測試。

·持續(xù)部署很有趣！寫代碼很有趣，我們的部署過程也應(yīng)該同樣有趣。

通過減少每次版本上線需要的時間，并加強(qiáng)測試，我們每天可以上線更多的修訂版，并有效減小變更伴隨的阻礙。這也是Quora這類快速起步的公司需要的東西。

編譯：伯樂在線 - 孫騰浩