暫且抛開業界非常流行的devops理念，單純地從研發團隊來看，如何快速的釋出對使用者有價值的軟體是重中之重。
那結合持續內建，我們又可以做些什麼呢？
先來看看我們持續內建的現狀
獨立的建構：持續內建往往就是對目前最新的代碼做一些自動化的測試，而完全忽略了軟體版本的管理，甚至不能很好的保證各種測試是否是基于同一份代碼
輔助手段：持續內建往往作為一種測試的輔助手段，更多的是用于快速發現代碼送出階段的錯誤
以上這些在持續內建初期完全沒有問題，而且這種方式也的确帶來了不少的價值，能夠幫助團隊更透明地了解産品的品質，并且快速的定位和解決問題。隻是，我們可以做的更多
再來展望下持續釋出的流程
整體的思路就是以持續內建流水線作為核心，把軟體釋出的各個環節透明地展示給團隊，并且通過流水線來管理版本的釋出流程
測試環境整合：打通持續內建環境/手工測試環境/線上模拟環境，保證一條流水線上使用同一份代碼，同一份建構物
測試流程整合：一鍵式的環境部署和一鍵式的版本管理（打tag，拉分支，建構物的存儲等），釋出前對産品品質有清晰的了解
重要和主要手段：以持續釋出流水線為基準，并積極拓展其他類型的測試
把持續內建融入到産品開發和釋出階段，而不是簡單地搭建一套“自動化運作任務”，并充分利用建構流水線實作流程和品質的雙重把控
最後來看下某個産品初步定義的持續釋出的流程
産品現狀
持續內建狀态
新功能測試在手工測試環境下進行
上線前需要線上上模拟環境進行性能測試和穩定性測試
持續釋出流水線
持續內建環境實時保證目前的送出沒有破壞基本功能
通過手工觸發（qa人員控制），一鍵部署産品到手工測試環境并能在流水線上展示手工測試結果（通過簡單的設定一個變量達到效果）；同時可以選擇觸發功能測試，達到同步的執行
如果qa人員認為目前測試版本可以達到内部釋出要求，可以一鍵打tag，并生成和存儲dist包
通過手工觸發（qa人員控制），一鍵部署dist包到模拟線上環境，而後自動化進行性能測試和穩定性測試
理想狀态這步應該是自動觸發，由于目前機器的不可獨占性，暫時隻能手工觸發
自動化的性能測試和穩定性測試還是實施中
最終版本的對外釋出也是通過手工觸發（qa人員控制）
以上的流程是根據項目/産品的需求和現狀制定的，隻是一些思路可以借鑒，具體的實施一定要結合實際情況，因地制宜的開展
jenkins持續釋出流水線
幾個jenkins持續釋出流水線配置小tips
通過buildnamesetterplugin顯示當次流水線建構的版本（svn revision或是git revision）
通過parameterizedtriggerplugin自動觸發下遊任務，并把建構版本資訊傳遞下去
通過copyartifactplugin用于建構物的部署
通過buildpipelineplugin手工觸發某些任務，用于需要人工介入的階段
最新内容請見作者的github頁：http://qaseven.github.io/