jenkins-爲何要持續集成

持續集成（Continuous Integration），也就是咱們常常說的 CI，是現代軟件開發技術的基礎。本文論述了當前軟件開發過程當中存在的問題，講解了持續集成、持續集成服務器的概念，最終探討了爲何咱們須要持續集成來解決這些問題。

 

當前軟件開發過程存在的問題

 

在沒有應用持續集成以前，傳統的開發模式是這樣的：

l 項目一開始是先劃分好模塊，分配模塊給相應的開發人員；

l 開發人員開發好一個模塊就進行單元測試；

l 等全部的模塊都開發完成以後，由項目經理對全部代碼進行集成；

l 集成後的項目由項目經理部署到測試服務器上，被交由測試人員進行集成測試；

l 測試過程當中出現 Bug 就提把問題記錄進行 Bug 列表中；

l 項目經理分配 Bug 給相應的責任人進行修改；

l 修改完成後，項目經理再次對項目進行集成，並部署到測試服務器上；

l 測試人員在下一次的集成測試中進行迴歸測試；

l 經過經過以後就部署到生產環境中；

l 若是測試不經過，則重複上述「分配 Bug -> 修改 Bug -> 集成代碼 -> 部署到測試服務器上 -> 集成測試」工做。

 

這個過程當中可能會出現以下問題：

 

1. Bug 老是在最後才發現

 

隨着軟件技術的發展，軟件規模也在擴大，軟件需求愈來愈複雜，軟件已經不能簡單地經過劃分模塊的方式來開發，每每須要在項目內部互相合做，模塊之間存在必定的依賴關係，那麼早期就存在的 Bug 每每會在最後集成的時候才被發現。

 

2. 越到項目後期，問題越難解決

 

不少開發者須要在集成階段花費大量的時間來尋找 Bug 的根源，加上軟件的複雜性，問題的根源很難定位。並且咱們都清楚，間隔的時間越久，Bug 修復的成本越高，由於連開發人員本身都忘了當初寫得是什麼鬼代碼，從而不得不從頭閱讀代碼、理解代碼。

 

3. 軟件交付時機沒法保障

 

正是由於咱們沒法及時修復 Bug，或者是沒能在早期就修復 Bug，從而令整個修復 Bug 的週期拉長了。無論怎麼樣，咱們不可能把明知存在 Bug 的軟件交付給客戶。

 

並且，大量沒有在前期預估到的工做量產生了——開發人員不得不花費大把時間在查找 Bug 上；測試人員不斷的須要進行迴歸測試；項目經理不得不疲命於該死的代碼的集成、部署這些重複性工做——最終致使整個項目的週期拉長，交付時間點日後拖。

 

4. 程序常常須要變動

 

某些項目，程序會常常須要變動，特別是敏捷開發的實踐者。因爲產品經理在與客戶交流過程當中，每每實際的軟件就是最好的原型，因此軟件會被看成原型做爲跟客戶交流的工具。固然，客戶最但願的固然是客戶的想法可以立刻反映到原型上，這會致使程序會常常被修改的。那麼也就意味着「分配 Bug -> 修改 Bug -> 集成代碼 -> 部署到測試服務器上 -> 集成測試」工做無形又爆增了。

 

5. 無效的等待變多

 

有可能開發在等集成其餘人的模塊；測試人員在等待開發人員修復 Bug；產品經理在等待新版本上線好給客戶作演示；項目經理在等待其餘人提交代碼。無論怎麼樣，等待意味低效。

 

6. 用戶的知足度低

 

這裏的用戶是廣義的，能夠指最終的客戶，也能夠是產品經理、公司領導、測試人員，甚至多是開發人員本身。你想一想看，原本三個月作完的項目被拉長到了九個月甚至一年，用戶能滿意嗎！產品經理、公司領導常常須要拿項目做爲演示的原型，結果告訴我在演示前一刻發現還有不少 Bug 沒有解決，項目啓動不了沒法訪問，這叫人情何以堪。

 

持續集成、持續集成服務器的概念

 

那麼好了，在上面論述的這些問題中，咱們發現有些工做是沒法避免的，好比測試工做、修改程序、集成工做、部署工做。但其實在整個工做流程上，是存在能夠優化的空間的，好比，集成測試的工做是否能夠提早作？能否有自動化的手段來代替測試、集成、部署工做？圍繞這些，軟件行業的大師們提出「持續集成」口號。

 

1. 什麼是持續集成、持續集成服務器

 

在軟件工程中，持續集成（CI）是指將全部開發者工做副本天天屢次合併到主幹的作法。 Grady Booch 在1991年的 Booch method 中首次命名並提出了 CI 的概念，儘管在當時他並不主張天天屢次集成。而 XP（Extreme programming，極限編程）採用了 CI 的概念，並提倡天天不止一次集成。

 

而持續集成服務器就是可以採用自動化的手段，來解放人的雙手，實現項目持續集成的工具。與之配套的軟件有 TeamCity、Jenkins、Go 等。

 

2. 怎麼樣纔算是「持續」

 

對於一天須要集成多少次數，並無一個明確的定義。通常就是按照本身項目的實際須要來設置必定的頻率，少則可能幾回，多則可能達幾十次。能夠設置按照代碼的變動來觸發集成，或者設置一個固定時間週期來集成，也能夠手工點擊集成的按鈕來「一鍵集成」。

 

3. 持續集成的工做流程

