1. 程式人生 > >簡介持續整合(CI)以及相關工具推薦

簡介持續整合(CI)以及相關工具推薦

雖然並非每個軟體專案都註定會獲得巨大成功,但一些軟體方法和最佳實踐可以提高成功機率,並讓開發工作更愉快。其中現在流行的一種做法是持續整合(CI,Continuous Integration)。

持續整合最初由Grady Booch在布區方法中提出,之後成為了極限程式設計(extreme programming)的一部分,目的是防止整合問題堆積成為“整合地獄(integration hell)”。

接下來,我們將從以下幾個方面一起了解什麼是持續整合以及如何利用它:

  • 什麼是持續整合
  • 持續整合的好處
  • 持續整合的要求
  • 持續整合伺服器
  • 對於團隊的要求
  • 持續交付和持續部署
  • 潛在的擔心

什麼是持續整合

持續整合是指不斷整合專案更改並進行相應的測試,通常每天至少進行一次。

馬丁福勒說得很好:

持續整合是一種軟體開發實踐,即團隊開發成員經常整合他們的工作,通過每個成員每天至少整合一次,也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建(包括編譯,釋出,自動化測試)來驗證,從而儘早地發現整合錯誤。

自動化的構建、測試和部署流程可以解決軟體開發專案中的許多麻煩和問題。通過可靠的方法頻繁整合程式碼更改,可以儘早發現錯誤。畢竟沒有人希望在demo day出現由於幾個月前編寫一直沒有適當的機會進行合理測試而出現的任何差池。

持續整合可以解決這一痛點,它的整個流程如下圖所示:

持續整合的好處

首先,降低整合風險。多數情況下,一個專案會有多個人單獨處理任務或者一部分程式碼,人員越多,整合的風險越大,而除錯、解決問題本身會是非常痛苦的,我們很可能需要大量修改程式碼。頻繁的整合將極大減少此類問題。

第二,保障程式碼質量。我們可以把精力放在業務程式碼和功能上,從而獲得更高質量的軟體。

第三,有效的版本控制。如果有人提交的程式碼有問題,團隊會即時收到通知,在有任何人拉取之前解決問題。

第四,減少團隊間摩擦。明確而公正的制度流程可以減少團隊之間的爭吵。

第五,改善測試團隊生活質量:) 通過不同版本和構建隔離並追蹤錯誤可以有效減輕測試團隊負擔。

第六,部署更快。自動化可以讓原本繁瑣耗時的部署工作變得輕鬆高效。

第七,增強團隊信心和士氣。團隊成員不必再為潛在錯誤可能會造成的不良後果而憂心忡忡,可以輕裝上陣去創造更好的軟體。

另外還有一個好處是,團隊新成員可以更容易地融入整個專案之中。

持續整合的要求

落地持續整合系統,需要滿足以下要求:

首先版本控制系統(VCS)必不可少,我們需要可靠的方法來集中和儲存專案的所有更改。

如果我們採用的是onsite解決方案,需要有備用的伺服器(至少有臺虛擬機器)。有一臺乾淨的機器來構建系統非常必要。

如果我們不想把伺服器或者虛擬機器搞得一團糟,可以選擇一些持續整合工具和解決方案,用來維護整個流程並獲得更強的伸縮性。

當然從技術上來講,持續整合工具不是必須的,就像軟體開發不是必須要用IDE一樣,具體怎麼選擇,在於我們的能力和需求。

持續整合伺服器

持續整合伺服器(也稱為構建伺服器,又稱CI伺服器)是一種軟體工具,它包含所有持續整合操作,併為我們構建專案提供可靠和穩定的環境。一般持續整合伺服器具備高度可配置性和可調整性,能夠為不同平臺構建各種專案。

使用持續整合伺服器最好能夠安裝在乾淨的機器上,保證其在中立的環境中不受不必要的工具、環境變數和其他配置影響。如果實在沒有物理機,可以考慮構建一個虛擬環境。

另外使用開發機器而不設定虛擬環境,可能會導致錯誤的假設和結果。把應用部署到另一臺機器上時,會遇到新的問題。

持續整合伺服器通常使用版本控制系統(如Subversion或Git或任何其他版本)來提取專案檔案。該系統監控專案倉庫,在程式碼成功提交時,會拉去更改並按照我們的定義來執行。完成任務後,持續整合伺服器會向相關成員傳送構建細節資訊。檢查專案的最新版本、執行構建指令碼、執行測試以及傳送通知是持續整合伺服器的最基本功能。

除此之外,程式碼分析、程式碼覆蓋率、程式碼質量報告、agent pooling、pipeline、構建比較、IDE整合、第三方工具支援等功能,會讓持續整合伺服器更加靈活好用。

對於團隊的要求

相比硬體、軟體或者工具,人的因素對於持續整合成功與否更為關鍵,這要求團隊裡的每個成員都能養成良好的“持續整合”習慣,例如頻繁提交程式碼、立即修復失敗構建、編寫單元測試等等。

持續交付和持續部署

典型的持續整合生命週期包括構建專案、單元測試、部署測試和驗收測試。一旦專案成功通過了所有階段,就可以將其部署到生產環境中。

交付專案到生產環境中可以像其他環節一樣自動完成,也可以根據業務需求手動完成。對於自動完成的情況,我們會了解到持續交付(Continuous Delivery)和持續部署(Continuous Deployment),其差異如下圖所示:

潛在的擔心

持續整合有很多好處,但也有人對它保持懷疑態度,主要考慮有以下幾點:

增加維護成本

我們本來也需要構建、測試和部署系統。如果不用持續整合來管理這些流程的話,也需要其他的工具,否則手工和人力將在專案達到一定複雜度時捉襟見肘。

變化太大

一些認可能不太願意在遺留系統上做太多改變,這種情況下,可以考慮逐步進行,現在小部分工作上使用持續整合。如果大家對效果滿意,再引入落實到其他部分工作上。

硬體/軟體成本

與維護成本及專案完成後回頭解決問題的成本相比,實施持續整合的成本微不足道。

開發者已經在做這些(持續整合的)工作

開發者本可以把時間集中在更有價值的業務開發上,而不是把精力浪費在重複性工作中。

專案太小

即使是很小的專案也可以從透明的開發構成與集中的專案資源和構建中獲益,許多線上持續整合工具設定起來非常簡單。

持續整合工具/平臺

市面上已有很多開源持續整合工具,例如我們熟悉的Jenkins,還有TeamCity、Travis CI、GO CD、Bamboo、Gitlab CI、CircleCI……等等等等。

開源PaaS Rainbond也支援持續整合,提供可擴充套件的CI/CD,支援Java、PHP、Python、Ruby、Node.js、Golang、Scala等原始碼構建,支援程式碼滾動上線、一鍵回滾、灰度釋出、AB測試,可對接Jenkins等第三方CI/CD。

進一步瞭解請訪問Rainbond官網或試用公有云(新使用者7天免費)