在前一篇講Capital One如何成功進行DevOps轉型的文章中，我提到了他們公司總結出的DevOps轉型目標是“Delivery High Quality Working Software Faster”，即更快速地交付高質量的可工作系統。

其中的“可工作”是指跨產品線、共享服務和依賴的第三方，確保系統端到端必須可用。持續交付和DevOps的難點問題之一就在于跨系統，尤其是銀行這類多個復雜系統共同協作的場景下，如何做好系統間的對齊，如何更有序的發布版本，是整個交付過程中非常關鍵的環節。

今天我們就來談一下大型復雜系統中如何發布管理的模式和技術。

▌常見的發布管理模式

常見的發布管理模式主要有以下幾種：

項目發布模式

發布窗口模式

發布火車模式

持續交付模式

1 ▏項目發布模式

一般來說，所謂項目就是指在一定約束條件下（主要是限定資源、限定時間、限定質量），具有特定目標的一次性任務。

目前很多大型企業的系統開發還是按照項目的模式開展，比如有時分為新建類項目（如新建系統）或延續性項目（如增強或優化系統），每個項目都需要完成從立項、項目啟動、項目實施到項目驗收等一系列較為完整的過程，實施流程繁瑣、參與人員眾多、普遍交付周期較長。

由于事先約定了項目所包含的需求或特性集合，當所有需求或特性全部開發完成，并通過驗收測試后，才能批量進行版本發布。過程中如果出現需求變更或某些需求交付遇到阻礙，常常會導致項目的延期發布。

另外，由于項目大小不一，發布周期不固定，缺少穩定的交付節奏，加之周期通常較長，可能導致項目交付的可預見性較差。

2 ▏發布窗口模式

發布窗口是指一個特定的時間段，在這個時間段內一個或多個團隊可以發布產品到生產環境。

發布窗口一般選擇系統負載較低的時候進行，盡管現在大多數應用系統的用戶都希望這些系統能夠提供7*24小時不間斷的服務。

在大型企業中，受到系統復雜度、研發流程和風險控制等因素的影響，常常選擇周期跨度較大的發布窗口，比如每季度一次常規投產、每個月一次常規投產，做的好一些的可以達到每兩周一次常規投產。

發布窗口模式的優點：

對業務部門及用戶：提供了始終如一的發布節奏；

對交付團隊：提供了始終如一的發布日期目標；

發布窗口模式的缺點：

少量的發布窗口需要同時集中處理多個團隊的發布需求，發布風險很高；

不同團隊爭搶有限的發布窗口，帶來大量溝通和協調成本；

不同系統之間存在相互依賴的情況，需要大量時間統一規劃和協調；

3 ▏發布火車模式

發布火車是指組成復雜系統的每個團隊都參與到統一發布節奏的“火車”中來。每列發布火車采用固定的“發車”時間，特性的發布取決于該特性是否趕上最近的火車發車時間。如果某個團隊錯過了發布日期，即錯過了這列火車，火車還是會按時發出，這個團隊可以等待下列火車的到來。

許多大型企業都在使用發布火車的發布模式，這種模式適用于不同團隊有各自負責的子系統或組件，但需要整體進行對齊和集成的場景。發布火車模式的提出最早是一些大型軟件公司組合不同的軟件產品，但近些年來SAFe等大規模敏捷框架的推廣讓發布火車模式更為流行。

當然，同樣是發布火車，不同場景下的展現形式可能不同。比如有的框架介紹發布火車一般8~12周完成一個大型產品的增量發布，有些企業實現的小型發布火車可以做到1~2周級別的發布（也有做的更快的，他們叫做班車模式）。

我們這里僅是從管理模式上和技術實現上考慮，發布火車可以實現多個子系統或組件團隊之間的高效協同，以及發布包的遞次晉級，我們討論的是一個廣義上的概念，具體的發布周期是可以按需求調整的。

發布火車模式的優點：

發布火車讓參與的團隊達成統一的發布節奏；

所有參與的團隊可以有效對齊該版本的各個實施階；

發布火車可以更有效的協調多團隊的發布；

火車的間隔周期通常可以設置的相對較短，即便錯過一列火車還可以等待下一列，緩解了爭搶發布窗口的問題；

發布火車模式的缺點：

統一的發布火車時刻表同時也約束了開發團隊，沒有做到持續交付；

如果發布火車間隔時間設置的很長，一樣會出現集成的瓶頸；

關于發布火車模式的具體實現細節方法，下文會進行詳細介紹。

4 ▏持續交付模式

持續交付是DevOps的核心工程實踐，也是眾多互聯網公司采用的交付模式。持續交付的思路是開發以小批量工作在主干上，或者每個人工作在短Feature分支上，有規律的合并主干。主干一直保持可部署狀態，可以做到通過一鍵式操作的方式在正常業務時段按需發布。

在流水線上，開發可以得到快速反饋，包括缺陷、性能問題、安全問題、易用性問題等，當問題被發現，他們快速修復，以保證主干一直保持可部署狀態。關于持續交付的實施框架和細節技術實踐，我曾經做過多次分享，但這并不是今天討論的重點，所以我們暫不展開。

持續交付可以做到行云流水一般，快速、按需發布到生產環境，相當于我們的發布窗口是7*24小時！以互聯網為代表的一些高績效IT公司，通過持續交付可以做到每天成千上萬次高質量的發布。但是，做到持續交付需要非常多的技術實踐，包括高度自動化的流水線，自動化構建，自動化測試，自動化部署，低風險的發布技術等等。

