Git+Docker+Jenkins持續集成

組成：

Git 做爲版本控制庫 

Docker 搭建測試環境 

Jenkins 做爲持續集成服務

Jenkins實現CI(Continuous Integration)到CD(Continuous Delivery)的轉換工具。

指望：

一、解決從開發–測試–上線等一系列環境統一及依賴問題 

二、可實現不停服務發佈上線和灰度(須要實現LB) 

三、可實現發佈回滾 

四、方便devops及運維操做

思路：

• 客戶或產品有新需求變動或者測試人員提出bug時，會提交事件到開發人員，開發人員獲得通知，會對開發分支作修改，項目會有不一樣的分支。

• 分支中會包含dev和master，開發人員拉取dev分支代碼，開發完成後push到dev分支及合併，通知測試人員部署到測試環境測試(Jenkins從Git拉取代碼實現打包構建，生成docker p_w_picpath所須要的文件，push到鏡像倉庫，而後部署到測試環境cc)

• cc環境測試無問題後，部署到tt和demo環境。

• 測試環境無問題後通知開發，開發發佈代碼到master分支(打tag),通知運維上灰度（Jenkins打包tag版本的鏡像而後push到鏡像倉庫），測試無問題後可上線。

• 客戶（線上）環境pull最新鏡像，升級現有鏡像。以下圖

流程圖:（來源網絡）

具體：

鏡像倉庫：會提供基礎的base版本的鏡像，此鏡像用於開發人員的自測和jenkins代碼鏡像的合併，生成新的鏡像，開發人員和jenkins會提供相同的生成鏡像的dockerfile文件，保證程序環境的統一。

鏡像倉庫將包含 dev：tag 測試鏡像  master：tag 生產鏡像

Jenkins：會創建 build-dev、build-product、cc測試環境、tt測試環境、demo環境等項目，用戶權限管理對應負責項目。

         build-dev：構建測試鏡像，會從Git dev分支拉取代碼打包，構建鏡像dev:tag,成功後push到鏡像倉庫中。

         build-product：構建生產鏡像，會從Git master分支下的某個tag拉取代碼打包，構建鏡像product:tag,成功後push到鏡像倉庫中。 

         cc測試環境:獲取到最新構建的dev鏡像到cc機器，更新現有的鏡像。

         tt測試環境和demo環境：同cc環境

Git: 版本控制，分支dev 分支master及master 下各個版本的tag 

此方案是基礎版（有部分細節並未考慮到），涉及到重複測試過多，後面可用Selenium前端測試，postman+jenkins API測試或其餘工具實現自動化測試，暫時先實現有無問題，後續再優化改進。