持續集成

開發中，我們經常遇到一些奇怪問題，比如本地可以編譯成功的代碼但是同事們更新代碼后編譯出錯，或者在項目有多個Target的時候，資源文件只添加到了當前的Target，另外一個Target這個時候是不能正常編譯的，再比如寫的工具類，被同事改了，或者自己有改動，很多地方用到了，怎么保證這個類的行為沒有發生變化而影響到項目中的其它模塊呢？諸如此類。

那么這些問題原因在哪，可否避免呢？當然是可以避免的，如果代碼有新的改動，提交到版本庫中的時候，有一個人幫我們檢查必要事項，然后做做測試不就好了，這個當然是可以的，前提是老板同意專門招一個這樣的人。

引起各種奇怪問題的原因有很多，比如開發環境比較復雜不干凈，IDE的bug，提交前有一些必要的檢查需要做，但是開發時因為各種原因沒做，這些機械重復的事情我們可以找一個工具來幫我們完成，而且這個工具跑在一個專門的服務器上，該服務器環境相對干凈，可以運行一些自動化操作，而自動編譯，代碼檢查，測試等環節，那么這種東西，就是接下來講的［持續集成］。

個人理解持續集成：為解決程序代碼提交質量低，提交內容導致原有系統的bug，按時或按需自動編譯版本，自動進行自動化測試。

百度的定義：持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡快發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。

［是什么］

持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通過每個成員每天至少集成一次，也就意味著每天可能會發生多次集成，每次的集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡早發現集成錯誤。簡單來說，就是持續的定時的在多個團隊成員的工作中進行集成，并且給予反饋。

持續集成需要開發人員一天多次的將代碼集成到主干，并進行自動化編譯、測試等操作，由于這種頻繁集成，以及集成后及時開始的編譯和測試，可以有效避免我們在提交代碼時沒有進行必要檢查而導致的錯誤，以及一些超出預期效果的更改，從而保證代碼的質量。

由于這種及時性，如果在一次提交后項目集成失敗，可以快速的在這次提交中查找問題所在，縮小了找問題的范圍，從而減少了一些debug時間。同時如果按照這種實踐，那么我們的主干代碼時刻都是正確的，這樣我們可以更頻繁的交付。

［為什么］

一般規模較小的項目，對外部系統的依賴和服務調用很小，對于軟件的集成不是問題。但是隨著軟件復雜度的增加，對集成提出了更多的要求，持續集成的好處就體現出來了。

1）對重復的編譯發布等操作進行抽象，減少重復過程。

2）及早發現各種沖突和錯誤，減少風險。

3）任何時間、任何地點生成可部署的軟件

［怎么做］

基本要求：要將這種實踐付諸實際，需要一些必要的條件，如下

1.一個自動構建過程，包括自動編譯、分發、部署和測試等

2.一個代碼存儲庫，即需要版本控制軟件來保障代碼的可維護性，同時作為構建過程的素材庫。

3.一個持續集成服務器。

自動化構建成過程，可幫助我們節省大量時間，完成這個過程的自動化后，在以后的開發過程中，我們需要做的，就是只是提交代碼到版本庫中，構建自動完成，基本不再需要人工干預。

代碼倉庫作為構建的素材庫，構建所需的代碼從代碼庫中獲得。

最好有一臺服務器單獨作為持續集成服務器，一方面保證了環境的純凈，一方面不影響開發，而且持續集成服務器一般是隨時準備開始構建的，所以一般也不關機。

1［首先要有統一的代碼庫，服務器不斷從版本控制服務器上檢查代碼狀態，看代碼是否有更新。如果發現有代碼更新，那么就從版本控制服務器下載最新的代碼。等代碼完全更新以后，調用自動化編譯腳本，進行代碼編譯。然后運行所有的自動化測試，并且進行代碼分析。如果其中任何一個步驟失敗，就表示build失敗，持續集成服務器會給予響應的反饋。每次代碼提交之后，都會在持續集成服務器上觸發一個定時構建，然后進行編譯、部署。］

［原則］

1.開發人員必須及時向版本控制庫中提交代碼，也必須經常性地從版本控制庫中更新代碼到本地；

2.需要有專門的集成服務器來執行集成構建。根據項目的具體實際，集成構建可以被軟件的修改來直接觸發，也可以定時啟動，如每半個小時構建一次；

3.必須保證構建的成功。如果構建失敗，修復構建過程中的錯誤是優先級最高的工作。一旦修復，需要手動啟動一次構建。

4.不更新構建失敗的代碼