在大型復雜系統中實現持續交付，還需要考慮系統之間相互依賴的問題。正確的思路應該是讓架構盡量做到解耦，使得每個系統能夠獨立的開發、測試、部署和發布，而不依賴其他系統。每個系統獨立演進的過程中，可以通過契約測試的方式驗證相互接口的正確性，同時還需要實現服務提供方的向下兼容以及服務消費方的容錯性設計。

▌發布管理模式的綜合應用

我的經驗是很多傳統一些企業都在使用發布窗口模式或發布火車模式，但也都在積極嘗試持續交付的發布模式。通常引入敏捷和DevOps的方法和實踐都會促進發布頻率的提升和發布周期的縮短。

那么如何綜合應用以上幾種發布管理模式，取長補短，即能夠提升單個系統的發布效率，又能兼顧系統之間的依賴關系呢？這個是我們接下來要討論的話題。

1 ▏綜合應用的策略

我們需要根據發布頻率的實際需求來選擇和搭配不同的發布模式。

在上圖中，我們可以看到有不同類型的發布需求，比如Major Release（可能是產品級的功能整體升級），或者Subsystem Release（可能是某個子系統內部的功能優化），也有為了滿足特定合規性需求或解決線上問題的緊急修復等。

不同的發布需求對應了不同的發布節奏。首先我們要按特定的節奏規劃產品級增量發布，此時可以應用發布火車的模式；然后是在產品級增量發布的中間，規劃粒度更細的子系統級發布，以及穿插其中不定期的緊急發布，此時可以應用持續交付的發布模式。

所以我們提出的整體策略就是“按節奏開發，按需進行發布”。按節奏開發是指以固定的節奏安排產品級發布規劃，同步和對齊不同團隊之間工作，主動管理風險并限制非預期的差異；按需進行發布是指構成復雜產品的不同子系統或組件，可以各自按需靈活安排自己的發布活動，只要合理、合規就可以在任意適合的時間進行發布。

2 ▏發布火車的實現細節

發布火車的實現細節如下圖所示（引用自EXIN DevOps課程的TTT講師 Bart de Best）:

使用發布火車將發布包從構建狀態逐步發布到測試及生產環境。

發布火車傳輸的內容是發布包，而非代碼（曾經遇到有些團隊用發布火車模式來傳遞代碼，這種方式問題較多，而且不符合持續交付的單一制品原則）；

只有出示了“車票”，才被允許上火車；

“車票”是指有效的測試結果；

在發布之旅中有很多的“站點”；

“站點”可以理解為不同的環境（開發環境、集成測試環境、驗收測試環境、生產環境）；

每個站點上特定的“關卡”，指的是特定環境上不同級別的測試；

火車會一站接一站的運行，從開發到測試，從測試到驗收，從驗收到生產，遞次運行；

每列火車有一個火車司機，火車司機就是發布經理；

火車司機（發布經理）負責判斷是否可以上車，除了檢查是否有車票，還要關注系統間的依賴和沖突；

如果發布包沒有趕上這列火車，或者有Bug，將會被放置在站點上等待；

直到修復Bug、通過測試（取得車票），并且滿足依賴之后，才能通過關卡，并搭乘下一列到達站點火車，奔向下一站；

下圖形象的展示了整個過程：

3 ▏發布模式的支撐技術

為了做到更快速、更穩健的發布，僅僅引入相關的方法是不充分的，還需要在自動化發布技術、架構解耦、可部署性、可靠性、快速恢復能力等方面進行建設。

除此之外，以下技術實踐的使用有助于實現更為靈活的發布模式：

功能開關

功能開關打開或關閉，可以控制在生產環境上的功能是否對最終用戶可見。比如剛才提到的多種發布節奏混合的場景下，可能需要采用多分支的模式匹配不同的發布版本。

使用功能開關的技術，就可以轉變為主干開發模式，并有效規避并行多分支的問題。如下圖所示，Spotify公司在使用發布火車模式時，利用功能開關把未完成功能在發布時做隱藏處理，這樣可以盡早暴露集成問題、最小化對并行分支的需求，并降低發布火車模式下分支管理的復雜度。

金絲雀發布

在發布變更到所有用戶之前，可以先發布到一小部分用戶，降低直接發布到生產環境所帶來的風險。

比如依次發布變更的功能到10%、20%、50%的用戶，并在每個節點驗證一段時間，最后再進行全量發布。在發布火車模式中，對生產環境的發布可以按金絲雀發布的模式，拆分為數個更小的發布階段來控制風險，如下圖所示：

▌總結

今天我們介紹了幾種常見的發布管理模式，在不同場景下綜合應用這些模式可以在更快速地交付高質量的可工作系統。

發布管理模式的一些核心要點如下：

策略：按節奏開發，按需進行發布；

可以根據發布頻率的實際需求來選擇和搭配不同的發布模式；

發布火車模式可以更有效的協調大型復雜系統多團隊的發布；

持續交付模式實現更頻繁的發布，前提是建設高度的自動化能力及復雜系統間充分的解耦；

發布火車模式下，傳輸的內容是發布包，而非代碼。只有出示了“車票”，才被允許上火車。每個“站點”上設有特定的“關卡”，火車按站點遞次運行，每個站點由”火車司機”負責團隊間對齊的工作；

配合使用功能開關和金絲雀發布技術實踐，可以讓發布模式更靈活并降低發布風險。

今天分享的內容可能略微復雜，整理起來也花費了我不少時間，但最終還是希望能對你有所幫助！

心動不如行動，綜合運用以上方法與實踐，讓你的產品發布能夠像高鐵一樣穩定的飛馳吧！

想了解更多IT資訊，請訪問中培偉業官網：中培偉業