l 當開始更改代碼時，開發人員會從代碼庫（如 SVN、Git 等）獲取當前代碼庫的副本。

l 當其餘開發人員將更改的代碼提交到代碼庫時，此副本將逐漸中止反映代碼庫中的代碼。代碼分支保持檢出的時間越長，當開發人員分支從新集成到主線時，多個集成衝突和故障的風險就越大。

l 當開發人員向代碼庫提交代碼時，他們必須首先更新他們的代碼，以反映代碼庫中的最新更改。

l 當存儲庫與開發人員的副本不一樣，他們必需要花時間來先處理衝突。

 

 

持續集成的好處

 

1. 解放了重複性勞動

 

自動化部署工做能夠解放了集成、測試、部署等重複性勞動，並且機器集成的頻率明顯能夠比手工的高不少。

 

2. 更快地修復問題

 

因爲持續集成更早的獲取變動，更早的進入測試，也就能更早的發現問題，解決問題的成本顯著降低。

 

3. 更快地交付成果

 

及早集成、及早測試減小了缺陷遺留到部署環節的機會。在某些狀況下，更早地查找錯誤還會減小解決錯誤所需的工做量。

 

若是集成服務器對代碼進行構建過程當中發現錯誤，能夠及時發送郵件或者短信提供給開發人員進行修復。

 

若是集成服務器在部署環節發現當前版本有問題不可用，集成服務器會將部署回退到上一個版本。這樣服務器上始終都會有一個可用的版本。

 

4. 減小手工的錯誤

 

人與機器的一個最大的區別是，在重複性動做上，人容易犯錯，而機器犯錯的概率幾乎爲零。因此，當咱們搭建完成集成服務器後，之後的事就交給集成服務器來打理吧。

 

5. 減小了等待時間

 

持續集成縮短了從開發、集成、測試、部署各個環節的時間，從而也就縮短了中間能夠出現的等待時間。持續集成，意味着開發、集成、測試、部署也得以持續。

 

6. 更高的產品質量

 

集成服務器每每提供 Code review、代碼質量檢測等功能。對代碼不規範或者有錯誤的地方會進行標識，也能夠設置郵件、短信等進行告警。而開發人員經過 Code review 也能夠持續提升編程的能力。

 

持續集成的最佳實踐

 

1. 頻繁檢出代碼

 

爲了讓你本地的副本和代碼庫中的版本最小差別化，建議頻繁檢出代碼。有時候代碼衝突無可避免，但最小差別化最容易解決。並且，越早發現的問題，解決成本也最低。

 

2. 頻繁提交代碼

 

這個與第1條的原理相似，頻繁提交代碼，可讓其餘人的檢出副本和代碼庫中的版本最小差別化。

 

3. 減小分支，迴歸主幹

 

雖然代碼管理工具都支持分支的概念，但應儘可能減小其使用。假設有多個分支並行，應及早將變動集成到主幹中，而不是同時維護軟件的多個版本。主幹做爲軟件開發的工做版本。

 

4. 使用自動化構建

 

可使用 Maven、Ant 等來實現自動化構建，這些工具能夠幫助你在構建過程當中實現自動化測試。前提是你有寫單元測試用例，好比 JUnit 等。

 

5. 提交自測

 

在提交工做以前，每一個程序員必須本地集成全部的代碼，作一個完整的構建和運行，並經過全部單元測試。這樣就減小了集成測試在集成服務器上構建失敗的風險。

 

6. 當前狀態對於每一個人均可見

 

集成服務器在持續集成過程當中發現問題，應能發送告警給相關的干係人。同時，也能夠在牆上等醒目的位置設置一個大屏顯示器，將集成服務器的狀態實時展示在大屏上，方便提醒組員「趕忙回去解決問題」！

 

持續集成可能會面臨的挑戰

 

1. 團隊人員思想上的抵觸

l 沒法接受新事物：無論怎麼樣，求穩心態的人仍是多。老是有人認爲老的技術表明穩定，新的事物每每會帶來問題。

l 認爲手工集成也沒有多少工做量：不是全部的人都參與到了整個持續集成的環節，因此沒有辦法認識到問題全貌。

l 針對這個問題，能夠經過設置必定的持續集成技術培訓、宣講獲得改觀。

 

2. 管理層的抵觸

l 培訓持續集成須要投入資金啊，沒錢。

l 持續集成服務器要增長軟硬件成本啊，沒錢。

l 開發人員領了那麼高的工資，多幹活多加班應該啊。

 

針對這一點，能夠從開發人員的成本和持續集成的投入（軟硬件）的成本上二者作下估算。

 

3. 生產環境的複雜

 

好比部署的生成環境是在政務外網，沒法從互聯網直接訪問等。

目前，這個是最麻煩的，還在研究中。初步設想是讓政務外網開闢一個白名單，給持續集成服務器設置一個單獨的通道。只是思路，未驗證。

固然，考慮到目前的工做的實際，能夠先持續部署軟件到本身公司的演示服務器上，這樣，起碼先解決了客戶和產品經理溝通所使用的原型問題。 畢竟，客戶真實使用的軟件在更新的頻率上能夠適度的放寬。

 

參考資料

l Grady Booch. Object-Oriented Design with Applications.Benjamin Cummings，1991，3(5):209

l Paul M. Duvall，Steve Matyas，Andrew Glover.Continuous Integration：Improving Software Quality and Reducing Risk.Upper Saddle River：Addison-Wesley，2007

l http://martinfowler.com/articles/continuousIntegration.html