今天沒空，只好完全靠 AI 寫… 不然今天是個非常好的主題

功能標誌讓程式可以先整合與部署，再安排功能開放；抽象分支則讓新舊實作並存，完成驗證後再切換。當發布安排改變時，這些做法也能讓團隊保留已整合的程式，調整實際提供的功能。

不過，能分開控制功能，不代表發布順序可以任意調整。原本排在後面的功能，仍可能需要前面的功能先提供。團隊要先確認這些依賴，再調整程式與設定，驗證新的組合是否符合需求。

活動延期，背景寄信先交付

以下沿用 Nathan 團隊的活動頁面與寄信改版，把時間放回兩者都還在準備的階段，假設發布安排有了變化。

產品經理原本安排先公開活動頁面，再讓指定客戶網域的通知改用背景寄送。活動頁面與首頁入口的程式已經整合到主幹，兩個開關仍保持關閉。寄信功能也已改用 Sender，但容器仍綁定原本的 ImmediateSender；新的 DomainQueueSender 已整合，尚未正式切換。

後來需求方延後活動日期，產品經理希望先提供背景寄信。Mandy 已完成新寄信實作的必要驗證，Brent 也準備好佇列與背景程序，但兩人仍要確認：活動保持關閉時，通知功能是否能照預期運作。Elvina 則配合檢查首頁與活動頁面的行為。

先確認通知是否需要活動頁面

背景寄信只改變通知的寄送方式，本身不需要活動頁面先公開。不過，本例另外假設，團隊先前按照原定發布安排，在一般通知文字中加入了活動連結。如果直接切換寄信，使用者收到通知後，就會被帶到尚未開放的頁面。

Mandy 與 Elvina 和產品經理確認，這批通知原本的用途不需要活動連結。因此，Mandy 可以先恢復原本的通知文字，延後加入活動連結，指定網域的通知仍可改用背景寄送。

如果通知的用途就是請使用者閱讀活動內容，就不能採取同樣的拆法。刪掉連結後，通知也失去原本的用途。團隊需要延後這項功能，或和需求方重新確認可以獨立交付的範圍。

除了使用者看到的內容，也要檢查程式需要哪些設定與資料。假如背景寄信使用了活動開發時加入的共用設定或資料欄位，這些內容仍須隨版本交付。

保留活動程式，調整寄信綁定

確認背景寄信可以先交付後，團隊再準備這次要部署的版本與設定。

活動頁面與首頁入口已有執行時讀取的開關，兩個開關繼續保持關閉，就能延後公開。已整合的活動程式可以保留在主幹，但網站仍要能正常建置、啟動，首頁等既有功能也要繼續運作。活動開發時修改的共用樣式或程式，不會因為開關關閉就自動失去影響，仍須按照影響範圍檢查。

寄信改版則沿用原本透過程式版本切換的做法。Mandy 將 Sender 的容器綁定改為 DomainQueueSender，並調整通知文字。完成審查與必要驗證後，按照直接提交與短期分支的流程整合到主幹，再確認整合後的驗證結果。

驗證活動關閉時的寄信流程

原本「活動先公開、再改寄信」的驗證結果，不能直接證明新的安排也符合預期。通知文字與綁定已經改變，活動也保持關閉，團隊需要用這次準備部署的版本與設定重新驗證。

主幹驗證通過後，Brent 將成品部署到測試環境，和 Mandy 一起確認實際背景寄送與失敗處理流程。Elvina 與 Mandy 則按照表中的預期行為，確認首頁與活動頁面。

如果驗證失敗或尚未完成，就先不切換正式功能。發現問題時，團隊要確認通知內容、設定與程式是否符合這次安排，以及是否遺漏了必要的依賴，修正後再重新驗證。

必要驗證與交付準備完成後，Brent 將測試過的同一份成品部署到正式環境，套用正式設定，並更新必要的長駐程序。部署後，團隊再確認活動仍未開放、指定網域的任務正常處理，以及其他網域仍使用立即寄送。

如果背景寄信發生問題，就按照寄信改版準備的還原方式恢復原本綁定。切回只會改變後續通知的寄送方式，已排入佇列的任務仍要確認狀態，再決定繼續處理或暫停；需要繼續寄送時，也要保留處理任務所需的程式。

活動取消時，只移除不再需要的部分

若需求方取消活動，團隊就要安排移除活動功能、開關與專用測試，保留仍適用的既有功能測試。

移除時，仍要確認哪些程式正在被其他功能使用。假如加入活動功能的提交，也包含背景寄信需要的共用程式，直接撤銷整筆提交，就會一起移除仍在使用的內容。團隊可以另作一筆提交，只移除活動專用的部分，再驗證寄信與受影響的既有功能。

資料也要分開處理。前面的密碼遷移已說明，開始寫入新格式後，預備還原的程式版本必須能處理這些資料。延後或取消功能，不會讓已寫入的資料自動恢復，因此不能只根據原定發布順序決定要恢復哪個版本。

持續維護尚未公開的活動功能

背景寄信先交付後，活動程式仍保留在主幹。後續有人修改首頁或共用程式，團隊也要確認活動功能是否受到影響，必要時一起調整程式與測試。

從這些維護項目來看，先完成並交付一項功能，再開始下一項，可以減少同時保留的過渡程式與設定。這是依本例作出的分析，不代表活動等待公開期間，其他人都必須停止開發。

產品經理可以依活動日期與實際依賴安排後續功能。到了新的公開時間，團隊再用當時的版本與設定驗證活動頁面及首頁入口，確認符合開放條件後才啟用，不能直接沿用改期前的驗證結果。

小結

功能已整合到主幹，發布順序改變時，不必立刻把程式移除。先確認功能的用途與依賴，再決定哪些程式要保留、哪些內容要調整，以及這次使用什麼版本與設定。完成新組合的驗證後，才能按照新的安排交付。

目前討論的替換，仍以同一套程式裡的功能與實作為主。如果要替換持續對外服務的整個舊系統，就還需要安排請求如何分給新舊系統，以及它們如何共同使用既有資料。接下來會把逐步替換的做法延伸到這個範圍。

參考資料

• Trunk Based Development：Concurrent development of consecutive releases
• Trunk Based Development：Feature flags