由于互聯(lián)網(wǎng)行業(yè)需求變化快、開發(fā)迭代周期短、上線頻繁的現(xiàn)實狀況決定了合理的軟件配置管理策略對于軟件質(zhì)量保證、協(xié)作開發(fā)效率至關(guān)重要。

??? 目前公司配置管理在策略上采用的是不穩(wěn)定主干（ unstable trunk） 模式，所有的項目都在同一主干上進(jìn)行修改，在每周上線后并沒有明確的stable分支版本，基本上是靠SCM人員手工拷貝代碼來管理維護(hù)的。這就引起了很多問題：

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

?? 2）、由于沒有明確stable分支版本，導(dǎo)致上QA、上生產(chǎn)只能采用增量更新，上QA、上生產(chǎn)出問題后的代碼回滾很麻煩，嚴(yán)重影響了測試、上線效率。對于生產(chǎn)環(huán)境運行的代碼的具體版本并沒有明確的管理，導(dǎo)致生產(chǎn)系統(tǒng)出問題后要排查問題也很難查。

?? 3）、由于核心基礎(chǔ)包沒有與上層應(yīng)用隔離，導(dǎo)致大家都會對核心包進(jìn)行修改，修改后代碼質(zhì)量并沒有有效控制。于是出現(xiàn)因為修改基礎(chǔ)包影響整個系統(tǒng)功能等現(xiàn)象

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

? 1）、分支管理策略：采用適當(dāng)?shù)姆种Ч芾聿呗詠肀ＷC開發(fā)庫、測試庫、發(fā)布庫的隔離

? 2）、適當(dāng)引入每日編譯、持續(xù)集成、Code Review等敏捷開發(fā)的最佳實踐

? 3）、采用自動化腳本完成上QA、上生產(chǎn)的部署工作，避免人工失誤

? 4）、對核心框架、后臺應(yīng)用、前端頁面開發(fā)采用不同的配置管理策略

?

1、分支策略（Branching Strategy）

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

? 1）、不穩(wěn)定主干策略（The unstable trunk strategy）

?? 此種分支策略使用主干作為新功能開發(fā)主線，分支用作發(fā)布。此種分支管理策略被廣泛的應(yīng)用于開源項目。比如freebsd的發(fā)布就是一個典型的例子。 freebsd的主干永遠(yuǎn)是current，也就是包括所有最新特性的不穩(wěn)定版本。然后隨著新特性的逐步穩(wěn)定，達(dá)到一個發(fā)布的里程碑以后，從主干分出來一 個stable分支。freebsd是每個大版本一個分支。也就是說4.x，5.x，6,x各一個分支。每個發(fā)布分支上只有bug修改和現(xiàn)有功能的完善， 而不會再增加新特性。新特性會繼續(xù)在主干上開發(fā)。當(dāng)穩(wěn)定分支上發(fā)生的修改積累到一定程度以后，就會有一次發(fā)布。發(fā)布的時候會在穩(wěn)定分支上再分出來一個 release分支。
?? 此種分支管理策略比較適合諸如傳統(tǒng)軟件產(chǎn)品的開發(fā)模式，例如微軟Windows開發(fā)，對于互聯(lián)網(wǎng)開發(fā)不是很適合。已經(jīng)在主干上集成的新功能，如果達(dá)不到里 程碑的要求，穩(wěn)定分支就不能創(chuàng)建，很有可能影響下一個發(fā)布的計劃。還有一個問題就是bug修改必須在各個分支之間合并。

? 2）、穩(wěn)定主干策略（The stable trunk）

??? 此種分支策略使用主干作為穩(wěn)定版的發(fā)布。主干上永遠(yuǎn)是穩(wěn)定版本，可以隨時發(fā)布。bug的修改和新功能的增加，全部在分支上進(jìn)行。而且每個bug和新功能都 有不同的開發(fā)分支，完全分離。而對主干上的每一次發(fā)布都做一個標(biāo)簽而不是分支。分支上的開發(fā)和測試完畢以后才合并到主干。
??? 這種發(fā)布方法的好處是每次發(fā)布的內(nèi)容調(diào)整起來比較容易。如果某個新功能或者bug在下一次發(fā)布之前無法完成，就不可能合并到主干，也就不會影響其他變更的 發(fā)布。另外，每個分支的生命期比較短，唯一長期存在的就是主干，這樣每次合并的風(fēng)險很小。每次發(fā)布之前，只要比較主干上的最新版本和上一次發(fā)布的版本就能 夠知道這次發(fā)布的文件范圍了。
?? 此種分支策略的缺點之一是如果某個開發(fā)分支因為功能比較復(fù)雜，或者應(yīng)發(fā)布計劃的要求而長期沒有合并到主干上，很可能在最后合并的時候出現(xiàn)沖突。另外由于對于每一分支都要進(jìn)行測試才能夠合并到主干中，測試工作量較大。

