<b>摘要：</b>随着持續內建技術的不斷成熟，各種持續內建相關的開源和商用軟體層出不窮，但是對于中小型企業的技術團隊而言，往往在進行持續內建實踐時會陷入工具之間的拉鋸戰。那麼，對于中小團隊而言，如何才能實作高效靈活的持續內建方案？2017蘇州雲栖大會雲效專場上，南京路特CTO、阿裡雲MVP戚俊結合實踐經驗為大家分享了中小團隊持續內建之路。
<b>以下内容根據演講視訊以及PPT整理而成。</b>
雖然持續內建的概念已經火了很長時間了，但是因為各個企業的規模以及業務類型都不同，是以在持續內建中遇到的問題也各不相同。本次将結合南京路特的實踐經驗為大家分享中小團隊的持續內建之路。本次的分享主要圍繞着困境、靈活開發、工具鍊、架構和收獲這5個方面闡述路特自己所走過的持續內建之路。
<b>困境</b>
對于南京路特而言，在沒有和阿裡的雲效平台結合之前所遇到的最為核心的3個問題就是成本問題、管理問題和效率問題。
将這3個問題更加細化拆分之後就是如下圖所示的狀态，如果大家也處于中小型團隊之中可能也會遇到這些問題。
<b>人力問題。</b>首先，在中小型企業中，技術管理者會有很強烈的想法讓專門的人來處理代碼合并以及審查等工作，因為經常會出現因為某次釋出沒有做好代碼審查導緻出現故障的情況。我們希望在持續內建開始的道路之前就有專門的人來解決代碼審查和合并問題。
<b>資金問題。</b>做持續內建将會面臨一大堆的工具鍊的建構問題，這些工具部署完成之後是會帶來成本的，首先是軟硬體成本，因為無論是購買雲伺服器還是在本地搭建實體機來運作應用，都是會産生成本的。随之而來還會産生運維成本，因為隻要是軟體産品都是會出問題的，出現問題時需要人工解決，而人工最終也會轉變成資金成本。
時間問題。為什麼說在持續內建道路上一定會遇到時間問題呢？簡單而言，使用一堆工具建構持續內建的工具鍊，最終實踐的時候就會發現工具鍊會天天出問題，也可能是方法論思考的不是很透徹，而這些事情是不可能在做架構之前全部都預料到的。而一旦出現這些問題就需要拿出時間解決問題，這就會造成時間成本的上升。
<b>效率問題。</b>路特曾經遇到過一個問題就是在需要釋出版本的時候，從開發、運維到測試，都非常希望整個公司的所有人都在場。出現這樣的顧慮是因為過去在釋出時所設計到的面非常廣泛，會涉及到測試、打包、釋出以及線上環境的替換等工作，如果這個過程一切順利，隻需要測試和運維這兩個崗位配合就可以了，但是事實上卻會遇到一些問題，比如開發人員在開發時使用了本地定制化的工具，而伺服器上沒有這個工具，而測試人員在本地進行測試時也忽略了這個問題，一旦釋出到正式線上就會出現Bug，這時候釋出失敗就需要進行復原。而如何處理這個Bug則需要決策者參與，需要決策者來判斷是這個修複這個Bug的緊要程度。而如果需要現場修複Bug時也需要開發人員在現場解決緊急的問題。這樣就從兩個人的崗位變成了四個人的崗位，是以持續內建如果做不好帶來的最大問題就是效率的下降。
<b>管理問題。</b>對于中小企業而言，往往沒有專人負責管理問題。往往是新員工在HR那裡辦完手續入職之後，到部門主管那裡用郵箱開通一系列工具的賬号。如果企業擁有SSO，那麼可以将這一系列工具串聯起來使用一個賬号，但是大部分中小型企業卻不會自己搭建一個SSO門戶管理整個企業内部的賬号問題。另外一個問題就是代碼權限，SSO解決的是賬号一體化登入的問題，卻無法解決代碼權限問題。而這就造成需要一個權限非常高的人員每天守在電腦邊為團隊成員管理代碼權限，而如果不管理權限，給每個人都是最高權限更會出現不可預測的問題。
<b>平衡：靈活開發與持續內建</b>
在做持續內建的時候所需要面對的第一個問題就是如何協調靈活開發與持續內建的關系。首先的一個問題就是需求及Bug如何盡快進入開發流程。路特是一家服務于媒體大資料的B2B公司，主要提供SaaS服務，是以需求的來源非常廣泛，同時Bug來源也非常廣泛，不光是測試人員會發現Bug，使用者也會發現很多Bug，很多的需求和Bug都可能會來源于終端使用者。而終端使用者提出的問題要麼是通過APP内部的問題回報收集到的工單，要麼就是直接打電話過來投訴。當問題回報已經收集到了，如何将其盡快進入到流程中呢？路特在沒有使用雲效平台之前有自己的一套類OA系統來解決問題，将公司内部的Bug工單和需求都做了歸類彙總，處理完成之後導入到JIRA裡面去。當接入到雲效之後，這件事情可以在雲效平台裡面建立需求和Bug并形成看闆，之後再實作。
第二個問題就是開發成果如何快速試錯。有時産品經理或者項目經理會遇到這樣一個問題：有一個産品或者功能并不确定最終市場的回報情況，但是覺得可以試一試，希望請開發人員在一周之内開發上線并讓産品經理看到最終的使用者回報報告。正是因為這樣的需求，導緻之前路特每年也會上一兩百個小子產品，而到了第二年的時候就是大浪淘沙，一兩百個小子產品最終隻剩下三五十個，但是中間的過程成本卻是存在的，因為如果不上線就不知道産品的最終回報如何。就路特本身而言，肯定會比自己的媒體客戶更懂技術，但是在對行業的了解上卻不如客戶，而行業客戶卻未必能夠用技術語言将需求描述得很好，是以更需要試錯的過程，這就産生了對于持續內建生态鍊快速響應的要求。在使用雲效平台之前試錯是很麻煩的，即便是實作一個小的需求往往需要經曆一兩周才能随着大版本一起上線。
第三個問題如何依托持續內建完成快速疊代全流程。在持續內建搭建之前，在建構部分往往是“東一榔頭，西一棒槌”的狀态，在建構完之後通過Jenkins的釋出元件釋出到伺服器，之後進行統一的批量更新。在接入到雲效之後，就可以通過比較好的流水線的方式解決整個持續內建的釋出疊代的過程，進而簡化了整個過程。從需求、Bug進入到雲效平台，到開發人員定向地針對這個需求拉分支進行單獨開發、Push并觸發自動建構、測試環境的自動部署等一系列流程完全都是自動完成的。
<b>現有流程的梳理</b>
如上圖所示的是現有流程的梳理。在代碼的管理上，會確定系統庫中有三個代碼分支：dev、rc和release，這三個分支是固定的，并且不允許任何開發人員push代碼，因為代碼的破壞往往發生在不經意的無心之失。現有的流程中，首先開發人員會拉一個dev分支并進行命名，之後進行開發，開發完成之後合并到dev上去，是以永遠不可能出現将dev拉下來修改再送出的情況。當将代碼合并到dev之後，在雲效平台會完成一個dev代碼的建構和測試，這部分根據選擇的程式設計語言不同會産生不同的建構效果。單元測試通過之後會推送到dev測試環境，也就是将目前代碼進行建構并運作單元測試，之後通知容器叢集将鏡像跑起來，然後就可以拿到配好域名的URL，之後就可以進行線上dev分支的代碼測試。路特現在使用了阿裡的ACM，可以幫助實作分布式的配置管理。因為容器的代碼源都是一樣的，但是又是無狀态的，是以在代碼中不可能出現寫死使用的資料庫或者緩存的情況，是以對于這套代碼，如果可以在測試環境運作應該就能在正式環境運作，可以借助配置管理工具實作環境的區分和隔離。
這套流程執行起來是比較規範的，是通過平衡效率和風險實作的架構。但是問題是路特的産品線比較多，這就意味着整套流程需要跑四五次，是以如果不使用雲效平台則會使得成本比較高，維護也比較麻煩。
<b>平衡：持續內建與工具鍊</b>
路特在應用持續內建工具鍊時也遇到了一些坑，第一個就是“使用者坑”，使用的一些開源或者商用的內建管理工具都會産生一個問題就是使用者無法管理。第二個問題就是“碎片資料坑”，路特使用Jenkins最頂峰的時候總共有6個節點，其中包括1個主要節點和5個建構節點，這就造成每次建構完成之後的日志無法進行管理，需要進行一系列的轉化才能變成可視的内容報告，而這一系列轉變卻是非常困難的。并且Jenkins内跟蹤的東西如何進入企業内部的知識庫也是非常困難的，這些問題對于中小型企業而言往往是難以實作的。第三個就是“運維坑”，實作持續內建會使用到一系列的工具鍊，每個工具看似很穩定，但是當真正部署到線上，将幾個工具串成一串使用的時候就會發現往往會出現一些莫名奇妙的問題。而這些問題就會給運維人員造成很大的傷害，因為所需要解決的屬于周邊性的問題，而非産品的問題，是以這使得運維人員會很累。使用的工具越多、越複雜，出現問題的頻率也會越高，這就會形成一個死結。
<b>釘釘+雲效=更高效</b>
路特結合上述的業務痛點在架構上進行了一定的調整，通過釘釘+雲效可以完美地解決上述所有的問題。首先是代碼權限問題，雲效接入釘釘企業版之後，可以為新入職的員工分好組，員工就可以自動擷取該組對應的Git代碼。與此同時也解決了賬号的問題，因為雲效是一個一體化的平台，代碼的建構工作全部都是在雲效上面做的，使用釘釘賬号就能進入雲效平台，并且基于釘釘賬号就能配置好代碼管理權限。此外，對于流程控制而言，結合釘釘和雲效開發也會非常友善。
<b>路特和雲效産品/團隊的淵源</b>
路特在最開始的時候沒有使用任何阿裡雲的産品，而是通過自建的腳本進行建構和部署的，當時還涉及到使用Windows和Liunx兩種平台以及三種語言進行建構。大概在2015年到2016年的時候，路特切入了阿裡的CRP平台，這個平台可以視作現在雲效平台的前身，但是其沒有項目管理功能，隻能進行建構和釋出。而CRP平台一開始的時候對于一些建構方面的問題不能夠很好地解決，并且對于新興的技術和語言都不能很好的支援，雖然後來都支援了，但是卻錯過了路特調整架構的時機，是以後來路特放棄了CRP平台。之後，路特重新部署了Jenkins一系列工具，這套工具大概使用了一年多的時間，就遇到了前面所提到的痛點和問題，雖然這套工具鍊能夠解決持續內建的每一個問題，但是串起來的過程卻很痛苦。最後，在考察了雲效平台之後，路特決定将所有業務遷移到雲效平台上去。整個遷移的過程大概花費了3個月的時間，其中路特的技術團隊和雲效技術團隊進行了廣泛的合作，雲效的團隊也能夠聆聽使用者的意見并且不斷疊代和修複自己的産品。
基于雲效平台的持續內建，路特也調整了自身的整體架構。之前沒有使用Docker容器技術，而現在全部改成了微服務和容器的模式。使用者的請求從公網進來到容器叢集中去，容器叢集再去分應用，應用裡面有服務，服務裡面有容器，目前雲效平台可以做到在服務粒度的持續內建，這個粒度已經非常細化了，這離容器已經非常近了。
<b>演進路線圖——我們一直在試圖尋找平衡</b>
在2015年，路特的技術團隊剛開始做持續內建的時候，采用的還不是容器模式，而是單獨的分布式部署模式。在轉向持續內建的時候發現，SVN的鈎子比較少，是以将SVN換成了Git，因為Git的API和鈎子都比較多，是以能夠做的事情也非常豐富，不像SVN所能夠定制化的點非常少。之後大概在2015年的下半年，實作了自定義腳本的建構和部署，因為涉及到3個語言2個平台，是以這個過程也非常痛苦，而自定義腳本也出現了非常多的釋出事故。到2016年的時候，發現3種語言所造成的負擔過大，是以調整成了容器架構，重構了一部分應用，尤其是使用Java重構一部分.Net的應用。大概在2017年初的時候達到了陣痛期，這個時期開源産品用的多了之後就感覺很難受，因為需要考慮各個工具之間的問題。經過多個開源産品之間的拉鋸和抉擇，在2017年末已經基本上全部切入到雲效平台上，并且目前基本上已經穩定了。以上就是路特技術團隊從2015年到2017年所做的關于持續內建的事情。
<b>階段性收獲</b>
通過阿裡雲系列服務及本身架構上的調整，目前在持續內建方面的成本上一年大約可以節約20-25萬左右。
通過與釘釘等辦公産品的有機結合，讓持續內建的流程性變得更簡單，且內建的過程變得更靈活了。
多産品、多項目的持續內建通過雲效的自定義流水線，可以解決原來的一些不夠靈活的問題，降低了中層成員的時間成本并提高了效率
以上由雲栖社群小組場景研讀整理，毛鶴校審，郭雪梅編輯