昨天的文章總結了從軟件工程角度，如何進行項目管理相關的知識。正好上週末星球內部直播時候，有同學問了一個問題：他們公司經常存在多版本並行的項目，不知道怎麼做好質量保障工作。
這篇文章就以昨天文章中提到的項目管理的方法，結合我自己的實際經歷，來聊聊多版本並行，質量保障工作面臨哪些挑戰以及如何保障交付質量。
我們日常工作中版本迭代一般都是按照時間進行排版迭代的，但偶爾也會遇到其他情況，比如新業務拓展需要緊急上線，但日常的迭代也不能停止。
這個時候就會出現多版本或者說多項目並行的情況，這也給質量保障工作帶來了很大的挑戰。總結一下，比較大的挑戰主要有如下四點。
環境問題
如上圖所示，當時我們遇到了這樣一個問題：在一個迭代週期內有2個業務迭代版本和3個獨立項目差不多要同時上線。這個時候面臨的第一個問題是測試環境的問題。
原則上來說，爲了避免不同項目之間的互相影響，在測試環境上要做到彼此隔離。但要做到環境隔離，又面臨2個挑戰：
第一個是成本問題，單獨搭建一套可用的測試環境，包括雲服務器、緩存、消息隊列和數據庫，成本是很高的；
第二個是時間問題，搭建環境涉及到運維、研發和測試團隊，需要運維準備資源、研發配合測試進行發佈聯調；
當時我們的測試環境很混亂，很多環境處於不可用狀態，面臨這個問題，我當時是這樣解決的。
首先，4.1和4.2版本的時間可以錯開，因此該兩個版本可以共用一套環境，只是在代碼部署上跟進下細節即可；
其次，獨立版本1由於橫跨了4.1和4.2版本，且涉及的業務域和對應服務和其他項目差異較大，因此獨佔T1環境；
最後，獨立版本2和獨立版本3提測及上線日期接近，且涉及的業務域和對應服務相差不多，可以將範圍內的所有服務發佈到T2環境，共用一套環境。
關於環境問題，我之前寫過一篇詳細的文章《被忽視的問題：測試環境穩定性治理》，大家可以參考。
業內比較好的解決方案是通過流量染色+stable環境來解決，架構圖如下：
分支問題
多版本並行，其實最大的難點就在於代碼分支問題。關於代碼分支，主要考量如下幾點：
- 每個項目是否都需要單獨拉一個分支出來進行開發；
- 上線前代碼merge，如果衝突較多，就需要儘早去做代碼合併儘早發現問題；
- 如果沒有明顯的代碼衝突，在UAT階段做一輪快速的迴歸驗證即可；
邊界問題
這個問題其實很容易忽略，但在實際的工作中，面臨多版本並行的情況，劃分清楚邊界其實是很重要的。
這樣一方面可以減少不必要的工作量，另一方面也可以避免測試過程中遇到不同項目的交互區域，責任劃分以及問題跟進問題。
邊界劃分，我個人的處理經驗主要遵循如下幾點：
- 需求評審時明確本次需求涉及的業務域；
- 按照業務域去確定該項目對應的應用服務名（便於區分代碼分支）；
- 綜合不同項目的調用依賴，判斷公共服務是否有變更（如有可考慮mock等手段）；
- 解決不同項目在測試過程中的測試數據問題（測試數據準備也是多項目並行的一大難點）；
迴歸問題
其實多版本並行最大的工作量就在於迴歸驗證，一方面要確保每個項目涉及到的變更影響部分都要回歸到，避免遺漏；
另一方面針對不同項目的不同代碼分支，還要考慮代碼衝突的問題。針對這種情況，一般來說解決方法無非下面幾種：
- 大量的自動化測試來節省迴歸測試的時間和工作量；
- 短期內通過增加人力的方式去儘可能覆蓋涉及的業務場景；
結合上篇文章講到的項目管理知識，可以看到：
- 在項目前期識別面臨的問題，這是風險評估和風險管理；
- 在面臨多項目並行時制定項目計劃並逐步拆解爲最小的可執行任務；
- 通過流程規範去約束代碼分支和提測發佈過程，並時時跟進；
- 通過工具去提升過程效率（如自動化等手段）；
綜合來說，軟件工程的方法論在實際的工作中，給了我們更高的一個觀察視角，能讓我們解決更復雜的問題。