Jenkins 就是常說的 CI 平臺（持續集成）。持續集成(CI)是一種實踐，可讓團隊在持續的基礎上收到反饋並進行改進，沒必要等到開發週期後期才尋找和修復缺陷。java

改進確定是本身改進，反饋是誰提供呢？python

最早應用在開發團隊中，也就是「打包」。大型項目都是 Java 寫的，它會遇到一些依賴包缺乏了，語法寫錯了，引用的依賴文件沒有或者依賴文件的函數被其它開發改了。git

這個狀況下去打包，就必定會打包失敗而且完整告訴你哪一個文件哪行代碼出了什麼錯。開發人員在收到錯誤反饋後就會修改代碼而後從新打包。這個就是儘早得發現它的問題，因此就是 Jenkins 發郵件的形式來反饋的。web

沒有 Jenkins 平臺的時候有這些問題遇到：

Bug 老是在最後才發現（必定要提交到測試纔會發現比較嚴重的 bug，在開發階段可能發現不了）
越到項目後期，問題越難解決
軟件交付時機沒法保障
程序常常須要變動（前期不怎麼改問題，到後面要上線了沒辦法，加班加點改，改完測試就得測）
無效的等待變多

長期得開發過程當中無人監控，只構建打包沒法保證產品質量。Jenkins 的定時任務在固定的週期內檢測代碼Jenkins 作全方位的質量監控。shell

版本管理提交代碼，同時也要下載到本地更新一下。這個過程當中開發是有不少個的：安全

可能出現 2 我的都要更改這個文件。或者我更改 A 和 B，可是個人 A 當中是有引用 B 的。我天天都要提交代碼。既然有這麼多人向版本管理系統提交代碼，我須要檢測下他們的代碼可否能正常打包成一個文件，有沒有引用的錯誤，語法的錯誤，有沒有缺依賴包等等，這個都是經過將文件編譯打包。服務器

編譯是將它打包成.class文件，這個文件更好得讓機器執行。編譯成.class文件得時候，假如文件 A 裏面引入了文件 B，那麼在編譯得時候全部依賴得第三方庫以及外部文件必須都能訪問獲得而且正確才能編譯成功。微信

打包很簡單，重要得是編譯過程。打包包含了編譯。天天都去編譯打包，天天都能發現問題。框架

1.開發階段

靜態代碼檢測是個什麼意思？

經過 Jenkins 平臺來自動對代碼進行靜態檢查。sonarQube 能夠作這些事，它能夠幫你發現基本的語法規範出錯了和安全隱患問題。運維

1.什麼是靜態代碼？

就是你的源碼，就是在 svn 上面下載下來的源碼庫。去解析處理，若是這些都經過了就上線，沒經過就修改你的代碼。

sonarQube 能夠和 Jenkins 完美得集成。sonarQube 會掃描出來究竟是誰寫的代碼。哪個文件，哪一行存在安全隱患。是什麼安全隱患，應該如何修改以及哪一行代碼有這個語法規範問題。請及時修改。

2.什麼語法規範？

重複度。 作一個大型的系統講究分層設計，下降它的重複度，提升它的靈活度。若是給一個項目的代碼給我，我掃描出來達到 50%的重複度。重複度過高就意味着很是得不靈活，通用共享作的太少。sonarQube 會給出提示，很明白告訴你，哪些文件的多少行是重複的。

就須要召集開發團隊趕忙把問題改改，將重複度降下來。

複雜度。 若是一個函數或者一個類裏面的複雜度過高（for 循環，if else，for 循環不宜作的太深，2 層就夠了。3-4 層，再下去複雜度就過高）。複雜度越高就意味着這個函數太難懂了，問題的可能性也很是大。

若是複雜度偏高，那你就要想辦法將這個偏高的函數想辦法將它簡單化，下降它的複雜度，這樣它的流程以及 bug 方面就不會有那麼多。sonarQube 會從全方位的角度幫你檢測你的整個項目在代碼層面有哪些問題須要你去改。

