互聯網敏捷開發配置管理策略思考

由於互聯網行業需求變化快、開發迭代週期短、上線頻繁的現實狀況決定了合理的軟件配置管理策略對於軟件質量保證、協作開發效率至關重要。

目前公司配置管理在策略上採用的是不穩定主幹（unstable trunk）模式，所有的項目都在同一主幹上進行修改，在每週上線後並沒有明確的stable分支版本，基本上是靠SCM人員手工拷貝代碼來管理維護的。這就引起了很多問題：

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

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

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

類似的問題很多。要在新的項目實施及後期運營中避免類似問題的重現，至少要從如下幾個方面來：

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

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

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

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

1、分支策略（Branching Strategy）

代碼分支管理策略一般分爲3種（參考Branching Strategy Questioned）

1）、不穩定主幹策略（The unstable trunk strategy）

此種分支策略使用主幹作爲新功能開發主線，分支用作發佈。此種分支管理策略被廣泛的應用於開源項目。比如freebsd的發佈就是一個典型的例子。freebsd的主幹永遠是current，也就是包括所有最新特性的不穩定版本。然後隨着新特性的逐步穩定，達到一個發佈的里程碑以後，從主幹分出來一個stable分支。freebsd是每個大版本一個分支。也就是說4.x，5.x，6,x各一個分支。每個發佈分支上只有bug修改和現有功能的完善，而不會再增加新特性。新特性會繼續在主幹上開發。當穩定分支上發生的修改積累到一定程度以後，就會有一次發佈。發佈的時候會在穩定分支上再分出來一個 release分支。
此種分支管理策略比較適合諸如傳統軟件產品的開發模式，例如微軟Windows開發，對於互聯網開發不是很適合。已經在主幹上集成的新功能，如果達不到里程碑的要求，穩定分支就不能創建，很有可能影響下一個發佈的計劃。還有一個問題就是bug修改必須在各個分支之間合併。

2）、穩定主幹策略（The stable trunk）

    此種分支策略使用主幹作爲穩定版的發佈。主幹上永遠是穩定版本，可以隨時發佈。bug的修改和新功能的增加，全部在分支上進行。而且每個bug和新功能都有不同的開發分支，完全分離。而對主幹上的每一次發佈都做一個標籤而不是分支。分支上的開發和測試完畢以後才合併到主幹。
    這種發佈方法的好處是每次發佈的內容調整起來比較容易。如果某個新功能或者bug在下一次發佈之前無法完成，就不可能合併到主幹，也就不會影響其他變更的發佈。另外，每個分支的生命期比較短，唯一長期存在的就是主幹，這樣每次合併的風險很小。每次發佈之前，只要比較主幹上的最新版本和上一次發佈的版本就能夠知道這次發佈的文件範圍了。
   此種分支策略的缺點之一是如果某個開發分支因爲功能比較複雜，或者應發佈計劃的要求而長期沒有合併到主幹上，很可能在最後合併的時候出現衝突。另外由於對於每一分支都要進行測試才能夠合併到主幹中，測試工作量較大。

3）、敏捷發佈策略（The agile release strategy）

此種模式在採用敏捷開發模式（例如Scrum）的項目中廣泛採用，這些項目有固定的迭代週期（例如Scrum中每個Sprint的兩週時間），新的功能開發都在Task branch(Feature branch)上進行，在接近迭代週期的發佈階段時候，新建Release branch來完成本迭代週期的發佈，各Task branch(Feature branch)的功能merge到Release Branch中。在完成發佈後，Release branch的功能merge到Trunk和尚在進行的Task branch中。

採用敏捷發佈策略要求主幹的版本：

任何時候都可以發佈：在任何時候，產品所有者都可以基於主幹的最新版本，發佈新版本的產品
希望儘早發佈

此種模式較適合敏捷開發軟件的要求，但對程序員及SCM要求較高。

關於敏捷發佈策略可以參考：多個敏捷團隊之間的版本控制

2、配置管理策略

