近來客戶問了一個很有趣的問題
系統移交後，還有保固期。我們的團隊要負責修復 bug 。但他們也有工程師要進來改，這樣怎麼維持系統的一份 Code ？
基於責任歸屬的問題，並不推薦這樣運作，畢竟就算改壞的系統功能不用委外團隊修復，排查問題還是會產生資源的耗用用。大多數的合約會乾脆訂，只要自己改了就不保固。但如果仍然要進行，問題就是回到標題寫的，不同團隊共同開發一套系統，怎麼維持系統的穩定？
版本控制策略
首先，系統源碼本身要有 Git 進行版本控制。在上面的情境中，最後發佈的負責人應該是委外團隊，但如果是一般公司組織內，就指派特定的資深人員就好。當然，如果規模比較大，也有可能會設一個變更管理團隊，但整體的結構不變。
以 Git Flow 分支策略，就能比較清楚知道怎麼進行。首先幾個名詞解釋
Master：最重要的主幹分支，裡面的每一個版本都是能隨時發佈的，所以它是相對穩定的版本，不可在上面進行測試或改動。Dev：開發團隊的主要分支，從 Master 分離出來，主要用於整合測試使用，是相對穩定的分支。Feature：個別工程師進行開發時，再從 Dev 分離出去的分支。因為 Dev 可能會有其它 QA 、 PM 在測試，同時一個系統可能有很多工程師在開發，切出 Feature 可讓開發中的震盪只會發生個別的 Feature 中，不會影響到 Dev。這等於每個開發中的功能，不會影響到團隊中其它實員的開發。個別的功能都應該切不同的 Feature (大致上就是對應到一個 issue)。
按這樣的結構處理後，當特定一個版本要發佈之前，會經過整合測試。
整合測試便是會把各個完成的 Feature 分支，合併到 Dev 。因為 Feature 是多線進行，且可能切出去的時 Dev 版本也不同，合併的時候若發生衝突，就是在這個階段排除。完成合併後便可進行整合測試。
發佈後的異常處理
整合測試完成後，新的 Dev 穩定至可發佈狀態時，再合併至 Master ，打上版號，準備發佈。這時，便發生另一個實務上一定會發生的議題：發佈後發現程式異常怎麼辦？
這時不出有三種策略：
- 排入下一個版本修復
- 回滾 (roll-back) 回上一個版本
- 緊急修正 (hotfix)
第 1 種就不討論，不影響主流程的情況，大概都是選擇第 1 種策略，再重複上面的開發循環。不管是不是跨團隊的開發，問題都不大。
比較有決策困難的是，影響系統主流程的版本怎麼辦？
沒有經驗的開發團隊，很多會選擇看噴什麼錯誤，直接改了。我通常看得是冷汗直流，直到我看到這個影片，覺得完全命中！
是的，Hotfix 就是這麼驚悚！所以…它不應該是常態。
回到最初設定的情境：多團隊的共同開發。進行發佈的負責人，有 99.9% 的機率不會清楚這次版本的所有變動區域。所以如果發佈新版本後，遇到影響系統主流程的異常，最標準的動作是：直接回滾到前一版本。因此， Master 的一個重要前提：每一個版本都是能隨時發佈，在此處就相當重要。
當然，工程師會抗議，不是他們要做 Hotfix ，是被 PM 押著做。不過 PM 大概也會說，他也是被 PO 推著走。這種事，只能書面揭露 hotfix 的項目及風險，請相關人員共同劃押、共同承擔了。
