持續集成作為一種很好的軟件工程實踐被很多團隊所采用，和其他一些先進的實踐一樣，它最終的目的一定是服務于產品的。產品的價值最終體現在用戶體驗的提升，而這個的前提就是產品的每一次更新能夠及時地傳遞給用戶，對于運維團隊來說就是更快地在生產環境中部署最新的產品，對于研發團隊來說就是更頻繁地發布可以
工作的軟件。
暫且拋開業界非常流行的DevOps理念，單純地從研發團隊來看，如何快速的發布對用戶有價值的軟件是重中之重。
那結合持續集成，我們又可以做些什么呢？
先來看看我們持續集成的現狀
獨立的環境：持續集成往往有一套獨立的
測試環境，而團隊還會在其他測試環境中進行測試，兩者似乎從來沒有交集
獨立的構建：持續集成往往就是對當前最新的代碼做一些自動化的測試，而完全忽略了軟件版本的管理，甚至不能很好的保證各種測試是否是基于同一份代碼
輔助手段：持續集成往往作為一種測試的輔助手段，更多的是用于快速發現代碼提交階段的錯誤
以上這些在持續集成初期完全沒有問題，而且這種方式也的確帶來了不少的價值，能夠幫助團隊更透明地了解產品的質量，并且快速的定位和解決問題。只是，我們可以做的更多
再來展望下持續發布的流程
整體的思路就是以持續集成流水線作為核心，把軟件發布的各個環節透明地展示給團隊，并且通過流水線來管理版本的發布流程
測試環境整合：打通持續集成環境/手工測試環境/線上模擬環境，保證一條流水線上使用同一份代碼，同一份構建物
測試流程整合：一鍵式的環境部署和一鍵式的版本管理（打TAG，拉分支，構建物的存儲等），發布前對產品質量有清晰的了解
重要和主要手段：以持續發布流水線為基準，并積極拓展其他類型的測試
把持續集成融入到產品開發和發布階段，而不是簡單地搭建一套“自動化運行任務”，并充分利用構建流水線實現流程和質量的雙重把控
最后來看下某個產品初步定義的持續發布的流程
產品現狀
三套環境：持續集成環境（云主機），
手工測試環境（云主機），線上模擬環境（物理機）
持續集成狀態
自動化的編譯，打包，部署，冒煙測試和快速
性能測試已經實現自動化并實時通過代碼提交觸發，全程20分鐘左右
單元測試和靜態代碼檢查還在完善中，也實時通過代碼提交觸發，不過沒有列入關鍵點，也就是成功與失敗并不直接影響構建流程
新功能測試在手工測試環境下進行
上線前需要在線上模擬環境進行性能測試和穩定性測試
持續發布流水線
持續集成環境實時保證當前的提交沒有破壞基本功能
通過手工觸發（QA人員控制），一鍵部署產品到手工測試環境并能在流水線上展示手工測試結果（通過簡單的設置一個變量達到效果）；同時可以選擇觸發功能測試，達到同步的執行
如果QA人員認為當前測試版本可以達到內部發布要求，可以一鍵打TAG，并生成和存儲dist包
通過手工觸發（QA人員控制），一鍵部署dist包到模擬線上環境，而后自動化進行性能測試和穩定性測試
理想狀態這步應該是自動觸發，由于目前機器的不可獨占性，暫時只能手工觸發
自動化的性能測試和穩定性測試還是實施中
最終版本的對外發布也是通過手工觸發（QA人員控制）
以上的流程是根據項目/產品的需求和現狀制定的，只是一些思路可以借鑒，具體的實施一定要結合實際情況，因地制宜的開展
Jenkins持續發布流水線
幾個Jenkins持續發布流水線配置小Tips
通過BuildNameSetterPlugin顯示當次流水線構建的版本（SVN revision或是Git revision）
通過ParameterizedTriggerPlugin自動觸發下游任務，并把構建版本信息傳遞下去
通過CopyArtifactPlugin用于構建物的部署
通過BuildPipelinePlugin手工觸發某些任務，用于需要人工介入的階段