微服務架構下，每個應用服務獨立開發、獨立釋出，小步快跑，持續快速交付業務需求。多人協同開發同一個應用時，分支開發模式是一個適合的協同方案。該模式下一個需求或任務通常對應一個 feature 分支，多個需求一起合併到 release 分支進行整合測試驗證併發布。期間可能遇到以下問題：
- 痛點 1：當開發同學領到一個需求時，怎麼為這個需求快速地拉一個 feature 分支？
- 痛點 2：當多個相關需求一起釋出時，多個 feature 分支怎麼高效自動化地合併到 release 分支？
- 痛點 3：當其中一個 feature 分支沒有經過測試驗證時，怎麼“阻止”它釋出到生產環境避免漏測引起故障？
- 痛點 4：當其中一個 feature 分支做了測試驗證，但是發現有嚴重問題，怎樣可以“退出”本次釋出而不影響其他需求正常釋出？
- 痛點 5：當一個需求 feature 分支提交測試了、釋出上線了，怎麼自動、及時的更改相應需求狀態，便於相關業務、產品、測試同學跟蹤進度？
雲效解決方案
雲效應用交付平臺 AppStack 提供的變更持續交付解決方案可以比較輕鬆地解決以上問題。在瞭解具體的使用前，我們先了解下 AppStack 中涉及的一些核心概念：
- 應用： 一個軟體的最小發布單元，聚合程式碼、環境、版本等軟體資產，以及研發流程定義。最小發布單元意味著無法解耦的一個或者多個服務的組合，這個服務組合會透過一個流程進行統一交付。
- 變更： 變更是對應用的一次特性改變（引入新的特性或改變已有特性），源於需求，終於交付。通常一個需求或任務對應一個變更，對應一個 feature 分支。
- 研發流程： 應用完成一次變更的過程和約束，包括開發、測試、釋出上線的完整流程，由多個階段的多條流水線承載，依次在不同環境進行測試、構建、部署，最終審批透過後釋出生產環境。
下面，我們以一個 spring-boot 應用的“圖書館管理系統”為例，演示如何在雲效應用交付平臺 AppStack 中開發“圖書借閱功能”、“圖書歸還功能”、“圖書到期續借功能”三個需求，並一起釋出上線。**過程中，前述的 5 個痛點都將得到解決。
作為應用負責人
作為應用負責人，需要編排應用構建、部署流程，透過流水線工具自動化起來；需要定義應用生產釋出準則，來規範應用研發流程降低釋出風險。
新建應用
新建應用，輸入應用名稱，應用模板選擇「變更持續交付模式」。
程式碼源配置
應用設定，配置應用程式碼源，設定預設分支。
配置研發流程
本應用的研發流程可以分為測試階段、預發階段、生產階段：
- 測試階段：由 Java 單元測試、Java 程式碼掃描、構建、部署測試環境等步驟組成。用於日常測試驗證。
- 預發階段：由構建、部署預發環境等步驟組成。用於預釋出驗證。
- 生產階段：由構建、生產釋出審批（人工卡點）、部署生產環境、合併主幹、關閉變更等步驟組成。
- 生產釋出審批透過後，部署生產環境。
- 生產環境部署驗證透過後，表明本次釋出成功，可以將釋出 release 分支合併回主幹 master，並自動關閉相關變更。
設定變更整合方式和准入規則
本示例各階段都選擇「新增變更整合」方式，在執行階段流水線時可以選擇多個變更分支整合到 release 分支進行構建部署驗證。
- 測試階段：無准入規則。
- 預發階段：配置准入規則為：「測試階段-執行結果」等於「成功」，避免沒有經過測試驗證的分支直接進入預發。
- 生產階段：配置准入規則為：「測試階段-執行結果」等於「成功」，「預發階段-執行結果」等於「成功」，避免沒有經過預發驗證的分支直接進入生產階段。
作為一線開發
“需求 1：圖書借閱功能”、“需求 2：圖書歸還功能”、“需求 3：圖書到期續借功能”三個需求分別分配給開發小張、小明、小強開發。
第 1 步，為一個需求新建一個變，更拉一個 feature 分支
小張建立一個變更「變更 1-實現圖書借閱功能」，選擇新建分支輸入 feature001，則可自動為該需求拉取一個分支（解決上述痛點 1）。依次類推，小明建立一個變更「變更 2-實現圖書歸還功能」，自動新建分支 feature002。小強建立一個變更「變更 3-實現到期續借功能」，自動新建分支 feature003。
第 2 步，開發程式碼提交到 feature 分支
小張開發好圖書借閱相關程式碼後，提交程式碼到 feature001 上，小明開發圖書歸還相關程式碼後，提交程式碼到 feature002 分支上。
第 3 步，選擇變更整合，部署測試環境驗證
小張和小明，一借一還，需要一起部署到測試環境進行聯調驗證。進入應用研發流程頁，選擇變更 1 和變更 2 一起整合測試，雲效會自動將 feature001 和 feature002 合併到自動生成的 release/xxx_n 分支（解決上述痛點 2），使用該 release 分支做構建，並部署環境。環境部署成功即可進行測試驗證。
第 4 步，提交變更進行預釋出
測試環境驗證透過，進入「預發階段」，選擇變更 1 和變更 2 進行整合，勾選自動合併上一階段整合的分支，會自動生成新的 release/xxx_m 整合分支，自動合併上一階段 feature001、feature002、release/xxx_n 分支，使用新的 release/xxx_m 分支構建並部署預發環境。預發部署成功後即可進行預發驗證。
此時若在預發階段選擇變更 1、變更 2、變更 3一起整合，則經過變更准入卡點時會校驗失敗，因為變更 3 沒有在測試環境部署驗證過，即保證了沒有經過測試驗證的需求不可釋出（解決上述痛點 3）。
變更 3 因沒有測試驗證透過，不滿足釋出條件，團隊本次決定圖書續借功能不上線，只上線變更 1 和變更 2，則可再次執行預發階段流水線，將變更 3 踢出整合區，退出本次釋出（解決上述痛點 4）。
第 5 步，提交變更進行生產釋出
預發驗證透過後，即可進入生成釋出階段。選擇待發布的變更 1 和變更 2，執行生產流水線，釋出審批透過後，即可部署生產環境。生產環境部署完成，可配置自動關閉變更，並將釋出 release/xxx_k 分支合併入主幹 master，至此即完成了一次完整的需求釋出上線。
作為業務/產品同學
變更釋出完成了，我作為產品同學怎麼知道需求釋出了呢？雲效 AppStack 的變更和雲效專案專案協作 Projex 中的工作項做了狀態聯動，支援變更釋出完成後自動將需求狀態置為「已釋出」，這樣產品同學可及時看到需求進展（解決上述痛點 5）。
具體配置方式如下：進入雲效 Projex 專案-專案設定-自動化規則，選擇「支援工作項與變更狀態的聯動」模板，配置當產品類需求關聯的全部變更狀態為「已釋出」時，將需求狀態置為「已完成」。
至此，本方案完成了從應用配置、到需求開發、多變更整合測試、釋出上線的完整流程，滿足了變更分支自動建立、變更分支自動合併整合測試、釋出准入卡點控制等訴求，支援變更關聯業務需求和狀態聯動，完整追溯需求的全生命週期流程。
🔔 注： 雲效 AppStack 中的變更持續交付模式為高階版付費功能，加入釘釘群：42574350 可申請免費試用體驗。
點選此處，瞭解更多。