作為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應用進行測試與部署的解決方案。