sonarQube 會集成單元測試、自動化測試。還能夠檢測自動化代碼的覆蓋率。它不分語言，python、java 等都是能夠作的。每一種語言都有對應的規則庫，你都是能夠下載的。自動化代碼也是代碼，你拿它去掃一掃，同樣會給你個結果。

在正式編譯打包以前，把靜態代碼檢查先作了。若是儘早介入，不是等代碼所有開發完成才介入。

定時來作這 2 件事：

能夠從開發層面很好地把控代碼質量。既然加入了 Jenkins，就會有郵件通知也會有報告展現。開發人員能夠每週作一次總結並處理。

能夠經過 Jenkins 再作單元測試，這個須要開發人員本身配合了，他們本身寫了單元測試代碼，咱們才能將單元測試代碼集成到 Jenkins 平臺。若是開發不寫，咱們怎麼測呢？

先作完靜態檢查，將它編譯打包後，對打包後的代碼進行單元測試，這個從總體的代碼層面不是從業務層面，而是你代碼的優質程度。單元測試從本身寫的業務函數層面、系統功能層面，來自我檢測一下這個有沒有問題。

開發代碼迭代： 每個星期給測試轉一個測試版本，這個版本應該作單元測試。那麼下一個星期，在歷史的長河中，在軟件開發的 2 年當中，逐步加內容改內容的時候必定會影響歷史模塊。

若是在這個過程當中，你開發的每個模塊都帶了單元測試，每次你轉到測試以前所有都作次單元測試。若是你改了加了新的代碼，影響了舊的代碼可是你沒有改，單元測試立刻就會暴露出來。

開發人員在自個人層面來控制代碼的質量，這就不用等到測試告訴你這個功能明明是好的，爲何到了這個版本又掛了？你在單元測試階段就會發現。

可是，國內的場景是沒有多少開發有作單元測試的意識。即便有的開發有這個想法，時間上也不容許。開發任務過重了，致使功能層面的代碼質量所有壓在了測試的身上。可是測試工程師不是萬能的，不少隱藏的問題，尤爲是開發層面的大 bug，咱們通常是看不到的，除非是有些狀況把它觸發出來了。

因此這 3 個角度，是從開發人員業務和代碼質量水平兩個維度來把控代碼質量。若是開發人員能把這 3 件事作好，到了測試的手上，問題基本上已經解決了一大半，很流暢，即使你要新增什麼模塊，優化什麼的，在單元測試這個地方就直接暴露出來了。

2.測試階段

1.環境部署

首先，環境部署，多是測試作，可能不是測試作。環境有不少套：好比 DEV（開發環境）、SIT 環境(系統集成測試)、預發佈環境。

DEV 環境有 1 套，SIT 環境有 4 套，預發佈環境 1 套，一共 6 套環境。會有專門的環境管理人員，可是人家重點是服務器方面的維護。可經過 Jenkins 平臺作自動部署。 發佈、部署測試版本的時候不須要去找環境管理人員了，直接在 Jenkins 平臺上點擊觸發下這個工程構建就 Ok 了。

自動部署就是打包以後將這個包（這個包和 DEV 環境是同步的），將它部署到測試環境當中，而後解包出來。

測試包部署流程： 開發通常只部署本身的測試環境，測完包後給到測試。正式環境通常都是運維。通常部署可能部署到 Linux 服務器上，而咱們編譯打包是直接能夠在 Windows 機制上執行，固然也能夠在 Linux 機制上執行。

要下載最新的代碼將它打包，打包以後傳送到測試服務器上。在測試服務器上再去將這個包解壓到對應的路徑下面（前提是經過網址訪問將測試環境的服務停掉）。把這個包部署上去，更新代碼以後，再將這個環境啓動起來，完畢之後才能作測試。

若是想作這個事，先找開發好好了解下部署流程怎麼作的，就知道怎麼部署啦。部署完成以後就能夠作自動化測試了。部署過程當中會涉及各類操做，會涉及 python 腳本、shell 腳本，還用到上傳的軟件（vpm\ftp），全看本身公司內部是怎麼作的了。知道流程以後，再想一想每一步我用代碼如何實現。而後將這個代碼歸入到 Jenkins 步驟當中，一步一步去作。