如何基於Docker和Jenkins打造?向初創公司的持續集成體系

談到持續集成，?家可能?先想到的是「?動化測試」。但事實上，我個?認為從DevOps的?度來說持續集成會有包含到整個研發?命周期中可以被?動化的????。

如圖所示，除了可以根據?例來跑?動化測試並輸出對應的測試報告以外。 包括諸如：基於源代碼來進?鏡像構建、使?靜態代碼分析器針對代碼風格以及潛在的 隱患點（?如： N+1查詢、SQL注?風險點）進??盒檢查都是持續集成所能夠帶來的價值。

在?案的具體選型上，之前我們也嘗試過?些必源的商業?案——?如teamcity， 但是發現因為?態系統完備性的問題 其實會有蠻多?較?的坑，需要??造??堆輪?。所以，我們最後綜合考慮選?了?態圈最為完備的開源CI系統——Jenkins。

為什麼我們覺得每個初創公司都會需要?套基於Docker和Jenkins實現的持續集成系統？

● ● ●

?先，從持續集成的?度來看?動化是最?的優勢所在。根據我之前的經驗，在技術團隊內部進?佈道推?測試驅動開發code review統?的代碼風格約定等最佳實踐的時候，所遇到的最?障礙是?。因為?會有天?的惰性。?如「哥們，我這個 hotfix現在急著merge到?產環境，變數命名不符合規範的問題 回頭再改。你先幫我把 code review 通過來吧」或者「就改了2?代碼，沒必要在跑單元測試，直接提pr得了」 諸如此類等等。 然後，我個?覺得解決這?系列問題的最好?案是通過機器???， 達成對於遵守規範的強約束。

然後，之所以考慮將jenkins本?以及jenkins具體的構建節點，都基於docker來進?運?。?先，毫?疑問是考慮到了部署上的簡易性。??命令，如絲般順滑。另???，對於處在快速成長期的初創公司來說?論是團隊成員或者業務線成倍的快速擴充 都是?件?常習以為常的事情。基於docker實現的整個ci架構，有助於按需快速簡便的伸縮節點數量。

整個持續交付體系在逐?X團隊內部的實踐情況

● ● ●

逐鹿X的整個研發團隊目前有11個?，完整的?產環境由5個docker容器組成。代碼託管在github的私有倉庫上，使?標準的git flow來做分?管理。 同時採用了諸如 結對編程、Code Review、TDD(測試驅動開發)、靜態代碼檢查 等等一系列最佳實踐。

完整的workflow如上圖所?。

?先，RD 同學會在??的 feature 分?中完成業務開發，然後提 PR 申請 merge 到開發分?。此時，Jenkins 會開始跑相關的?動化測試?例，同時使?靜態代碼分析器進?代碼風格檢查以及?盒安全測試。

隨後我們會指定一名同學進行 Code Review，並且通過 Jenkins 會?動在開發環境的聯調機上執?部署。 不過考慮到從 feature 分支 merge 到 develop 分支 是?件?常?頻的事情，所以出於速度上的考量——我們基於shell腳本??docker鏡像進?部署。

?當此?迭代中的所有功能全部完成開發，並且通過 RD ?測後。我們會將開發分?的代碼 merge 到 release 分?。此時 Jenkins 則會開始構建對應的 Docker 鏡像，並且部署於 Staging 環境。

?個流程中?關重要的?些細節

● ● ●

?先，將整個?作流和團隊的IM?具打通是確保整個?案順利實施的關鍵節點。 只有當團隊中的所有成員，能夠在第?時間獲悉CI當前的構建狀態。才能確保整個流程順暢?阻的執?下去。 對於使?slack作為團隊im?具的同學，jenkins中有slack相關的插件可以滿?你們的需求。然後，如果有同學是使?釘釘作為團隊im?具的話，那麼也告訴?家?個好消息。我們已經開發了1個jenkins的釘釘通知插件，將在內部基本使?穩定後開源放出，?概是 在半個?以後。

再然後，有1個可能?常容易被忽略的點是——當通過ci?動化部署測試環境的時候。最好，同時?shell腳本將?產環境的數據脫敏後導?到測試環境。這樣可以使得，很多因為臟數據導致的問題在測試環境中提前得到暴露。

還有就是，?定?定要記得盡量把整個持續集成環境部署在海外。我們?前采? 的是青雲?港機房的伺服器，不然?論是拉docker鏡像還是跑npm或者github拉代碼 都會慢到你想哭。 穿越長城，才能?向世界。

推薦閱讀：