阿里巴巴基於應用和變更的交付模式｜阿里巴巴DevOps實踐指南

雲效DevOps平臺發表於2022-01-26

編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：https://developer.aliyun.com/topic/devops，下載完整版電子書，瞭解阿里十年DevOps實踐經驗。

讓我們進入到阿里巴巴在交付階段的一些實踐，包括：

以應用和變更為核心的交付流程
基於變更的檢查項和卡點
針對應用特徵選擇研發模式

應用與變更

進入到具體的實踐之前，我們先介紹下阿里巴巴的應用和變更模型。

應用，是研發活動的載體，包括了程式碼庫、部署環境、配置項、變更管理、釋出流水線、運維等一系列要素。整個需求的開發交付過程都可以在應用中完成。應用上可以設定不同的角色，這些角色資訊在研發的各個環節中會起到作用。比如誰能釋出線上環境，誰有許可權修改測試配置等。

變更，作為應用的重要組成部分，是一個抽象的概念。所有對線上的行為的修改都可以稱之為變更，變更屬於某一個應用。變更中可以包含一個或者多個不同型別的變更內容，最常見的變更內容型別就是程式碼變更。

變更有相應的生命週期，一個典型的變更生命週期為：開發中->釋出中->完成。當一個應用有多個變更同時在開發和釋出時，需要有一定的協調機制，比如是在一個臨時的整合分支上進行整合，還是在一個常駐的 develop 分支上進行整合。我們稱這種分支協作模式為“研發模式”。

建立變更通常是為了實現需求和修復缺陷。一個需求可能需要修改多個應用，也就是需要在多個應用上建立變更，而簡單的缺陷修復可能修改一個應用就可以解決問題，也就是一個變更。所以工作項（需求和 bug）和變更是一對多的關係。

我們從兩個視角來看一下：

應用部署視角：每次應用部署上線會包含一個或者多個該應用的變更，可能涉及多個工作項。
工作項釋出視角：一個工作項的釋出可能需要多個應用的先後部署。
這兩個視角是有交叉的。作為平臺和工具，應該更關注哪個視角呢？
如果偏應用，則要完成一個工作項的釋出，開發團隊需要自行協調多個應用的部署順序，會產生一定的溝通成本。
如果偏工作項，則會出現一個工作項的一組變更在部署某個驗收環境，其他的工作項的變更需要等待，影響了整體交付吞吐率。
如果想要兼顧這兩個視角，則不可避免的需要使用大版本制，或者叫火車制，拉長了單工作項的交付週期。

阿里巴巴的 DevOps 工具選擇偏應用的視角，主要保證單個應用的部署上線流程和質量，將部署的節奏交給開發團隊靈活安排。

比如一個工作項的釋出涉及三個應用的三個變更，這個工作項的開發可以選擇在週一部署第一個變更，週二部署第二個變更，而這兩個變更不會造成任何線上可見的修改；到了週四，產品希望該功能上線時，再部署第三個變更，需求正式釋出。這種將部署應用行為與釋出功能行為分離的模式，可以降低集中部署帶來的風險。當然能夠這樣做的前提是需要有比較完善的自動化質量保障及卡點機制。

基於變更的檢查項和卡點

變更是交付的載體，因此可以通過在變更上承載檢查項來保證交付質量。最常見的檢查項包括：

是否通過程式碼評審
是否通過安全掃描
是否通過單元測試/UI 測試
基於這些檢查項會進行質量卡點，一般在如下的生命週期節點上：
從開發中進入釋出中：需要滿足一定的質量標準（比如單元測試通過率，覆蓋率等）之後，才允許進入到釋出中的狀態，能進入測試環境進行驗證。
釋出到某個環境上：這時變更已經進入了整合流水線，完成了構建等，但如果要繼續部署到某個環境，需要滿足更多的驗證條件。比如安全稽核需要通過，才能釋出正式等。

至於在哪些節點設定哪些卡點，應用負責人可以自行決定。多個檢查項建議儘早同時開始，以提高效率。

從另一個角度來看，釋出平臺也可以對所有應用進行全域性的卡點設定，針對某些卡點自動開啟，且不允許取消。比如掃描到你的程式碼中依賴了有安全問題的 JAR 包，則要求必須進行修復，否則無法部署上線。這樣就可以控制一些全域性性的風險。

變更和應用中的釋出流水線，提供了一個進行檢查和卡點的框架。具體的檢查工作由其它的專門的平臺提供，比如測試平臺、安全掃描平臺、與特定業務相關的合規掃描等。

研發模式

如前文提到，為了能夠讓一個應用的多個變更協同開發和釋出，我們需要採用不同的研發模式。研發模式的主要差別在分支合併策略，目前阿里巴巴主要採用下面三種研發模式：

主幹模式
Aone-Flow 分支模式
Git Flow 模式

應用有大有小，在其上進行需求開發的並行度也不相同。

阿里巴巴有大量的的應用沒有並行進行的變更釋出。這類應用適合使用主幹模式或者 Git Flow 模式。也有一些應用變更的併發度比較高，會出現一些釋出節奏不同的問題。業界一般使用功能開關的方式解決這個問題。阿里內部採用名為 Aone-Flow 的分支模式來解決。

在 Aone-Flow 的分支模式下，開發人員的典型工作流程為：

提交變更，Aone-Flow 會建立一個整合分支，或者複用已有分支，自動將你的變更合併到這個整合分支。
當你發現你的變更有問題不能釋出，可以“退出釋出”，Aone-Flow 會自動建立一個新的整合分支，把剩餘的需要繼續釋出的變更再合併進去。
當整合分支完成正式部署之後，會合併到 master 主幹上。這個整合分支上的變更都會被標記“已完成”，並打上 Git Tag。
當需要回滾時，可以根據系統的記錄同時將線上的版本和程式碼一起回滾掉（git revert）。避免出現無意把有問題的 master 程式碼釋出上線的情況。

關於 Aone-Flow 的詳細描述可以參看：https://www.infoq.cn/article/EaC4c6yiJrzZ_Gtaf9Ne

這裡僅就主幹模式和 Aone-Flow 進行一個簡單的對比。

	主幹模式/Git Flow 模式	Aone-Flow
對並行功能開發的支援	功能開關，成本高	進入/退出釋出，有可能出現重複解決分支之間的衝突的問題
對重構的友好程度	友好，修改了之後 push 上去即可	重構容易產生衝突，在 Aone-Flow 中會出現重複解決衝突的問題。解決方案就是儘快的把重構的變更釋出到線上，這樣才能合併到 master
對“快速上線”的友好程度	通過自動化測試的程式碼就會合併到公共分支（比如 master）。當需要進行釋出時候，就會把這些功能都發布上去，如果自動化測試不能給你足夠的信心，那麼釋出的風險就會提升，從而可能造成了大家不願意去頻繁釋出，或者成為一個火車版本模式。	由於釋出時候可以選擇變更，每個變更可以不受其他變更的約束，單獨儘快進行釋出上線，釋出風險比較小。另一方面，前面提到的“重複解決分支衝突”問題也會督促開發者儘快把變更釋出上線。