團隊持續把程式整合到主幹，主幹上的內容也會跟著改變。準備發布時，需要先選定這次要交付的版本，讓後續提交不會直接改變這次的發布內容，再針對選定的版本完成驗證。
常見的做法有兩種：直接選用主幹上的某個版本發布，或從那個版本建立發布分支。發現問題需要修正時，前者會從持續前進的主幹選取新版本，後者則只把這次發布需要的修正帶到發布分支。
兩種方式都需要備妥建置成品、設定與環境，並完成必要驗證。
建置成品（build artifact）指建置過程產生並保留的檔案，例如供後續驗證、部署或發布使用的套件。本文後續簡稱為「成品」（artifact）。
首先，要記錄成品在版本控制中對應的原始碼版本。只記錄分支名稱並不足夠，因為分支還會繼續接收提交。在 Git 裡，可以記錄提交識別碼，再用標籤（tag）標示發布版本，例如 v1.0.0。
除了原始碼版本，也要保留實際發布的成品，並記錄它通過了哪些驗證。後續部署使用同一份成品，就能確保部署的是先前驗證過的檔案。
部署到指定環境時，也要記錄使用的成品與設定，方便發生問題時回頭查找。
從主幹發布時，先選定一個符合本次需求、已完成建置與必要驗證的提交。可以選用主幹的最新提交，也可以選用先前已確認的提交。
接著取得該提交對應的成品，完成交付準備後，就發布這份成品並留下紀錄。
假設團隊已選定提交 A，之後主幹加入其他變更，前進到 B。只要 A 仍符合發布條件，就可以發布 A 的成品，不必改用 B。
後來團隊發現 A 有問題，便在主幹修正，產生提交 C。C 同時包含 B 的變更，因此要依這些變更是否適合一起發布，選擇以下方式：
兩種方式都要確認對應成品已完成建置與必要驗證，並備妥交付所需的設定與環境，再進行發布。下圖呈現這兩種選擇，A 的叉號表示後來發現的問題。
發布分支（Release Branch）用來準備或維護特定發布版本。團隊先從主幹選定提交建立分支，之後只加入這次發布需要的調整，日常功能開發仍持續整合到主幹。
但主幹上的提交，不一定都要在這次發布。選較早的提交，可能缺少需要的功能；選較新的提交，又可能包含不想發布的功能。因此，選擇分支起點時，也要一起考慮後續需要補入或移除哪些程式。
以下用另一個例子說明。主幹依序有 A、B、C 三個提交：A 是共同基礎，B 加入這次不想發布的功能，C 則加入這次需要的功能。這個例子假設 C 的功能不依賴 B。
cherry-pick 套用 C 的變更。這是主幹開發網站〈Branch for release〉介紹的做法，不會帶入 B，但要確認所需的提交與依賴都已補齊。git revert 撤銷 B 的變更。這會新增一個反向修改的提交，保留原有歷史；仍須確認撤銷 B 後，C 加入的功能與原有功能仍能正常運作。下圖的兩條發布分支代表兩種替代方案，不需要同時建立。兩者的目標都是保留 C 的功能、排除 B 的功能。
實際情況若是 C 的功能依賴 B，兩種方式都不能直接達成目的。團隊需要先調整程式，讓所需功能能分開使用，或重新決定這次發布的內容。不能只看要挑選或撤銷幾個提交，就判斷哪種方式比較簡單。
挑選或撤銷變更後，發布分支的程式組合已經不同於主幹。建置流程要針對這個版本產生成品並執行必要驗證，不能直接沿用主幹的成功結果。確認通過並完成交付準備後，再發布該分支的成品。
延續前面的例子，如果 B 的功能一直不準備上線，團隊每次部署都從主幹挑選其他提交，持續加到發布分支，這條分支就會逐漸成為另一條長期開發路線。團隊除了維護主幹，還要持續處理發布分支上的依賴、衝突與驗證，才能讓後續功能上線。
團隊應處理 B 無法上線的原因，讓主幹能直接用來發布。如果暫時無法解決，也可以先從主幹撤銷 B，等到適合的時機再放回去。
選定起點後，這個版本需要的修正都要進入發布分支。通常要先在主幹重現問題、補上測試並修正，再把修正帶到發布分支，重新建置與驗證，避免只修好發布版本，卻漏掉主幹。
若無法在主幹重現問題，可以先在發布分支修正，但仍要注意後續版本再次出現相同問題的風險。
如果可以直接使用主幹上的版本，就不必另外維護發布分支。如果需要排除部分變更，或持續修正特定版本，就可以使用發布分支，但也需要維護該分支的建置與驗證。
如果這個版本還需要發布更新，就保留發布分支。確定不再維護後，再刪除分支，並保留發布標籤、成品與相關紀錄，方便日後查找。
發布完成後，要核對交付的成品與發布紀錄是否一致。若是線上服務，還要確認實際版本、設定、服務可用性，以及受影響功能的行為；若是安裝檔，則透過既有的支援與回報管道追蹤使用者遇到的問題。
這些確認的範圍應在發布前就約定好。例如，本次若調整共用模組，就需要留意使用該模組的流程。部署指令結束，還不足以判斷實際使用情況。
發現問題時，再依影響判斷是否暫停後續發布、修正後交付，或在條件允許時恢復先前版本。
從主幹發布，可以直接選用已驗證的提交與成品。從發布分支發布，則要先選擇起點，確認需要補入或移除哪些變更，再針對調整後的版本建置與驗證，並持續維護。
選定發布來源後，團隊還需要持續備妥成品、環境與部署流程，才能在需要時發布。
iThome鐵人賽
看影片追技術