? 3）、敏捷發(fā)布策略（The agile release strategy）

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

??? 采用敏捷發(fā)布策略要求主干的版本：

• 任何時候都可以發(fā)布 ：在任何時候，產(chǎn)品所有者都可以基于主干的最新版本，發(fā)布新版本的產(chǎn)品
• 希望盡早發(fā)布

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

? 關(guān)于敏捷發(fā)布策略可以參考： 多個敏捷團隊之間的版本控制

?

2、配置管理策略

?? 根據(jù)目前公司的實際情況，建議采用穩(wěn)定主干策略為主（ The stable trunk ） 。參考 淘寶網(wǎng)最佳實踐之ABS自動編譯 可以看到，淘寶也采用了類似的版本管理策略。

?? 具體操作策略如下（尚需要細(xì)化）：

?? 1）、trunk保持穩(wěn)定，保證可以隨時發(fā)布。trunk只有SCM人員才具有寫權(quán)限，開發(fā)人員等只有讀權(quán)限。

?? 2）、為降低SCM分支管理的壓力，branch的權(quán)限可以授予給指定的幾個組長

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

?????? 項目定義：新功能開發(fā)、bug修復(fù)、需求變更等

?? 4）、在每周的上線發(fā)布后，在主干建立基線release版本（通過svn tag），以當(dāng)前的主干作為基線，建立下一發(fā)布周期的test branch

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

?????? 只要對上線單命名按照規(guī)范進(jìn)行定義（例如與分支名稱相同），此部分工作可以由腳本來自動化，存在沖突再人工干預(yù)。

?? 6）、測試人員完成本發(fā)布周期test branch所有上線單的功能測試后，由SCM人員將本發(fā)布周期的test branch合并到trunk，并通過打tag來release 一個上線版本

?? 7）、系統(tǒng)人員利用自動化部署腳本從trunk檢出對應(yīng)的release版本進(jìn)行上線部署

???? 此部分工作采用自動化腳本完成，自動化腳本主要完成如下操作：從trunk檢出完整的release 版本并打包，并包含部署包的md5驗證碼-> 上傳部署包到生產(chǎn)系統(tǒng)各服務(wù)器->校驗發(fā)布包的md5驗證碼是否正確,保證文件正確傳輸->完整備份生產(chǎn)系統(tǒng)的運行包->部署生產(chǎn)系統(tǒng)

?? 8）、每日晚上對trunk進(jìn)行持續(xù)集成，保證能夠正常編譯和部署。工具建議采用 hudson

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

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

??? 開發(fā)分支的生命周期問題 ：上線后，原有的development branch變?yōu)橹蛔x的或者可以定期刪除掉。

??? 緊急上線策略 ：緊急上線不遵循每周兩次的上線周期，因此對于需要緊急上線的程序可以從trunk檢出最 近的release版本代碼建立臨時測試分支（test branch），緊急上線仍然需要按照規(guī)范建立對應(yīng)的development branch，然后與臨時測試分支合并，測試通過后上線，同時由SCM人員將緊急上線的development branch合并到當(dāng)前的測試分支，繼續(xù)進(jìn)行測試。

??? 不同項目的配置管理策略 ：對核心框架、后臺應(yīng)用、前端頁面開發(fā)可以采用不同的配置管理策略，例如核心框架可以采用不穩(wěn)定主干策略（The unstable trunk strategy）；后臺應(yīng)用采用穩(wěn)定主干策略（ The stable trunk ）

?

3、版本控制工具選擇

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

?? 因此可以結(jié)合SVN和Git/Mercurial（hg）來作為版本控制工具。用SVN進(jìn)行集中管理，用Mercurial（hg）在多個不同機器上進(jìn)行 開發(fā)，功能完善并測試完成后再提交至 SVN Repository。可以借助git-svn、HgSubversion、hgsvn這樣的工具來結(jié)合使用。考慮到目前的開發(fā)環(huán)境為Windows環(huán) 境，建議采用Mercurial。

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

4、一些工具

code review

??? http://www.reviewboard.org/

持續(xù)集成

??? https://hudson.dev.java.net/

自動部署

??? http://www.smartfrog.org/

??? http://www.capify.org

商業(yè)軟件中采用atlassian的系列產(chǎn)品倒是不錯的選擇：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

? http://www.infoq.com/cn/articles/agile-version-control

互聯(lián)網(wǎng)敏捷開發(fā)配置管理策略思考