摘要
釋出作為應用上線前的最後一個步驟，一直以來都是運維做的比較頻繁也是風險比較高的操作，釋出系統不僅要做到提升釋出效率，更重要的是保障釋出過程中系統的穩定，減少因釋出導緻的故障。本次演講主要講述美聯的釋出&持續內建系統的演進以及在提高釋出效率，保障系統穩定上的實踐。
視訊内容
釋出系統的演進
釋出系統的演進在一定程度上代表了運維體系甚至是公司技術架構的演進。
技術架構-早期(2011-2013)
最早期的開發語言是PHP，最流行的開源運作環境是LNMP，代碼管理是SVN。
最開始的是人肉釋出，後來有了PHP主站釋出系統。它能代替人肉進行釋出和操作，支援檔案釋出，有了復原的功能，還有最簡單的審批操作。
業務架構-中期(2014-2015)
到了2014年，我們的業務架構有所調整，建立了自己的交易平台。
開發語言變成了JAVA，運作環境是TOMCAT，代碼管理用的是GIT。
業務系統改成JAVA以後對釋出系統也提出了更多的挑戰。JAVA釋出和PHP釋出有很大差別，于是我們做了JAVA的釋出系統。
釋出系統也改為StarkPlus，需要支援更多的釋出類型、釋出模式，以及更多的釋出功能。
釋出系統的特點是支援類型多，有JAVA、C++、NodeJS、PHP、Golang、Css_js以及二方庫。
釋出政策也多，有分批釋出、分組釋出、流式釋出、自動釋出和自定義釋出。
功能多。原來的系統每次隻能釋出一個特定的分支，現在有一個應用多個分支并行開發的情況，是以我們需要多分支內建。
我們的應用又部署在多個機房，每個機房的配置可能都是不一樣的，建構也不同，是以需要多機房建構。
最開始隻有三套環境，後來慢慢發現三套環境已經不能滿足我們的研發需求，需要多套環境部署。
Docker是目前非常流行的一個容器，我們現在也有部分應用在Docker上面，要對Docker做一些支援。同時也支援Docker和KBM的混合釋出。
還有內建測試、安全掃描、性能壓測和jar包檢測，這些是其它業務團隊做的工具，我們把它們內建到我們的釋出系統中，來增強這些功能。
實踐之路
運維的基礎-标準化
首先要做好基礎軟體及配置标準化，OS、JDK、tomcat、nginx等等為運維提供了一套最标準的環境，所有的應用都跑在同樣的環境上。
應用本身配置的标準化，應用命名、配置管理，啟停腳本、檢測腳本、部署目錄、日志目錄這些有統一的标準。
我們提供了一個應用的模版，假如應用完全符合我們的标準，就不需要改動可以直接接入，但也有些特殊的應用可能情況會不一樣。
應用配置管理
應用類型配置可以使用我們的标準模版，也可以做一些自定義的功能，主要是人員角色、應用類型、啟停指令和軟體包資訊。其實它們內建在我們的釋出系統裡面，後來我們發現這些設定不僅僅是釋出系統要用，其它很多運維系統、業務系統都會用到。于是我們把它羅列出來單獨成立了一個配置中心。
上圖是我們釋出系統的一個依賴關系，裡面的一圈是它的核心依賴，CMDB管理伺服器，配置中心管理應用的配置，OpsAgent在每個機器上部署一個Agent，用來執行一些在伺服器上持續的操作。Gitlab做代碼管理，流程引擎用于審批内容。
外圍一圈都是用于增強我們的功能和一些外部依賴，有監控、安全掃描等等。
釋出系統架構非常簡單，主要就是兩部分，一個是JAVA前端，用來做頁面和流程控制。下面一個是用Pathon寫的一組worker，用于執行一些具體的操作，例如代碼的建構、合并、部署。中間通過一個MQ做任務隊列和解耦，它們之間通過DB來進行傳遞。
分支管理
上圖是我們的分支管理。所有的開發分支都是來源于master，在開發分支上開發完成将近釋出的時候，釋出系統會從master上拉出一個release，把feature分支一個個往上合，合完以後釋出這個release分支。release分支發到線上成功以後再把它合回到master，建立一個基線。
建立&導入變更
建立變更有兩種方式，一種是建立變更，就是從master上拉出一個新的分支；另一種是導入變更，已經有了從另外的開發分支上的一個分支，需要手動把這個分支拉出來進行導入。
內建&釋出
上圖是我們內建釋出的頁面。最上層是我們的三套部署環境；釋出的基礎資訊包括了應用名和目前釋出的分支名稱等；下面是我們釋出過程，釋出過程會根據應用類型的不同而有所差別；內建區的分支就是目前分支在釋出中，待內建區是已經開發送出了內建但是還沒有進行釋出。
進入線上
預發必須部署成功，內建區的checklist要全部通過。
代碼合并
手動解決在代碼合并過程中發生的沖突。Release分支更換政策就是新加入的分支或者修改feature分支代碼的時候，Release分支是不會變的，不用再解決第二次沖突。
不同應用類型的建構方式是不一樣的，而且建構是基于合并完成的Release分支，像JAVA、C++、GOLANG、NODEJS是放在一個Docker容器中進行建構，建構完成後會有産出。
健康檢查
每個應用都有健康檢查URL：/status
當通路/status時，檢查核心依賴（DB、cache、依賴應用），預熱資料。
執行成功傳回“SUCCESS”，其餘狀況均為失敗。
釋出計劃&審批
日常釋出是周一至周四工作時間，由主管審批；
正常緊急釋出在周五、周末，由研發D進行審批；
節假日例如法定節假日、營運商封網等，也是研發D審批；
特殊時期比如大促、集團釋出會等期間，理論上是不允許任何釋出的，如需釋出就需要通過CTO審批。
我們的特色
研發流程閉環
深度整合釋出系統與項目管理系統（PMO），需求、項目可以建立、關聯變更。變更釋出後可以通知到PMO的系統去更新需求和項目狀态，這樣就可以明确每次釋出的目的。
多機房、多分組建構
同一個應用在不同的機房有不同的配置，在不同的分組提供的服務也有差別。
線下&預發多套環境
因為需求多、變更多，是以部署變更非常頻繁，測試總是抱怨環境不穩定。大項目希望能獨占一套項目環境，解決環境的隔離。
Jar包檢測&Diff
Jar包沖突檢測：Jar包沖突會導緻莫名其妙的問題，難以排查。
Snapshot包檢測：Snapshot版本更新頻率高，不可控。
Jar包版本限制：已經廢棄的版本、有bug的版本不能被使用。
Jar包Diff：檢視本次釋出版本和基線版本的jar包差異。
穩定性
前端掃描：對于css_js的釋出做前端代碼品質檢測；
安全掃描：對java代碼做靜态安全性分析；
內建測試：預發環境釋出的同時執行單元測試、接口測試；
性能監控&壓測：線上beta釋出後對beta機器執行性能壓測。
我今天的分享就到這裡，謝謝大家！