關於CI的伺服器與最佳實踐，這裡有一些思考

CI是敏捷和DevOps關鍵性的一步，數人云最近給大家分享了《致：正在選擇CI平台的你（10大要素需把控）》今天的文章將討論如何使用CI伺服器創建高質量產品以及相關擴展插件和指標度量。最後針對業內標準規則進行了自我思考。

CI伺服器

擁有自動化的構建系統，是實現CI唯一強制性要求。但在實踐中，除了自動化構建系統外，還可以安裝和配置「CI伺服器」。

概述

CI伺服器是大腦，在幕後工作，無縫地將各種行業標準實踐整合到CI實現過程中。

下圖是個典型的CI工作流，包含6個階段，從代碼檢入開始，直到向企業內不同的人員提供反饋信息。

啟動過程

通常，開發人員將代碼簽入源存儲庫時，CI流程就會啟動。

CI工作流也可以通過其他方式觸發，下面列舉幾個方法——

• 手動：用戶通過CI伺服器管理控制台或腳本手動執行時。
• 計劃：預先配置的時間表，如某個夜間構建。
• 觸發：每次提交到源代碼版本控制系統。

夜間構建通常會對代碼執行更大檢查和更久時間。

獲取最新代碼

流程的第二步，CI伺服器從源控制項獲取最新代碼，可以通過輪詢或推送機制實現。

• 在輪詢機制中，CI伺服器配置為源控制伺服器，不斷地在固定時間間隔內對給定的位置進行輪詢，檢測任何新的代碼更改，一旦檢測到，會從源控制伺服器下載最新的代碼副本到磁碟上。

• 推送機制中，源控制系統由一個：「鉤子」提供給CI伺服器，當開發者向提交更改時，調用「鉤子」，並讓CI伺服器了解更改是可用的。

構建

源代碼一般獨立於構建，即必要的構建腳本與源代碼共存，最新的代碼在前面步驟中被詳細地獲取，綁定的腳本會觸發構建。

對於Java項目，通常構建自動化腳本使用Maven或分級。使用不支持內置依賴管理的構建系統並不常見，在不需要依賴管理的情況下，Make 使用了在Unix系統中廣泛使用的構建機制。

有很多構建工具可以使用，Wiki列出了一些:（https://en.wikipedia.org/wiki/List_of_build_automation_software）

執行測試

在此過程中執行單元測試和集成測試，這些測試和代碼一般捆綁在一起。

基於Java的系統，測試使用類似於Junit的測試框架執行，允許對測試依賴項進行簡單的模擬。

某些編程技術自帶測試運行器框架，如Spring的Spring Junit運行器、Java EE中的Arquillian等。

在CI伺服器上運行測試有以下幾點：

• 曾經遇到過測試在一台機器上傳遞，但在另一台上失效的情況嗎？通過在集中的伺服器上運行測試，消除了測試環境的問題。

• 測試會立即執行每個更改，若有代碼破壞預期行為能被快速發現。

• 很多團隊并行處理特性，甚至團隊成員在全球範圍內分佈，每次開發者向存儲庫提交代碼，任何故障都能即刻識別和修復。

結果

CI過程的最後有兩種結果：構建和測試失敗或通過。

每個嵌入都是經過驗證的，並且確保不會破壞現有的代碼，代碼被合併到主幹中，會被構建和測試，允許減少主線代碼被破壞的時間。

一般情況下，CI伺服器失敗會發送電子郵件（給整體團隊或只負責以前簽入的人），可以快速看到失敗的狀況，並且儘快採取糾正措施。

CI伺服器還凸顯了最近構建的狀態，以及最近幾個構建在紅-綠-琥珀光指示器上的狀態，例如，Jenkins使用了下面的構建指示器：

CI伺服器插件

上一節介紹了CI的基本工作流程，但大多數企業會使用它完成更多任務，通過安裝各種插件擴展CI伺服器，開拓行為，下面介紹一些常用的擴展：

技術債務與代碼質量

在應用中引入的任何變化都會增加系統複雜和無序性被稱之為「技術債務」，當新代碼引入系統時會增加技術債務，如果被忽視太久，越來越多的新功能被緊湊的最後期限所填滿，此時想要在可控範圍內幾乎不可能，這將對應用的生產效率和可維護性造成負面影響。

