前言

之後的工作中會負責版本控制與釋出，所以根據現有的邏輯整理一下持續整合與釋出的流程。
首先，持續整合，持續釋出，這個概念通過這篇文章有個大致的瞭解https://yq.aliyun.com/articles/72400
自己總結了一下，對於傳統的開發模式，一般使用的程式碼管理工具是svn，svn放置於一臺伺服器中，每次從svn中down下來最新的程式碼，修改後上傳到伺服器。但是若大幅度提交導致伺服器掛掉，會導致程式碼的缺失等問題；另外，傳統的開發模式，多數在開發完成之後，再進行測試，測試通過一輪手工測試後，部分公司會在上線前進行一輪迴歸測試。
這樣的問題，顯而易見，專案週期延長，人力成本過高。

流程

一張圖片來看一下，現在的工作流程：
首先，分為3個環境：
集測環境：程式碼遞交–靜態檢查—單元測試–介面測試等
預上線環境（灰度釋出）：在registry節點打包—生成image映象，利用上線環境資料測試–介面測試、效能測試等
上線環境：使用預上線環境的image

開發階段

1.團隊成員工作在develop分支上，develop分支只允許提交將在下個版本釋出的程式碼
2.提交到develop分支的程式碼要求是可以工作的程式碼，不能導致程式碼構建失敗
3.Jenkins監控develop分支程式碼更新，進行docker映象構建，並更新到集測環境，產品經理可以在集測環境看到最新的開發進展
4.對於不在下一個版本釋出的特性，應fork獨立的feature/xxx分支進行開發，在下一個release/x.x版本fork之後再merge到develop分支

預釋出

1.預釋出條件：develop分支已經包含本次釋出的所有特性，且集測環境驗證通過，進入預釋出階段
2.假設待發布的版本號是： 1.0，從develop分支fork出release/1.0
3.使用Jenkins的yuce_release專案生成構建，填寫本次構建的版本號：1.0，構建生成待預釋出的docker映象
4.進入預釋出環境，同步生產資料庫到預發資料庫，按需升級預發資料庫（可選），使用預釋出的docker映象更新預釋出環境，進行預釋出環境的驗證測試
5.驗證測試期間，若發現bug，則在release分支上進行修復，並將改動merge回develop分支，重複3-4-5

釋出

1.釋出條件：團隊成員確認預釋出環境驗證通過，進入釋出階段
2.進入生產環境，備份生產資料庫，按需升級生產資料庫（可選），使用預釋出驗證過的docker映象，更新生產環境，進行生產環境的驗證測試
3.團隊成員確認生產環境驗證通過，至此本次釋出完成

另外以上基於自動化測試很完善的情況。在沒有自動化測試時，很難做到對質量的控制。目前企業級比較認可的覆蓋率是75%左右。其次是看漏測率，有時候自動化用例本身也可能有Bug，前期階段通過比較手動測試自動化測試的結果來判斷自動化測試是否有效。（–引自熟悉概念的那篇文章）

所以，自動化測試方面，任重而道遠