由于互聯網行業需求變化快、開發迭代周期短、上線頻繁的現實狀況決定了合理的軟件配置管理策略對于軟件質量保證、協作開發效率至關重要。
??? 目前公司配置管理在策略上采用的是不穩定主干（ 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? 。
4、一些工具
code review
??? http://www.reviewboard.org/
持續集成
??? https://hudson.dev.java.net/
自動部署
商業軟件中采用atlassian的系列產品倒是不錯的選擇：Jira+Crucible+FishEye+Bamboo
?
5、參考文檔
? http://www.programmer.com.cn/3223/
? http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.commonpatterns.feature
? http://martinfowler.com/bliki/FeatureBranch.html
? http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
? http://msdn.microsoft.com/en-us/library/bb668955.aspx
? http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx
? http://www.cmcrossroads.com/bradapp/acme/branching/
? http://www.vance.com/steve/perforce/Branching_Strategies.html
? http://blog.gravityfree.ca/2009/02/using-feature-branches.html
? http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
? http://thinkernel.bokee.com/4518935.html
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
