閱讀字數：2380 | 4分鐘閱讀
摘要
釋出作為應用上線前的最後一個步驟，一直以來都是運維做的比較頻繁也是風險比較高的操作，釋出系統不僅要做到提升釋出效率，更重要的是保障釋出過程中系統的穩定，減少因釋出導致的故障。本次演講主要講述美聯的釋出&持續整合系統的演進以及在提高發布效率，保障系統穩定上的實踐。
釋出系統的演進
釋出系統的演進在一定程度上代表了運維體系甚至是公司技術架構的演進。
技術架構-早期(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機器執行效能壓測。
我今天的分享就到這裡，謝謝大家！