簡介持續集成（CI）以及相關工具推薦

Vladimir Pecanac

雖然並不是每一個軟件項目都註定會得到巨大成功，但一些軟件方法和最佳實踐能夠提升成功概率，並讓開發工做更愉快。其中如今流行的一種作法是持續集成（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天免費）