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

誕生之初

事情還得從頭開始說起，從那些自動化的fabric文件開始，也從我剛入職搜狐負責手機搜狐開發開始說起。我參與開發的時候項目的部署已經是自動化了，不過并沒有抽象出一個工具來。那會兒主要由兩個項目，一個基于tornado，一個基于Django。兩個項目都有各自的發版方法，但邏輯基本一致。

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

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

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

開始造輪子

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

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

有了上面的經驗，只要把必需的東西輸出就行了。總結了一下，當時項目的打包和上線涉及到這幾個方面：:

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

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

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

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

爭論之處

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

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

代碼結構的爭論還好些，基于經驗就能看出哪種更好。但是一些邏輯的設計卻不是經驗能得到的，就像軟件開發沒有銀彈一樣，各自的業務場景都不同，沒有統一的解決方案。

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

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

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

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

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

開放的初衷

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

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

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

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

補充一些數據

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

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