在前一篇文章持續(xù)集成入門篇中我大概介紹了下持續(xù)集成的概念及工具（抱歉，在前一篇文章中我查的資料不夠與時俱進，工具介紹的都比較老挎袜，目前流行的工具應(yīng)該就屬Jenkins和Travis CI 了）优妙。
這篇文章我將就持續(xù)集成的話題繼續(xù)深入地探討一番。
持續(xù)集成的四個步驟
代碼級別的集成
這個級別的集成不依賴獨立的持續(xù)集成工具也可以實現(xiàn)祭埂，一般語言的build工具基本內(nèi)置，比如java的maven兵钮，gradle蛆橡，go內(nèi)置的build工具。
集成 Workflow
單一的編譯-構(gòu)建工具逐漸地不能滿足產(chǎn)品快速交付的需求矢空。
整個開發(fā)流程的重心從『代碼級別的集成』轉(zhuǎn)移到了更自動化地編譯和更完美的測試驗證航罗，致力于在最短的時間內(nèi)發(fā)現(xiàn)問題，縮短開發(fā)周期屁药，提高軟件質(zhì)量粥血。比較常見的一個場景，某個團隊先進行代碼 Build，觸發(fā)單元測試复亏、集成測試趾娃，打包測試完畢后再自動部署到測試環(huán)境，循環(huán)往復(fù)缔御，形成「編譯-構(gòu)建-測試-集成-部署到測試環(huán)境」的 Workflow.
持續(xù)部署與交付
在上個階段中抬闷，產(chǎn)品是自動部署在測試環(huán)境，手動部署在生產(chǎn)環(huán)境耕突。之所以這樣選擇笤成，是因為產(chǎn)品在從需求到部署的過程中，會經(jīng)歷若干種不同的環(huán)境眷茁，例如 QA 環(huán)境炕泳、各種自動化測試運行環(huán)境、生產(chǎn)環(huán)境等上祈。這些環(huán)境的搭建培遵、配置、管理登刺，在不同環(huán)境中的具體部署是比較復(fù)雜的籽腕。經(jīng)常會遇到這么一種場景：明明在測試環(huán)境已經(jīng)部署成功，但線上環(huán)境又出現(xiàn)部署故障纸俭。這種情況很可能是生產(chǎn)環(huán)境和測試環(huán)境的異構(gòu)造成的皇耗。
這時候需要改進你的 CI 系統(tǒng)，建立標準化的環(huán)境部署順序掉蔬，在 Workflow 中增加部署預(yù)生產(chǎn)環(huán)境并進行灰度集成測試的流程廊宪，做好線上環(huán)境部署后的回歸測試矾瘾。到這里女轿，已經(jīng)真正做到了持續(xù)交付。
持續(xù)交付并不是指軟件每一個改動都要盡快部署到產(chǎn)品環(huán)境中佛嬉，它指的是任何的代碼修改都可以在任何時候?qū)嵤┎渴鹧字汀６?strong>持續(xù)部署』杭隙，即自動部署到生產(chǎn)環(huán)境中而無需手工干預(yù)：得到一個版本后，自動部署該版本到生產(chǎn)環(huán)境中北救。實踐證明，相對獨立快速地部署新功能是一個核心競爭力芜抒，可以減輕大規(guī)模功能變更的風(fēng)險珍策。
并行多workflow集成以及個性化集成
隨著項目和團隊規(guī)模增長，模塊之間依賴關(guān)系變得復(fù)雜宅倒，如何確保代碼質(zhì)量的同時攘宙，保證代碼構(gòu)建的一致性和穩(wěn)定性，成為一大挑戰(zhàn)。Docker 可以方便地以『容器化』的方式部署蹭劈，它就像集裝箱一樣疗绣，打包了所有依賴，在其他服務(wù)器上部署很容易铺韧，不至于換服務(wù)器后發(fā)現(xiàn)各種配置文件散落一地多矮，這樣就解決了編譯時依賴和運行時依賴的問題。
還有一個問題哈打，開發(fā)的分支越來越多塔逃，每個活躍分支都進行環(huán)境部署和集成測試，對持續(xù)集成環(huán)境的維護成本也就越高料仗。Docker 的快速啟動和鏡像倉庫是天生為 CI/CD 設(shè)計的患雏，以前啟動一個虛擬機需要幾分鐘，而啟動 Docker 只需要幾秒鐘罢维，讓并行的持續(xù)集成才能成為可能淹仑。
目前，比較常見的基于 Docker 進行持續(xù)集成的流程如下：
- 開發(fā)者提交代碼
- 觸發(fā)鏡像構(gòu)建
- 構(gòu)建鏡像上傳至私有倉庫
- 鏡像下載至執(zhí)行機器
- 鏡像運行
持續(xù)集成工具
傳統(tǒng)的CI工具
第一個正規(guī)的持續(xù)集成工具是于2001年所推出的CruiseControl肺孵，這是一個基于Java開發(fā)的開源軟件匀借。除了持續(xù)構(gòu)建流程之外，它還提供了郵件通知平窘、Ant以及對各種源代碼控制系統(tǒng)的支持吓肋，并推出了支持.NET與Ruby的移植版本。盡管Jenkins后來居上瑰艘，成為第一個得到廣泛應(yīng)用的CI工具是鬼，但CruiseControl已經(jīng)具備了一個CI工具的基本功能，為CI過程的推廣做出了很大的貢獻紫新。
Jenkins的出現(xiàn)與發(fā)展頗有傳奇色彩均蜜，它的前身是由一位來自Sun公司的開發(fā)者川口浩介（Kohsuke Kawaguchi）于2004年開發(fā)的一個基于Java的CI工具Hudson。經(jīng)過三/四年的發(fā)展后芒率，它逐漸超越CruiseControl成為了最流行的CI工具囤耳。但自從Oracle收購了Sun之后，希望將Hudson作為收費的商業(yè)工具進行開發(fā)偶芍。以川口為首的開發(fā)者社區(qū)則決定以Jenkins的名義繼續(xù)免費版本的開發(fā)充择。有趣的是，Hudson與Jenkins的開發(fā)者各自將對方視為自己的分支版本匪蟀，而將自身視為正統(tǒng)椎麦。在2013年后，Jenkins的發(fā)展勢頭已有超越之勢材彪，它的每日提交次數(shù)遠遠地超越了Hudson观挎，如今已成為市面上最流行的CI工具撒桨。
早期的Jenkins與其他傳統(tǒng)CI一樣，只支持本地托管键兜。而現(xiàn)在已經(jīng)有一些云計算平臺推出了基于Jenkins的SaaS方案凤类。這方面比較突出的有CloudBees，它所提供的方案是一種集成了CI與CD的混合方案普气，可通過Docker Pipeline插件提供對Docker容器的支持谜疤。
除了Jenkins之外，其他一些流行的CI工具還包括由JetBrains推出的TeamCity现诀，以及由Atlassian推出的Bamboo等等夷磕。這些CI工具基本都提供了以下功能：
- 對源代碼控制系統(tǒng)的支持，例如Git仔沿、Subversion坐桩、TFS等等》怙保可以在代碼控制的主線發(fā)生代碼提交時自動觸發(fā)后續(xù)的一系列步驟绵跷，例如構(gòu)建、測試與部署等等成福。
- 對依賴管理工具的支持碾局，如Java的Maven、NodeJS的NPM奴艾、Ruby的Gem净当，以及.NET的Nuget等等。
- 對各種類型測試的支持蕴潦。早期的CI只支持單元測試像啼，即單個對象或組件的功能驗證。隨后加入了對集成測試的支持潭苞，即對組件之間的通信與交互進行難忽冻。盡管如此，這還不足以驗證系統(tǒng)確實按照用戶期望的方式進行工作萄传。因此現(xiàn)代化的CI工具開始支持功能性測試甚颂，將原先的手工測試替代為基于Selenium等工具的自動化測試蜜猾。
云計算環(huán)境中的CI工具
曾在大規(guī)模企業(yè)中嘗試過CI實踐的開發(fā)者非常了解：代碼的構(gòu)建與測試的執(zhí)行是一種非常消耗資源的操作秀菱，如果有多個團隊使用同一個CI平臺，那么這種情況將進一步加劇蹭睡。近幾年來衍菱，軟件團隊逐漸厭倦了本地托管的CI系統(tǒng)對時間與精力的要求。而基于云計算平臺的SaaS解決方案的出現(xiàn)快速地彌補了這方面市場的缺失肩豁。
Travis CI是一個基于GitHub API所打造的托管CI服務(wù)脊串，使用Travis CI有一個先決條件辫呻，即源代碼需要在GitHub進行托管。Travis CI通過webhook對GitHub代碼倉庫中的各種變化進行響應(yīng)琼锋，例如代碼提交或pull request等等放闺。Travis CI也依賴GitHub提供的服務(wù)對用戶和組織進行認證。
使用基于云環(huán)境的CI系統(tǒng)讓開發(fā)者得以從對本地CI系統(tǒng)的安裝缕坎、配置過程中解脫怖侦，不必再關(guān)注于基礎(chǔ)設(shè)施和用戶認證與授權(quán)方面的問題。此外谜叹，由于大多數(shù)SaaS方案都提供了對應(yīng)的API匾寝，因此整個工作流都可以實現(xiàn)API驅(qū)動。
基于云環(huán)境的CI系統(tǒng)還有另一大優(yōu)勢荷腊，他們通常會提供更多的測試功能艳悔，例如對不同瀏覽器與操作系統(tǒng)組合條件的測試。例如Travis就支持在Linux女仰、Mac和Windows系統(tǒng)上的測試猜年，并支持PHP、NodeJS疾忍、Go和C等各種語言码倦。
用于移動應(yīng)用的CI工具
隨著智能手機的日益普及，移動應(yīng)用的數(shù)量也在不斷增長锭碳。但由于移動應(yīng)用與Web應(yīng)用相比有一些特別之處袁稽，例如它的測試與發(fā)布方式，以及完全不同的依賴管理機制擒抛，因此移動應(yīng)用對于構(gòu)建推汽、測試及部署流程提出了完全不同的要求，這是傳統(tǒng)的CI工具力所不及的歧沪。好在如今已經(jīng)有幾家主流的CI提供商實現(xiàn)了支持移動應(yīng)用的CI工具歹撒，例如CircleCI已經(jīng)提供了對iOS應(yīng)用的支持。
移動應(yīng)用的測試與Web應(yīng)用具有很大的差別诊胞，Web應(yīng)用的客戶端多數(shù)集中在一些主流的瀏覽器與操作系統(tǒng)上暖夭，而移動應(yīng)用的客戶端往往是千差萬別的，特別是在Android平臺上撵孤。某些測試框架迈着，例如Espresso以及Appium能夠自動替你解決許多困難。而像Crashlytics與HockeyApp這樣的工具除了內(nèi)置的CI功能之外邪码，還能夠自動生成應(yīng)用崩潰的報告裕菠，為開發(fā)者進行問題診斷提供充分的上下文。
而由于移動客戶端的多樣性闭专，以集中化的方式進行所有測試的方式是不太實際的奴潘。因此旧烧，移動開發(fā)社區(qū)更推崇beta測試的方式，通過TestFairy或TestFlight等工具將潛在的新版本發(fā)布給beta測試人員画髓。
移動應(yīng)用的另一個獨特之處在于它的發(fā)布方式掘剪，通常需要經(jīng)過漫長而繁瑣的審核流程才可發(fā)布至對應(yīng)的應(yīng)用商店。這不僅降低了持續(xù)交付的速度奈虾，還不得不在流程中引入各種人工步驟杖小，使全自動化的流程無法實現(xiàn)。
為此愚墓，像Fastlane這樣的工具可實現(xiàn)將應(yīng)用審核流程中的大部分元素實現(xiàn)自動化予权，例如為新應(yīng)用進行屏幕截圖及處理認證等信息±瞬幔可結(jié)合Jenkins等CI工具以完善整個工作流扫腺。
CI工具的未來
CI與CD過程如今已成為現(xiàn)代化應(yīng)用開發(fā)中一個并不可少的元素，絕大多數(shù)開發(fā)團隊在軟件項目中都需要設(shè)計一個完善的CI與CD工作流村象。
而CI的發(fā)展并不會停下腳步笆环，它仍處于高速的發(fā)展中。在對Web及移動項目支持的基礎(chǔ)上厚者，未來幾年之內(nèi)躁劣，我們將看到CI在其他類型的開發(fā)中的應(yīng)用，例如智能手表库菲、智能汽車以及物聯(lián)網(wǎng)中账忘，甚至是在虛擬現(xiàn)實與生物科技項目中的應(yīng)用。
CI過程目前所面臨的一個挑戰(zhàn)在于在開發(fā)環(huán)境中執(zhí)行的自動化測試與生產(chǎn)環(huán)境之間總是存在著或多或少的差別熙宇。隨著近來年以Docker為代表的容器化技術(shù)在（微）服務(wù)系統(tǒng)中的廣泛應(yīng)用鳖擒，CI過程也從容器的使用中受益匪淺。Docker的高可移植性使多個CI提供商開始擁抱Docker烫止。舉例來說蒋荚，CircleCI就支持基于容器的應(yīng)用，而CodeShip近期也推出了Jet馆蠕，這是一個對Docker應(yīng)用進行測試與部署的解決方案期升。
持續(xù)集成最佳實踐要點
持續(xù)集成無論是工具使用還是流程定義，其實都不難互躬，難的是如何形成這樣的習(xí)慣與文化播赁。筆者通過自己的實踐經(jīng)驗總結(jié)了以下持續(xù)集成的最佳實踐要點，可以幫助讓這個改進更容易些：
- 首先要選擇一個可以脫離IDE進行build的語言以及項目定義工具吨铸。這個很明顯行拢，CI是要在服務(wù)器上跑的。如果你的團隊進行build還完全依賴IDE诞吱，這事情就沒法搞舟奠。
- CI工具越早引入越好，最好是寫第一行代碼的時候就先弄個CI房维，但配置不用一步到位沼瘫，可以按照上面的進階一步步完善。這樣才容易形成圍繞CI進行開發(fā)的習(xí)慣咙俩。
- 集成測試用例最好使用項目本身開發(fā)語言編寫和單元測試類似耿戚，至少是團隊開發(fā)人員都熟悉的語言。并且項目代碼要和集成測試用例在同一個源碼倉庫里阿趁。如果你的團隊有專門的QA人員寫測試用例膜蛔，那最好讓QA和開發(fā)人員共享同一個代碼倉庫。如果你的集成測試系統(tǒng)是通過配置實現(xiàn)的脖阵，那也請將測試用例作為配置文件放到代碼倉庫中皂股，而不是通過web編輯器放到數(shù)據(jù)庫中。這樣做的最大好處是項目代碼和集成測試代碼共享同一個分支命黔，同一個build number呜呐，只有這樣才能做多分支的并行測試。否則如果測試用例單獨維護悍募，代碼的分支如何和測試用例對應(yīng)起來蘑辑？最后的結(jié)果就是，自動化測試用例都是上線后補充的坠宴，上線前還是依賴人肉測試洋魂。
- 編寫測試用例和功能開發(fā)最好是同一個人，如果做不到喜鼓，編寫測試用例的開發(fā)也要有權(quán)限修改業(yè)務(wù)代碼忧设。因為要做自動化測試必須在系統(tǒng)中留一些后門來給自動化測試提供便利。比如提供用戶的批量生成和銷毀颠通，比如對測試的請求不記錄到統(tǒng)計日志中等等址晕。
- 部署的腳本或者配置最好和項目在同一個源碼倉庫。只有這樣顿锰，自動化部署才方便實施谨垃。因為項目的改進以及重構(gòu)，往往伴隨著依賴資源以及部署機制上的改造硼控。
- 服務(wù)最好不依賴外部容器刘陶，可以獨立運行。這個專指java的容器牢撼，其他的如go,nodejs都沒有這個問題匙隔。java的容器是企業(yè)應(yīng)用為了降低部署成本帶來的習(xí)慣，但當前虛擬化熏版，docker等技術(shù)這樣成熟的情況下纷责，應(yīng)用容器已經(jīng)完全沒必要了捍掺。如果非要用，也最好直接和應(yīng)用打包在一起再膳，讓應(yīng)用可以直接運行挺勿，這對開發(fā)效率以及集成測試，都非常有幫助喂柒。
- 最好提供一種直接可以單進程運行整個系統(tǒng)而不依賴外部資源的配置不瓶，外部資源都用內(nèi)存版的庫進行mock。這樣做的好處是可以非吃纸埽快速的進行初步的集成測試驗證蚊丐，同時也非常方便統(tǒng)計集成測試覆蓋率（通過單元測試覆蓋率工具即可實現(xiàn)）。
- 如果公司有多個研發(fā)團隊艳吠，最好共享CI池麦备，這樣成本最小。有的公司為了省錢讲竿，避免超過免費限制泥兰，部署多套CI。其實算下來這樣成本比購買商業(yè)版更高题禀。
總結(jié)
持續(xù)集成是最能體現(xiàn)一個團隊的DevOps（關(guān)于DevOps將在接下來的文章中進行講解）氛圍以及水平的一個場景鞋诗，因為整個流程需要開發(fā)，測試迈嘹，運維的緊密協(xié)作削彬，缺一不可。
