持續集成 Jenkins 簡介

持續集成的定義

大師 Martin Fowler 是這樣定義持續集成的: 持續集成是一種軟件開發實戰, 即團隊開發成員常常集成他們的工做. 一般, 每一個成員天天至少集成一次, 也就意味着天天可能發生屢次集成.

持續集成並不能消除Bug, 而是讓它們很是容易發現和改正.

根據對項目實戰的理解, 持續集成中的 "持續" 是指不間斷的; "集成" 可分爲廣義和狹義, 廣義的集成指軟件各個過程的集成, 包括開發、部署、測試等. 狹義的集成即代碼和代碼之間的集成, 從而保證代碼合併不衝突.

每次集成都經過自動化的構建 (包括編譯、發佈和自動化測試) 來驗證, 從而儘快的發現集成錯誤. 許多團隊都發現這個過程能夠大大減小代碼集成的問題, 讓團隊更快的開發內聚的軟件. 請注意, 持續集成不等於持續編譯.

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

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

• 項目一開始是先劃分好模塊，分配模塊給相應的開發人員；
• 開發人員開發好一個模塊就進行單元測試；
• 等全部的模塊都開發完成以後，由項目經理對全部代碼進行集成；
• 集成後的項目由項目經理部署到測試服務器上，被交由測試人員進行集成測試；
• 測試過程當中出現 Bug 就提把問題記錄進行 Bug 列表中；
• 項目經理分配 Bug 給相應的責任人進行修改；
• 修改完成後，項目經理再次對項目進行集成，並部署到測試服務器上；
• 測試人員在下一次的集成測試中進行迴歸測試；
• 經過經過以後就部署到生產環境中；
• 若是測試不經過，則重複上述「分配 Bug -> 修改 Bug -> 集成代碼 -> 部署到測試服務器上 -> 集成測試」工做。

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

Bug 老是在最後才發現

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

越到項目後期, 問題越難解決

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

軟件交付時機沒法保障

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

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

程序常常須要變動

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

無效的等待變多

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

用戶的知足度低

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

怎麼樣纔算是「持續」

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

持續集成的工做流程

• 當開始更改代碼時，開發人員會從代碼庫（如 SVN、Git 等）獲取當前代碼庫的副本.
• 當其餘開發人員將更改的代碼提交到代碼庫時, 此副本將逐漸中止反映代碼庫中的代碼. 代碼分支保持檢出的時間越長, 當開發人員分支從新集成到主線時, 多個集成衝突和故障的風險就越大.
• 當開發人員向代碼庫提交代碼時, 他們必須首先更新他們的代碼, 以反映代碼庫中的最新更改.
• 當存儲庫與開發人員的副本不一樣, 他們必需要花時間來先處理衝突.

持續集成的好處

解放了重複性勞動

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

更快地修復問題

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

更快地交付成果

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

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

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

減小手工的錯誤

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

減小了等待時間

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

更高的產品質量

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