Jenkins介紹

持續集成：

持續集成是一種軟件開發實踐，即團隊開發成員常常集成他們的工做，經過每一個成員天天至少集成一次，也就意味着天天可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘早地發現集成錯誤。

1、引入持續集成測試：

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Bug 老是在最後才發現

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

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

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

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

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

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

4. 程序常常須要變動

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

5. 無效的等待變多

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

6. 用戶的知足度低

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

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

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

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

持續集成的優勢

1.統一的代碼庫

2.自動構建

3.自動測試

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

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

6.保證快速構建

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

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

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

10.自動化的部署

用什麼來實現集成？

Jenkins是一個開源軟件項目，旨在提供一個開放易用的軟件平臺，使軟件的持續集成變成可能。

什麼是jenkins？

Jenkins是一個開源軟件項目，是基於Java開發的一種持續集成工具，用於監控持續重複的工做，旨在提供一個開放易用的軟件平臺，使軟件的持續集成變成可能

jenkins的功能？

一、軟件的持續構建和測試

二、監視job的執行

三、項目源代碼修改的檢測

四、分佈式構建

節點配置：（代理服務器）

jenkins安裝在一臺機器，全部的jobs都在這臺機器上運行，若是超過太多jobs去運行，

會造成等待，節點存在就是解決這個問題提升效率，安裝jenkins的機器稱爲master機，

而其它機器就屬於master的分支，成爲slave；而要利用其它機器用執行jenkins的jobs，則須要一些配置，造成兩臺機器互通，固然下面的例子你用本機當作slave也是能夠的。

節點能夠理解爲一個代理，一臺服務器。Jenkins是一個ci(持續集成)平臺，每一個代理

服務器要與jenkins進行集成，須要執行java -jar ,後面是代理服務器Ip地址，經過這條

命令，執行成功說明代理已集成在ci平臺

觸發器是用於控制自動化測試執行時間的

日程表裏有5個數字，分別表明

格式：H /* * * *   (要空)

第一個*：分鐘：0-59

第二個*：小時：0-23

第三個*：日：1-31

第四個*：月：1-12

第五個*：周：0-7   0和7都表明星期天

* 指定全部有效的值

M-N 指定一個值的範圍

例如：

# 每隔15分鐘。(或許:07, :22, :37, :52)

H/15 * * * *

# 每前半小時中每隔10分鐘。 (3次, 或許:04, :14, :24)

H(0-29)/10 * * * *

# 每一個工做日從早上9點45分開始到下午3點45分結束這段時間內每間隔2小時的45分鐘那一刻。

45 9-16/2 * * 1-5

#每一個工做日從早上9點到下午5點這段時間內每間隔2小時之間的某刻。(或許在上午10:38, 下午12:38, 下午2:38 , 下午4:38)

H H(9-16)/2 * * 1-5