迭代開發、自動化檢測、和CI的使用來監控每個簽入技術債務是控制技術債務的唯一方法。

如SonarQube工具，採用識別代碼質量和跟蹤技術債務的開源平台，可以輕鬆地集成到任何CI伺服器中，為技術債務提供實時數據。

其不僅僅衡量技術債務，也度量並涵蓋了代碼質量的7個核心：

SonarQube在簡單的WEB中展現分析結果，是非常有用的工具，不僅是開發者，對於管理其他非技術的人也是如此。

了解更多請參考：

• 管理技術債務
• Sonarqube：
• Codacy

語義

對於開發者來說，引入CI在另一個重要的方面非常具有價值——可以衡量代碼質量——語義及常見的反模式。

靜態代碼工具可以作為CI過程的一部分，以深入了解代碼的健康度，歷史數據也可以存儲，從而在一段時間內提供質量度量。可以為兩個提交作比較，確定每個提交的債務度量標準。

很多工具可以靜態地分析代碼並計算質量度量的多樣性，同時可以被集成到CI伺服器中自動運行，例如：

• Checkstyle
• Findbugs
• Sonar

更詳盡地工具請參考

代碼評審

開發者在特性分支上工作，並儘可能頻繁地提交代碼。

代碼分析工具（如：Sonar）可以在CI伺服器中執行自動代碼檢測，然後每個開發者負責處理提交時生成的評論註釋。

自動代碼審查基於一組預定義的規則，是發現潛在技術問題很好的方法，這些規則可以從主流的開發語言中下載。

解決了自動化評審意見，會進行同行代碼評審，捕捉那些不能用自動化審查的問題，如驗證業務需求、體系結構問題、代碼易讀性、擴展性等。

如果有一定數量的人沒對代碼進行審查，CI伺服器可以配置成阻止對主線分支任何的提交，常見辦法是在主線分支中強制要求每個提交至少2個審核員，Java的項目中，常見工具是Gerrit。

更多代碼審核工具請參考

Headless Testing

若想在CI伺服器上運行UI測試，必須依賴於Headless（Headless：在缺少顯示屏、鍵盤或者滑鼠時的系統配置）測試，因為瀏覽器沒有顯示，這意味著要在沒有圖形用戶界面的情況下運行UI測試，需要類似於流行WEB瀏覽器的Headless瀏覽器，通過命令行界面執行，並具有UI元素的內存模式。內存中的模型用於模擬UI交互，如，在UI中單擊一個按鈕即可模擬內存中的模型對象。

Selenium測試工具可以用於無頭測試，如Phantom JS的Headless瀏覽器也被廣泛應用，在構建中引入這些測試，CI伺服器能夠驗證失敗的UI。

安裝CI伺服器

CI伺服器主要有三種：

• 獨立
• 託管
• 私有雲

獨立的CI伺服器安裝在一台機器上進行，通常用於小型項目或少於10人的開發團隊。

託管的CI伺服器可以在公有雲上使用，大多數情況下，都與CI伺服器可以訪問的基於雲的源控制系統相連接。這些公司都不希望維護CI或無法維護的公司使用，對於中等規模的團隊，是非常可行的選擇。

私有雲是想要完全控制和基於安全考慮的大公司使用的，多個CI伺服器代理配置在高性能伺服器的集合中，以支持數百個開發者繁重工作負載。

一些被廣泛使用的CI伺服器：

• Jenkins
• Travis CI
• TeamCity
• CruiseControl

更多CI伺服器請參考

CI最佳實踐

Martin Fowler（國際著名面向對象分析設計、UML、模式等方面的專家，敏捷開發方法的創始人之一）在他關於CI的白皮書中提到了為任何CI設置的一些關鍵實踐。這些建議已經成為多年來CI的最佳實踐。

這裡將根據文章作者的見解來審視每一種最佳實踐。

維護單個源存儲庫

「提倡使用版本控制系統實現項目的源代碼，所有與構建項目相關的都應存放在存儲庫中，在此實踐中，約定系統應該從一個新的簽出中構建，不需要額外依賴項，極限開發倡導者Martin Fowler提到，在使用工具支持分支的情況下，應盡量減少分支的使用，更傾向於進行集成而不是同時維護多個版本的應用，主線（或主幹），應該是應用的工作版本。」