開發人員及時的提交代碼進行構建是符合上述實踐的，及時拉取代碼可以防止工作中的分支偏離主干分支太多。定時觸發構建或者通過檢測代碼的修改情況在觸發構建都是可以的，主要是根及時的構建新的代碼。如果構建失敗，則必要及時處理導致失敗的問題，修復后重新構建。當然構建失敗的代碼就不要拉到本地了，會污染一個本來是可以運行的工作區。

［持續集成工具］

講了這么多概念，有沒一種工具把這種實踐實現呢？當然有，常見的持續集成工具如下：

jenkins

travis

gitlab

buddybuild

僅列舉了一些典型的，Jenkins 是傳統型的工具，前身是 Hudson，04 年到現在已經有十多年的歷史，后幾個是最近幾年出現的新一批，多少都和容器技術有點關系，這里我們主要介紹 Jenkins，因為這個工具比較常用，各種開發實踐都可以通過大量的插件來組合實現，可定制性好很多。

jenkins

1jenkins是一個開源項目，提供了一種易于使用的持續集成系統，使開發者從繁雜的集成中解脫出來，專注于更為重要的業務邏輯實現上。同時 Jenkins 能實施監控集成中存在的錯誤，提供詳細的日志文件和提醒功能，還能用圖表的形式形象地展示項目構建的趨勢和穩定性。— 維基百科

Jenkins 有哪些功能呢？

1.定時拉取代碼并編譯

2.靜態代碼分析

3.定時打包發布測試版

4.自定義額外的操作，如跑單元測試等

5.出錯提醒

基本上都是持續集成實踐中的要求和周邊的一些實現措施，如提醒功能等，出錯后及時提醒開發者修復，Jenkins 中通過配置 SMTP 配置信息（這個一般的郵件服務提供商都有提供），郵件模板等，創建事件觸發器，在事件（如編譯失敗）發生時，及時發送郵件通知開發者，挺方便的。

Jenkins 有很多種觸發構建的方式，如 webhook，定時更新代碼等，同時可以在觸發構建后執行自定義的構建操作，通過編輯自定義的構建腳本，幾乎可以進行任何構建操作。

圖片理解：

1）齒輪：如果將java/maven/ant/git/tomcat/jenkins等軟件比喻為齒輪，如下圖

2）兩個軟件在一起可以驅動另外一個軟件，如下圖

3）如果把這些軟件要集成在一起工作，那么這個軟件就可以存在其他軟件的中間來驅動各個軟件工作，如下圖：

4）jenkins就是類似中間那個齒輪，來驅動其他軟件的集成一起工作，如下圖

jenkins是一個開源軟件項目，旨在提供一個開放易用的軟件平臺，使得持續集成編程可能。它的前身是hudson，是基于java開發的一種持續集成工具，它可以根據配置進行持續定期編譯，運行相應的代碼，將運行結果發送至郵件或者展示成報告等。

jenkins作為持續集成的標志性工具，自然是有了持續集成的眾多優點。jenkins可以做一些自動化的build，只要我們把jenkins搭建成功，可以設置幾分鐘build一次，在定時自動build，驗證單元測試，如果發生錯誤則把錯誤報告以email形式發送給項目模塊負責人。

［宏觀理解］

先來張圖，大致理解下宏觀：

詳細介紹：

至于關于郵件的配置，也是為了方便我們的開發和管理，jenkins很強大。

講到這里，還是“啊呀呀，完蛋，還是有點不懂“的話，不如直接甩圖（從網上copy下來的）：

這里是選擇Gitlab作為git server。Gitlab的功能和Github差不多，但是是開源的，可以用來搭建私有git server，也提供非常強大的web GUI，比如開發者互相review源代碼的時候就會很方便。

系統的工作流程大概分為以下幾步：

1> 開發者將新版本push到git server （Gitlab）。

2> Gitlab隨后觸發jenkins master結點進行一次build。（通過web hook或者定時檢測）

3> jenkins master結點將這個build任務分配給若干個注冊的slave結點中的一個，這個slave結點根據一個事先設置好的腳本進行build。這個腳本可以做的事情很多，比如編譯，測試，生成測試報告等等。這些原本需要手動完成的任務都可以交給jenkins來做。

4> 我們在build中要進行編譯，這里使用了分布式編譯器distcc來加快編譯速度。

notes

jenkins的工作原理是先將源代碼從gitlab中拷貝一份到本地，然后根據設置的腳本進行build。我們可以看出，整個系統的關鍵就是那個build腳本，用來告訴jenkins在一次集成中需要執行的任務。

不過我之后是用的Github作為git server。但其實差不多，先講到這里，重點難點還是在之后jenkins的安裝配置使用上。