今天主要介紹下我們組剛剛開源出來的一個自動化部署的工具 essay ，功能在readme上已經(jīng)介紹的很詳細了，這篇文章只是介紹下外圍的情況，產(chǎn)生的環(huán)境，一些決策的考慮。

誕生之初

事情還得從頭開始說起，從那些自動化的fabric文件開始，也從我剛?cè)肼毸押撠?zé)手機搜狐開發(fā)開始說起。我參與開發(fā)的時候項目的部署已經(jīng)是自動化了，不過并沒有抽象出一個工具來。那會兒主要由兩個項目，一個基于tornado，一個基于Django。兩個項目都有各自的發(fā)版方法，但邏輯基本一致。

兩個項目的上線流程都是先打包（py的源碼包），然后在通過內(nèi)部的pypiserver安裝到各個服務(wù)器上，由supervisord啟動、管理。

隨著業(yè)務(wù)的發(fā)展，新的項目逐漸多了起來。這時一個新的項目開發(fā)流程是這樣的：先從就項目中把fabfile（fabric的配置文件）和supervisord配置文件以及setup.py文件拷貝過來，然后再往里面填源碼。流程依然是一致的。

這就是一開始的狀態(tài)，混沌中帶著那么一點秩序。

開始造輪子

說起來，程序員都是十足的懶人。這樣copy的方式多少讓自己都有點不忍直視，于是 @熊總 建議我們不如造這樣一個輪子，讓所有的項目都能在這上面滾起來。于是把這個造輪子的任務(wù)交給我來做，剛好我也是懶人一個，于是很happy的開始了。

要造一個通用的輪子，必然是要把項目中用到的部分抽象出來，哪些部分是通用的呢，這只有深切參與到項目的開發(fā)和部署中才能體會得到。剛好在那段時間之前，我也參與了修改bug，打包，部署上線的過程，包括copy那些打包的腳本和配置文件。

有了上面的經(jīng)驗，只要把必需的東西輸出就行了?？偨Y(jié)了一下，當(dāng)時項目的打包和上線涉及到這幾個方面：:

1. 打包 —— 生成版本號，渲染setup中的版本和項目信息，然后放到pypi server的packages目錄下
2. 虛擬環(huán)境 —— 在新的服務(wù)器上創(chuàng)建虛擬環(huán)境
3. 安裝項目 —— 從pypiserver安裝項目到虛擬環(huán)境中
4. 啟動supervisord —— 管理項目進程
5. 切換nginx配置 —— 我們有兩套環(huán)境在線上同時運行，可以稱為a環(huán)境和b環(huán)境，主要用于上線以及線上突然出現(xiàn)問題時回滾

細分的話就上面五個步驟，不太理解的可以去看看我們的essay說明。也就是只要滿足了這些功能，那么這輪子就算是完成了。另外還考慮到為了便于新項目的開發(fā)，還需要能自動創(chuàng)建具備這些功能的項目模板。這其實是最主要的痛點，總是拷貝什么的最沒技術(shù)含量了。

于是添加了創(chuàng)建項目并且初始化模板，然后還能初始化到gitlab或者github上。

這樣的工具儼然是項目開發(fā)部署、居家旅行之良品。

爭論之處

需求明確之后，怎么組織項目的代碼呢，對于正常的web項目來說，沒有啥難度的，都有固定的模板。對于這個工具類的東西，還是***次考慮，怎么設(shè)計才能更合理——易擴展、易維護。在翻了好久django的源代碼之后，我開始按照一個core，然后一些tools的思路開始碼代碼。

我的考慮是，這個工具應(yīng)該有一個核心的功能，然后是周圍的一些輔助工具。遺憾的是，這種思路***還是被推翻了。熊總的意思是應(yīng)該參考linux的pipeline來設(shè)計，所有的功能都應(yīng)能單獨拿出來。于是底層的工具模塊都按照這個邏輯被他重寫了（so，如果你們覺得那部分代碼有槽點盡管吐好了，我不介意的，^_^)。

代碼結(jié)構(gòu)的爭論還好些，基于經(jīng)驗就能看出哪種更好。但是一些邏輯的設(shè)計卻不是經(jīng)驗?zāi)艿玫降?，就像軟件開發(fā)沒有銀彈一樣，各自的業(yè)務(wù)場景都不同，沒有統(tǒng)一的解決方案。

另外一個爭執(zhí)的點是部署方式。如果你已經(jīng)看了我們的文檔，或者已經(jīng)理解了上面的部署方式。你可能已經(jīng)疑惑了：“為毛你們不直接用git部署呢?還可以打tag什么的。” 這也是我們之前在考慮的問題。

擺在我們面前的有兩條路，一條路是用git來部署代碼，另外一條路是用pip install項目包來部署。我們選擇了后者。原因是這樣的：

1. 歷史原因 —— 之前的項目一直在用這樣的方式

2. 服務(wù)器配置的成本 —— 這個我覺得是最主要的，對比兩種方式，git部署的話服務(wù)器要統(tǒng)一安裝git環(huán)境，但是我們申請到新的服務(wù)器沒有這東西，我們得自己安裝；另外還有一個包依賴的問題。而使用pip的方式安裝，不需要做多余的處理，新來機器，給了ip，直接就能部署上去。

大概就基于上述的兩個原因，選擇了用pip install的方式來部署了。有什么沒說到得地方，有同事路過留言補充下吧。

開放的初衷

有了上面的過程，也就產(chǎn)生了這么個工具： essay 。在項目完成之后，后面的時間里我們劃分了不同的組，又開始負責(zé)新的項目。這個工具算是一直在我們的項目開發(fā)中起著重要的作用。我們覺得這個工具算是我們在過去一年多中開發(fā)和部署經(jīng)驗的總結(jié)，開放出來應(yīng)該會有些價值，無論是對于開發(fā)者還是對于團隊。

我自己是在這個工具的開發(fā)過程中學(xué)到很多東西，我想任何一個渴望了解項目從開發(fā)到部署整個流程的開發(fā)人員都應(yīng)該能從中有所收益。

開放的目的除了分享經(jīng)驗，還有一個重要的作用就是交流。我們所積累的經(jīng)驗在業(yè)內(nèi)并不一定是***的，肯定還有更多更好的解決方案，而這些東西都要來源于交流。這樣才能相互促進，而相互促進才是開放和開源的初衷。

項目地址：https://github.com/SohuTech/essay

補充一些數(shù)據(jù)

手機搜狐網(wǎng)（m.sohu.com)每天有幾億的PV，在這樣的情況下，發(fā)現(xiàn)線上bug，一般情況下從修復(fù)bug到上線不會超過15分鐘。并且在上線的時候用戶是不會感覺到頁面訪問慢或者打不開的。在新功能點或者bug多的情況下，一天上線十幾個版本的情況也是有的。每次上線都不會對用戶造成影響的關(guān)鍵在于我們部署了a，b兩套環(huán)境。

之前在我參與手機搜狐網(wǎng)開發(fā)時后臺有100多臺虛機，在遇到熱點事件的時候會擴充一倍。在這種情況下，新功能上線的過程我印象中不會超過5分鐘，如果關(guān)閉fabric的success的console輸出以及開啟并行模式，發(fā)布的速度會更快。