1. 持續集成簡介

1.1 持續集成的作用

隨著互聯網的蓬勃發展，軟件生命周期模型也經歷了幾個比較大的階段，從最初的瀑布模型，到 V 模型，再到現在的敏捷或者 devops，不論哪個階段，項目從立項到交付幾乎都離不開以下幾個過程，開發、構建、測試和發布，而且一直都在致力于又好又快地完成軟件的交付。

然而大多數互聯網公司面臨的常態卻是，臨近上線日全員待命，如臨大敵，通宵達旦，生怕出現上線事故導致版本回滾，即使暫時上線成功后也可能會出現明明測試環境全部通過了，卻依然有各種線上質量問題頻發。這些現象的主要原因就是代碼合并的太晚，而且每次改動未經過充分的測試，代碼合并時出現沖突，為了解決沖突重新修改代碼，新修改的代碼又有可能會引發新的問題，進入了惡性循環。

那么如何才能快速地合并代碼，快速地構建，快速地測試，快速地發布高質量的代碼呢？持續集成就應運而生了，它的宗旨就是多次合并代碼，合并完成后在各種環境下進行多次充分的測試，保證版本的可用性和代碼更改的正確性。

1.2 持續集成的定義

我們經常聽到的持續工程方法有 3 個，分別為持續集成（Continuous Integration，CI）、持續交付（Continuous Delivery，CD）和持續部署（Continuous Deploy，CD）。

• 持續集成：指的是在一定時間內，開發人員多次將代碼合并到同一主干上。代碼入庫后將代碼編譯打包成可以發布的形式，先發布到測試環境進行詳細全面的測試（如果是代碼修復的情況下可以根據實際情況只進行精準的測試），測試環境通過后再發布到預生產環境，最終部署到線上環境。目的就是頻繁的集成以便發現其中的錯誤。
• 持續交付：強調的是短時間內完成可以隨時發布的軟件產品，對每一個進入主干分支的代碼提交后，構建打包，測試環境驗證通過，預發布環境進行驗證，保證產品是可發布的狀態。目的是快速地得到市場的反饋，以便更好地進行開發和設計。
• 持續部署：將每一次代碼提交后，都構建出產品直接上線，交付給用戶使用。

以上 3 個流程的本質都是為了保證每一次代碼合并后都能經過一系列的驗證，保證這些變更的質量。以下是 3 個持續過程的流水線示意圖：

1.3 持續集成的原則

測試要盡量得充分

因為持續集成最終的目的是保證版本的可用性，而且由于多人協作，合并后的代碼有可能對整個的軟件都會有影響，所以一般情況下需要把所有的測試流程都走一遍，比如靜態代碼掃描、單元測試、功能測試、接口測試、性能測試等等；如果只是修復了一些 bug，代碼改動不大的情況下，可以只做一些針對性測試。

測試的速度要盡可能得快

持續集成中每天都會有代碼合并，甚至一天有好幾次合并，如果測試的效率不夠高的話很可能會出現一個打包的版本還未測試完成，新的版本就已經出現了，甚至積壓幾個版本，這樣的話就不能及時的發現是哪個版本出現的問題，而且開發一直是在有問題的版本上進行的修改，所以這就要求測試的速度要快，自動化測試肯定是不可或缺的，甚至還要并行或者分布式執行測試。

盡量使用和生產環境類似的環境進行測試

如果持續集成采用的測試環境和線上環境差異太大的話，測試的結果很可能是不準確的，有些線上的問題也是很難發現的，特別是關于性能測試的結果，資源和鎖等問題。所以采用和線上環境完全一樣的環境時最理想的，如果條件不允許的話要盡可能采用同比例縮小的環境進行測試，以保證測試結果的準確性。

1.4 整體流程

 

2. 持續集成環境搭建

Win10 + Jenkins 2.277.2 + JDK 1.8 + Maven + Git + Tomcat

2.1 Git 安裝

1）登錄官網下載安裝包：官網 https://git-scm.com/download/win

2）下載完成后雙擊安裝，如下圖所示：

雙擊 exe 文件，一路 next 即可。

3）配置環境變量：將 Git 的 bin 目錄 添加到環境變量。

4&#