一直為軟體版本釋出困擾，開發人員需要不斷前進完成功能，測試人員在後面緊跟測試，售後人員需要穩定版本上線，三者間沒有達成統一的認識，產品或者專案到底怎樣才算穩定版本。

目前公司配置管理在策略上採用的是不穩定主幹（unstable trunk） 模式，所有的專案都在同一主幹上進行修改，在每次上線後並沒有明確的stable分支版本，基本上是靠測試人員TAG程式碼來管理維護的。

問題：

   1）、多個專案組開發人員都可能併發對同樣程式碼進行修改，造成了嚴重的程式碼衝突問題。例如張三修改了a.java並上QA測試伺服器，在QA測試過程中， 李四也對a.java進行修改並上QA，李四的程式碼覆蓋了張三的程式碼。由於是SCM人員並不清楚程式碼衝突情況，這樣張三和李四的程式碼上QA很容易相互影響 並很難查具體原因

   2）、由於沒有明確stable分支版本，導致上QA、上生產只能採用增量更新，上QA、上生產出問題後的程式碼回滾很麻煩，嚴重影響了測試、上線效率。對於生產環境執行的程式碼的具體版本並沒有明確的管理，導致生產系統出問題後要排查問題也很難查。

   3）、由於核心基礎包沒有與上層應用隔離，導致大家都會對核心包進行修改，修改後程式碼質量並沒有有效控制。於是出現因為修改基礎包影響整個系統功能等現象

如何避免，至少要從如下幾個方面來：

  1）、分支管理策略：採用適當的分支管理策略來保證開發庫、測試庫、釋出庫的隔離

  2）、適當引入每日編譯、持續整合、Code Review等敏捷開發的最佳實踐

  3）、採用自動化指令碼完成上QA、上生產的部署工作，避免人工失誤

  4）、對核心框架、後臺應用、前端頁面開發採用不同的配置管理策略

版本管理的策略：不穩定主幹策略、穩定主幹策略、敏捷釋出策略。

下面是對這幾種策略的摘錄：

不穩定主幹策略

1. 使用用主幹作為新功能開發主線，分支用作釋出。
2. 被廣泛的應用於開源專案。
3. 比較適合諸如傳統軟體產品的開發模式，比如微軟的office等。
4. bug修改需要在各個分支中合併。
5. 新程式碼在主幹上開發，因此如果主幹不能達到穩定的標準，就不可以進行釋出。
6. 這種策略的好處是沒有分支合併的工作量，因此比較簡單。

穩定主幹策略

1. 使用主幹作為穩定版的釋出。
2. bug的修改和新功能的增加，全部在分支上進行。
3. 不同的修改或新功能開發以分支隔離。
4. 分支上的開發和測試完畢以後才合併到主幹。
5. 主幹上的每一次釋出都做一個標籤而不是分支。
6. 每次釋出的內容調整起來比較容易。
7. 缺點是分支合併所增加的成本。

敏捷釋出策略

1. 敏捷開發模式的專案中廣泛採用，敏捷開發的專案具有固定的釋出週期。
2. 為每個task建立分支。
3. 為每個釋出建立分支，每個週期內的task分支需要合併到釋出分支釋出。
4. 在完成釋出後，釋出分支的功能合併到主幹和尚在進行的任務分支中。
5. 一種穩定主幹策略的變體。
6. 團隊成員要求較高。

團隊當前情況

1. 負責網際網路產品的開發，釋出更新較為頻繁。
2. 有固定的釋出週期，同時也存在比較多的hotfix。
3. 修改任務通常比較小，改動範圍通常不大，時間通常較短。
4. 不同的功能頁面有不同的小組負責，耦合度相對較低。
5. 團隊目前沒有采用分支策略，開發人員協商進行增量更新，出現錯誤的機率較高。
6. 已使用SVN版本控制工具。

初步實踐

參考上述策略，結合當前團隊的現狀，初步設計了下面的版本控制解決方案。

此方案已穩定主幹策略為主結合了一些敏捷釋出策略的思路，具體實施方案如下：

1、主幹時刻處於穩定狀態，隨時可以釋出。設SCM人員對主幹程式碼進行管理，普通開發人員只讀。

2、SCM為開發任務建立開發分支。常規的可以以小組為單位建立分支，較大的任務可以建立專門的分支。

3、在釋出日，從主幹複製一個測試分支，需要在本釋出日釋出的各開發分支向此測試分支合併。

4、對測試分支程式碼進行測試，出現bug在測試分支上更改，無誤後釋出。

5、測試分支程式碼釋出後，合併入主幹，並在主幹上進行標記。

6、對緊急修復（Hotfix）的情況，可以從主幹複製出測試分支，在測試分支上進行緊急修改，並在測試後釋出，釋出後同樣將程式碼合併會主幹，做標記。

7、 Hotfix僅限於可以很快解決的小問題，如果更改時間過長，則需採用常規方法完成。

8、如果在測試分支測試過程中需要hotfix工作，則在複製一個新的測試分支進行hotfix，測試後釋出。然後同時合併入原測試分支和主幹，並在主幹上做標記。此過程未在上圖中畫出。

9、測試分支釋出後，開發分支可以刪除；測試分支合併入主幹後，測試分支可以定期刪除。

方案的優缺點

方案優點

1、解決了沒有實施分支策略時，程式碼不能經常簽入的問題。

2、主幹程式碼始終處於穩定的狀態隨時可以釋出，降低了風險。

3、可以基於一個完整的測試分支進行測試及釋出，而不是以口口相傳的方式增量更新。

方案缺點

1、建立分支、合併分支增加了工作量。考慮實際情況，以及版本控制工具的輔助，增加的工作量應該可以接受。

2、如果某些開發分支工期跨越多個釋出週期，修改過於劇烈，合併分支時可能工作量較大。可以考慮分解任務，避免過大的任務出現。

3、在同一時間最好只有一個測試分支，因此建立測試分支的許可權需要限制，除hotfix場景外應當避免。

參考：

淘寶網最佳實踐之ABS自動編譯