持續集成

持續集成（Continuous integration）

提出

集成軟件的過程不是新問題，若是項目開發的規模比較小，好比一我的的項目，若是它對外部系統的依賴很小，那麼軟件集成不是問題，可是隨着軟件項目複雜度的增長（即便增長一我的），就會對集成和確保軟件組件可以在一塊兒工做提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發現項目風險和質量問題，若是到後期才發現這些問題，解決問題代價很大，頗有可能致使項目延期或者項目失敗。

定義

大師Martin Fowler對持續集成是這樣定義的:持續集成是一種軟件開發實踐，即團隊開發成員常常集成他們的工做，一般每一個成員天天至少集成一次，也就意味着天天可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試)來驗證，從而儘快地發現集成錯誤。許多團隊發現這個過程能夠大大減小集成的問題，讓團隊可以更快的開發內聚的軟件。

價值

減小風險

一天中進行屢次的集成，並作了相應的測試，這樣有利於檢查缺陷，瞭解軟件的健康情況，減小假定。

減小重複過程

減小重複的過程能夠節省時間、費用和工做量。提及來簡單，作起來難。這些浪費時間的重複勞動可能在咱們的項目活動的任何一個環節發生，包括代碼編譯、數據庫集成、測試、審查、部署及反饋。經過自動化的持續集成能夠將這些重複的動做都變成自動化的，無需太多人工干預，讓人們的時間更多的投入到動腦筋的、更高價值的事情上。

任什麼時候間、任何地點生成可部署的軟件

持續集成可讓您在任什麼時候間發佈能夠部署的軟件。從外界來看，這是持續集成最明顯的好處，咱們能夠對改進軟件品質和減小風險提及來口若懸河，但對於客戶來講，能夠部署的軟件產品是最實際的資產。利用持續集成，您能夠常常對源代碼進行一些小改動，並將這些改動和其餘的代碼進行集成。若是出現問題，項目成員立刻就會被通知到，問題會第一時間被修復。不採用持續集成的狀況下，這些問題有可能到交付前的集成測試的時候才發現，有可能會致使延遲發佈產品，而在急於修復這些缺陷的時候又有可能引入新的缺陷，最終可能致使項目失敗。

加強項目的可見性

持續集成讓咱們可以注意到趨勢並進行有效的決策。若是沒有真實或最新的數據提供支持，項目就會遇到麻煩，每一個人都會提出他最好的猜想。一般，項目成員經過手工收集這些信息，增長了負擔，也很耗時。持續集成能夠帶來兩點積極效果：

(1)有效決策：持續集成系統爲項目構建狀態和品質指標提供了及時的信息，有些持續集成系統能夠報告功能完成度和缺陷率。

(2)注意到趨勢：因爲常常集成，咱們能夠看到一些趨勢，如構建成功或失敗、整體品質以及其它的項目信息。

創建團隊對開發產品的信心

持續集成能夠創建開發團隊對開發產品的信心，由於他們清楚的知道每一次構建的結果，他們知道他們對軟件的改動形成了哪些影響，結果怎麼樣。

要素

1.統一的代碼庫

2.自動構建

3.自動測試

4.每一個人天天都要向代碼庫主幹提交代碼

5.每次代碼遞交後都會在持續集成服務器上觸發一次構建

6.保證快速構建

7.模擬生產環境的自動測試

8.每一個人均可以很容易的獲取最新可執行的應用程序

9.每一個人都清楚正在發生的情況

10.自動化的部署

原則

1. 全部的開發人員須要在本地機器上作本地構建，而後再提交的版本控制庫中，從而確保他們的變動不會致使持續集成失敗。

2. 開發人員天天至少向版本控制庫中提交一次代碼。

3. 開發人員天天至少須要從版本控制庫中更新一次代碼到本地機器。

4. 須要有專門的集成服務器來執行集成構建,天天要執行屢次構建。

5. 每次構建都要100%經過。

6. 每次構建均可以生成可發佈的產品。

7. 修復失敗的構建是優先級最高的事情。