根據目前公司的實際情況，建議採用穩定主
幹策略爲主（The stable trunk）。參考淘寶網最佳實踐之ABS自動編譯可以看到，淘寶也採用了類似的版本管理策略。

具體操作策略如下（尚需要細化）：

1）、trunk保持穩定，保證可以隨時發佈。trunk只有SCM人員才具有寫權限，開發人員等只有讀權限。

2）、爲降低SCM分支管理的壓力，branch的權限可以授予給指定的幾個組長

3）、在每一個項目開始前，採用Branch per feature(Branch per Task)的分支管理模式（Common Branching Patterns），由各組長或SCM人員按照branch管理規範建立對應項目的開發分支development branch，例如airline_product1_feature_leader_date、airline_product2_bug_leader_date。

項目定義：新功能開發、bug修復、需求變更等

4）、在每週的上線發佈後，在主幹建立基線release版本（通過svn tag），以當前的主幹作爲基線，建立下一發布週期的test branch

5）、開發人員在所在項目的development branch完成開發及集成測試後提交上線單，由SCM人員根據項目上線單的分支名稱merge分支代碼到本發佈週期的test branch，進行測試。如果在測試過程中有新的上線單且有可能與其他上線單存在衝突，則在merge到test branch的過程中，SCM人員可以很容易及時排查問題。

只要對上線單命名按照規範進行定義（例如與分支名稱相同），此部分工作可以由腳本來自動化，存在衝突再人工干預。

6）、測試人員完成本發佈週期test branch所有上線單的功能測試後，由SCM人員將本發佈週期的test branch合併到trunk，並通過打tag來release 一個上線版本

7）、系統人員利用自動化部署腳本從trunk檢出對應的release版本進行上線部署

此部分工作採用自動化腳本完成，自動化腳本主要完成如下操作：從trunk檢出完整的release 版本並打包，幷包含部署包的md5驗證碼-> 上傳部署包到生產系統各服務器->校驗發佈包的md5驗證碼是否正確,保證文件正確傳輸->完整備份生產系統的運行包->部署生產系統

8）、每日晚上對trunk進行持續集成，保證能夠正常編譯和部署。工具建議採用hudson

9）、對於核心代碼及後臺代碼的修改，採用Pre-commit review模式，必須通過code review後，才能夠提交到trunk中。工具可以採用reviewboard

10）、其他一些值得討論的問題

開發分支的生命週期問題：上線後，原有的development branch變爲只讀的或者可以定期刪除掉。

緊急上線策略：緊急上線不遵循每週兩次的上線週期，因此對於需要緊急上線的程序可以從trunk檢出最近的release版本代碼建立臨時測試分支（test branch），緊急上線仍然需要按照規範建立對應的development branch，然後與臨時測試分支合併，測試通過後上線，同時由SCM人員將緊急上線的development branch合併到當前的測試分支，繼續進行測試。

不同項目的配置管理策略：對核心框架、後臺應用、前端頁面開發可以採用不同的配置管理策略，例如核心框架可以採用不穩定主幹策略（The unstable trunk strategy）；後臺應用採用穩定主幹策略（The stable trunk）

3、版本控制工具選擇

SVN的集中管理模式較爲適合目前公司協作開發的需要，例如SVN所提供的集中式權限控制，對代碼、二進制文件及文檔的集中管理，類似TortoiseSVN的支持工具以及Eclipse 插件等。而Git/Mercurial（hg）的分佈式管理特性，很適合開發人員本地版本開發管理。

因此可以結合SVN和Git/Mercurial（hg）來作爲版本控制工具。用SVN進行集中管理，用Mercurial（hg）在多個不同機器上進行開發，功能完善並測試完成後再提交至 SVN Repository。可以藉助git-svn、HgSubversion、hgsvn這樣的工具來結合使用。考慮到目前的開發環境爲Windows環境，建議採用Mercurial。

值得一提的是SVN從1.5版本開始，對branching merge的支持有很大的提升，大大簡化了分支合併的難度，可以參考What’s New in Subversion 1.6?。