以持續整合工具實現DevOps之禪

作為DevOps流程中的一個重要組成部分，持續整合（CI）的目標是對開發團隊的程式碼進行整合，包括程式碼的構建、單元測試與整合測試的執行，以及生成執行結果的報表等等。CI使開發團隊無需將時間浪費在處理程式碼衝突的問題上，因此很多人將其視為敏捷軟體開發的奠基石。

CI與持續部署（CD）過程通常是緊密聯絡在一起的。CD過程通過在管道中定義的步驟將由CI過程所生成的結果部署至整合、預釋出乃至生產環境中。由於整個CD過程是“持續的”，因此一旦有程式碼簽入原始碼控制系統，後續過程就會自動進行測試、對程式碼進行構建、並將構建結果部署至目標環境中。它的優點顯而易見：一方面，開發者可快速地收到bug與故障的通知，形成快速的反饋迴圈。另一方面，客戶也將更快地使用你的新特性。

近日，Vassili van der Mersch在一篇部落格文章中對各種環境中的CI工具進行了詳細的比較，並分析了CI工具的未來發展。在後續的文章中，作者還將繼續分析DevOps中的另一重要內容，即配置管理。

傳統的CI工具

第一個正規的持續整合工具是於2001年所推出的CruiseControl，這是一個基於Java開發的開源軟體。除了持續構建流程之外，它還提供了郵件通知、Ant以及對各種原始碼控制系統的支援，並推出了支援.NET與Ruby的移植版本。儘管Jenkins後來居上，成為第一個得到廣泛應用的CI工具，但CruiseControl已經具備了一個CI工具的基本功能，為CI過程的推廣做出了很大的貢獻。

Jenkins的出現與發展頗有傳奇色彩，它的前身是由一位來自Sun公司的開發者川口浩介（Kohsuke Kawaguchi）於2004年開發的一個基於Java的CI工具Hudson。經過三/四年的發展後，它逐漸超越CruiseControl成為了最流行的CI工具。但自從Oracle收購了Sun之後，希望將Hudson作為收費的商業工具進行開發。以川口為首的開發者社群則決定以Jenkins的名義繼續免費版本的開發。有趣的是，Hudson與Jenkins的開發者各自將對方視為自己的分支版本，而將自身視為正統。在2013年後，Jenkins的發展勢頭已有超越之勢，它的每日提交次數遠遠地超越了Hudson，如今已成為市面上最流行的CI工具。

早期的Jenkins與其他傳統CI一樣，只支援本地託管。而現在已經有一些雲端計算平臺推出了基於Jenkins的SaaS方案。這方面比較突出的有CloudBees，它所提供的方案是一種整合了CI與CD的混合方案，可通過Docker Pipeline外掛提供對Docker容器的支援。

除了Jenkins之外，其他一些流行的CI工具還包括由JetBrains推出的TeamCity，以及由Atlassian推出的Bamboo等等。這些CI工具基本都提供了以下功能：

對原始碼控制系統的支援，例如Git、Subversion、TFS等等。可以在程式碼控制的主線發生程式碼提交時自動觸發後續的一系列步驟，例如構建、測試與部署等等。 對依賴管理工具的支援，如Java的Maven、NodeJS的NPM、Ruby的Gem，以及.NET的Nuget等等。 對各種型別測試的支援。早期的CI只支援單元測試，即單個物件或元件的功能驗證。隨後加入了對整合測試的支援，即對元件之間的通訊與互動進行難。儘管如此，這還不足以驗證系統確實按照使用者期望的方式進行工作。因此現代化的CI工具開始支援功能性測試，將原先的手工測試替代為基於Selenium等工具的自動化測試。

雲端計算環境中的CI工具

曾在大規模企業中嘗試過CI實踐的開發者非常瞭解：程式碼的構建與測試的執行是一種非常消耗資源的操作，如果有多個團隊使用同一個CI平臺，那麼這種情況將進一步加劇。近幾年來，軟體團隊逐漸厭倦了本地託管的CI系統對時間與精力的要求。而基於雲端計算平臺的SaaS解決方案的出現快速地彌補了這方面市場的缺失。

Travis CI是一個基於GitHub API所打造的託管CI服務，使用Travis CI有一個先決條件，即原始碼需要在GitHub進行託管。Travis CI通過webhook對GitHub程式碼倉庫中的各種變化進行響應，例如程式碼提交或pull request等等。Travis CI也依賴GitHub提供的服務對使用者和組織進行認證。

使用基於雲環境的CI系統讓開發者得以從對本地CI系統的安裝、配置過程中解脫，不必再關注於基礎設施和使用者認證與授權方面的問題。此外，由於大多數SaaS方案都提供了對應的API，因此整個工作流都可以實現API驅動。

基於雲環境的CI系統還有另一大優勢，他們通常會提供更多的測試功能，例如對不同瀏覽器與作業系統組合條件的測試。例如Travis就支援在Linux、Mac和Windows系統上的測試，並支援PHP、NodeJS、Go和C等各種語言。

用於移動應用的CI工具

隨著智慧手機的日益普及，移動應用的數量也在不斷增長。但由於移動應用與Web應用相比有一些特別之處，例如它的測試與釋出方式，以及完全不同的依賴管理機制，因此移動應用對於構建、測試及部署流程提出了完全不同的要求，這是傳統的CI工具力所不及的。好在如今已經有幾家主流的CI提供商實現了支援移動應用的CI工具，例如CircleCI已經提供了對iOS應用的支援。

移動應用的測試與Web應用具有很大的差別，Web應用的客戶端多數集中在一些主流的瀏覽器與作業系統上，而移動應用的客戶端往往是千差萬別的，特別是在Android平臺上。某些測試框架，例如Espresso以及Appium能夠自動替你解決許多困難。而像Crashlytics與HockeyApp這樣的工具除了內建的CI功能之外，還能夠自動生成應用崩潰的報告，為開發者進行問題診斷提供充分的上下文。

而由於移動客戶端的多樣性，以集中化的方式進行所有測試的方式是不太實際的。因此，移動開發社群更推崇beta測試的方式，通過TestFairy或TestFlight等工具將潛在的新版本釋出給beta測試人員。

移動應用的另一個獨特之處在於它的釋出方式，通常需要經過漫長而繁瑣的稽核流程才可釋出至對應的應用商店。這不僅降低了持續交付的速度，還不得不在流程中引入各種人工步驟，使全自動化的流程無法實現。

為此，像Fastlane這樣的工具可實現將應用稽核流程中的大部分元素實現自動化，例如為新應用進行螢幕截圖及處理認證等資訊。可結合Jenkins等CI工具以完善整個工作流。

CI工具的未來

CI與CD過程如今已成為現代化應用開發中一個並不可少的元素，絕大多數開發團隊在軟體專案中都需要設計一個完善的CI與CD工作流。

而CI的發展並不會停下腳步，它仍處於高速的發展中。在對Web及移動專案支援的基礎上，未來幾年之內，我們將看到CI在其他型別的開發中的應用，例如智慧手錶、智慧汽車以及物聯網中，甚至是在虛擬現實與生物科技專案中的應用。

CI過程目前所面臨的一個挑戰在於在開發環境中執行的自動化測試與生產環境之間總是存在著或多或少的差別。隨著近來年以Docker為代表的容器化技術在（微）服務系統中的廣泛應用，CI過程也從容器的使用中受益匪淺。Docker的高可移植性使多個CI提供商開始擁抱Docker。舉例來說，CircleCI就支援基於容器的應用，而CodeShip近期也推出了Jet，這是一個對Docker應用進行測試與部署的解決方案。

本文轉自d1net（轉載）