提示

• 原則並非一定按照字面上只需一個單一的存儲庫，關鍵是擁有在存儲庫中構建項目所需的所有相關工件，該項目應該從一個新的簽出中進行構建，而不需要額外的依賴項或手動步驟。

• 「項目」的定義取決於自身，如果代碼庫很小，或者代碼所構建的邏輯模塊組件，那麼就意味著是完整可交付的產品。

觀點

• 實踐中建議不要在版本控制系統中使用分支，相反，建議只開發項目的某個分支，且讓其一直處於開發階段。

• 本文作者不同意這種說法，在多數企業中，有許多分支需要同時并行開發，企業需要支持產品的前一個版本，修復BUG，而其他團隊成員則開始著手下一個版本的工作，所以需要在代碼庫中使用多個分支。

自動化構建

「單個命令應該具備構建系統的能力，許多構建工具如Make，已經存在多年，其他近期的工具經常用於CI環境中，構建的自動化應該包括自動化集成，包括部署到類似產品的環境中，在許多情況下構建本本不僅編譯二進位文件，還生成文檔、網站頁面、統計信息和分發介質（如Debian DEB、Red Hat RPM或Windows MSI文件）」

提示

• 構建的自動化應該包括：編譯代碼、執行單元測試和集成測試，以及許多工具——代碼質量檢測、語義檢測、測量技術債務等，多數現代構建工具都支持這些額外集成，並且用於開發CI環境。

• 在實際項目中，不同的團隊負責開發系統不同部分，都有自己的存儲庫，因此這種情況幾乎不可能發生，將整個產品進行自動化構建沒有必要，為系統單獨部分開發構建自動化就足夠。

觀點

定義CI的目的除了自動化構建過程外，是否還有投資CI的意思？作為CI的一部分，打算度量哪些標準？很多人將CI設置看做開發者的工具。

CI不是敏捷或DevOps，只是整體過程的工具之一，敏捷或DevOps已經超越了開發技術層面，升華成一種文化。

構建自測

「構建代碼后，所有測試都應運行以確認它如開發者的預期一樣。」

提示

• 代碼至少要包含單元測試，如Junit框架可以模擬依賴關係。

• 特定組件與其他模塊是不應該交互的，要確保獨立運行。

觀點

• 單元測試應該測試行為，而不是實現細節，例如，不要去在乎如何計算汽車的速度，只要使用的方法和工具是正確的即可。

• 許多測試框架允許斷言模擬對象，如測試模擬對象是否被調用，是否在特定的參數中傳遞等，除非測試實現本身是主要關注點，否則應將其弱化。

保持快速構建

「構建需要快速完成，因此如果集成有問題，會很快被識別。」

提示

• 應該以更快地執行測試為目標，所以需要做比其他類型更多的單元測試。

• 避免在單元測試中使用資料庫，如果可以，也要必滿在集成測試中使用。通常需要集成測試使用另一種數據源，指向內存中的資料庫。如果不可避免，每次測試前都需刷新資料庫，確保數據處於已知狀態，並且測試會以一致的數據開始。

注意

不要依賴大量的UI測試，其非常脆弱，需要大量維護，建議使用如Selenium類似的UI測試框架來緩解UI測試的一些問題，如屏幕上更改UI元素的位置、處理UI事件等。

自動化部署

「很多CI系統允許在構建完成後運行腳本，可以編寫一個腳本將應用部署到每個人都可以查看的實時測試伺服器上，此種思維方式進一步發展是CD（持續部署），要求將應用直接部署到生產中，需要額外的自動化防止BUG和回滾。」

觀點

• 不是所有的項目都需要自動化部署，如果生產站點是由同一家公司託管，那麼在CD中投資更加有利，CD是CI的下一個邏輯步驟。

• 不是所有提交的結果都是可交付的產品，在敏捷社區中每個構建都是可交付的產品是常見的誤解，可交付的產品與工作應用是不同的概念。

原文作者：Deepak Karanth 原文鏈接：https://dzone.com/articles/continuous-integration-part-3-best-practices