需求並行開發場景，如何高效發佈

1. 適用場景

微服務架構下，每個應用服務獨立開發、獨立發佈，小步快跑，持續快速交付業務需求。多人協同開發同一個應用時，分支開發模式是一個適合的協同方案。該模式下一個需求或任務通常對應一個 feature 分支，多個需求一起合併到 release 分支進行集成測試驗證併發布。

該場景下，你是否有這樣的苦惱？

• 一個需求沒有經過集成測試驗證，卻被髮布上線了，最終因爲“漏測”導致生產故障！
• 一個需求經過了集成測試驗證，但是臨發佈前發現有嚴重問題，但需求無法靈活“下車”，最終導致本次發佈的所有需求都被延期了！

2. 雲效解決方案

雲效應用交付平臺 AppStack 提供變更持續交付解決方案，涉及核心概念如下：

• 應用：一個軟件的最小發布單元，聚合代碼、環境、版本等軟件資產，以及研發流程定義。最小發布單元意味着無法解耦的一個或者多個服務的組合，這個服務組合會通過一個流程進行統一交付。
• 變更：變更是對應用的一次特性改變（引入新的特性或改變已有特性），源於需求，終於交付。通常一個需求或任務對應一個變更，對應一個 feature 分支。
• 研發流程：應用完成一次變更的過程和約束，包括開發、測試、發佈上線的完整流程，由多個階段的多條流水線承載，依次在不同環境進行測試、構建、部署，最終審批通過後發佈生產環境。

雲效通過應用定義、變更承載需求、研發流程約束髮布規範，來解決以下兩個問題：

• 問題1：當其中一個 feature 分支沒有經過測試驗證時，怎麼“阻止”它發佈到生產環境避免漏測引起故障？
• 問題2：當其中一個 feature 分支做了測試驗證，但是發現有嚴重問題，怎樣可以“退出”本次發佈而不影響其他需求正常發佈？

3. 雲效操作實踐

以下實踐，以一個spring-boot應用的“圖書館管理系統”爲例，開發“圖書借閱功能”、“圖書歸還功能”、“圖書到期續借功能”三個需求，一起發佈上線。

3.1 前提條件

已有一個應用 spring-boot，配置好應用代碼、研發流程（CI/CD流水線）、環境等。通常一個應用的研發流程可以分爲測試階段、預發階段、生產階段：

• 測試階段：由Java單元測試、Java代碼掃描、構建、部署測試環境等步驟組成。用於日常測試驗證。
• 預發階段：由構建、部署預發環境等步驟組成。用於預發佈驗證。
• 生產階段：由構建、生產發佈審批（人工卡點）、部署生產環境、合併主幹、關閉變更等步驟組成。
  • 配置准入規則爲：「測試階段-執行結果」等於「成功」，「預發階段-執行結果」等於「成功」，避免沒有經過預發驗證的分支直接進入生產階段。
  • 生產發佈審批通過後，部署生產環境。
  • 生產環境部署驗證通過後，表明本次發佈成功，可以將發佈release 分支合併回主幹 master，並自動關閉相關變更。

3.2 需求開發測試

“需求1:圖書借閱功能”、“需求2:圖書歸還功能”、“需求3:圖書到期續借功能”三個需求分別分配給開發小張、小明、小強開發。

第1步，爲一個需求新建一個變更拉一個 feature 分支

小張創建一個變更「變更1-實現圖書借閱功能」，選擇新建分支輸入 feature001，則可自動爲該需求拉取一個分支。依次類推，小明創建一個變更「變更2-實現圖書歸還功能」，自動新建分支feature002。小強創建一個變更「變更3-實現到期續借功能」，自動新建分支feature003。

第2步，開發代碼提交到 feature 分支

小張開發好圖書借閱相關代碼後，提交代碼到feature001上，小明開發圖書歸還相關代碼後，提交代碼到feature002分支上。

第3步，選擇變更集成，部署測試環境驗證

小張和小明，一借一還，需要一起部署到測試環境進行聯調驗證。進入應用研發流程頁，選擇變更1和變更2一起集成測試，雲效會自動將 feature001 和 feature002 合併到自動生成的 release/xxx_n 分支，使用該 release 分支做構建，並部署環境。環境部署成功即可進行測試驗證。

 

 

第4步，提交變更進行預發佈

測試環境驗證通過，進入「預發階段」，選擇變更1和變更2進行集成，勾選自動合併上一階段集成的分支，會自動生成新的 release/xxx_m 集成分支，自動合併上一階段 feature001、feature002、release/xxx_n 分支，使用新的 release/xxx_m 分支構建並部署預發環境。預發部署成功後即可進行預發驗證。

 

3.3 需求發佈上線

提交變更，需求自動化發佈到生產環境

預發驗證通過後，即可進入生成發佈階段。選擇待發布的變更1和變更2，運行生產流水線，發佈審批通過後，即可部署生產環境。生產環境部署完成，可配置自動關閉變更，並將發佈 release/xxx_k 分支合併入主幹 master，至此即完成了一次完整的需求發佈上線。

未經過預發驗證的需求禁止發佈，避免“漏測”

此時若在生產階段選擇變更1、變更2、變更3一起發佈，則經過變更准入卡點時會校驗失敗，因爲變更3沒有在測試環境部署驗證過，即保證了沒有經過測試驗證的需求不可發佈。

需求臨時“下車”，退出發佈窗口，不影響其他需求發佈

臨發佈前，變更3因沒有測試驗證通過，不滿足發佈條件，團隊本次決定圖書續借功能不上線，只上線變更1和變更2，則可再次運行預發階段流水線，將變更3踢出集成區，退出本次發佈。

4. 總結語

至此，本方案完成了從應用配置、到需求開發、多變更（需求）集成測試、發佈上線的完整流程，滿足了變更分支自動創建、變更分支自動合併集成測試、發佈准入卡點控制等訴求，避免因爲“漏測”帶來的生產故障，也避免因爲其中一個需求未達到發佈條件延期所有需求。

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。