1、互聯(lián)網(wǎng)敏捷開發(fā)配置管理策略思考由于互聯(lián)網(wǎng)行業(yè)需求變化快、開發(fā)迭代周期短、上線頻繁的現(xiàn)實狀況 決定了合理的軟件配置管理策略對于軟件質量保證、協(xié)作開發(fā)效率至 關重要。目前公司配置管理在策略上采用的是不穩(wěn)定主于Unstable-trunk） 模式，所有的項目都在同一主十上進行修改，在每周上線后并沒有明 確的stable分支版本，基本上是靠SCM人員手工拷貝代碼來管理維 護的。這就引起了很多問題：1）、多個項目組開發(fā)人員都可能并發(fā)對同樣代碼進行修改，造成了 嚴重的代碼沖突問題。例如張三修改了a.java并上QA測試服務器， 在QA測試過程中，李四也對a.java進行修改并上QA，李四的代碼 覆蓋了張三

2、的代碼。由于是SCM人員并不清楚代碼沖突情況，這樣 張三和李四的代碼上QA很容易相互影響并很難查具體原因2）、由于沒有明確stable分支版本，導致上QA、上生產(chǎn)只能采用 增量更新，上QA、上生產(chǎn)出問題后的代碼回滾很麻煩，嚴重影響了 測試、上線效率。對于生產(chǎn)環(huán)境運行的代碼的具體版本并沒有明確的 管理，導致生產(chǎn)系統(tǒng)出問題后要排查問題也很難查。3）、由于核心基礎包沒有與上層應用隔離，導致大家都會對核心包 進行修改，修改后代碼質量并沒有有效控制。于是出現(xiàn)因為修改基礎 包影響整個系統(tǒng)功能等現(xiàn)象類似的問題很多。要在新的項目實施及后期運營中避免類似問題的重 現(xiàn)，至少要從如下幾個方面來：、分支管理策略：采用

3、適當?shù)姆种Ч芾聿呗詠肀ＷC開發(fā)庫、測試 庫、發(fā)布庫的隔離、適當引入每日編譯、持續(xù)集成.Code Review等敏捷開發(fā)的最 佳實踐、采用自動化腳本完成上QA、上生產(chǎn)的部署工作，避免人工失 誤、對核心框架、后臺應用、前端頁面開發(fā)采用不同的配置管理策 略1、分支策略(Branching Strategy)代碼分支管理策略一般分為3種(參考Branching Strategy Questioned1)、不穩(wěn)定主干策略(The unstable trunk strategy)此種分支策略使用主干作為新功能開發(fā)主線，分支用作發(fā)布。此種分 支管理策略被廣泛的應用于開源項目。比如freebsd的發(fā)布就是一個

4、典型的例子。freebsd的主干永遠是current，也就是包括所有最新特 性的不穩(wěn)定版本。然后隨著新特性的逐步穩(wěn)定，達到一個發(fā)布的里程 碑以后，從主十分出來一個stable分支。freebsd是每個大版本一個 分支。也就是說4.x，5.x，6,x各一個分支。每個發(fā)布分支上只有bug 修改和現(xiàn)有功能的完善，而不會再增加新特性。新特性會繼續(xù)在主干 上開發(fā)。當穩(wěn)定分支上發(fā)生的修改積累到一定程度以后，就會有一次 發(fā)布。發(fā)布的時候會在穩(wěn)定分支上再分出來一個release分支。此種分支管理策略比較適合諸如傳統(tǒng)軟件產(chǎn)品的開發(fā)模式，例如微軟 Windows開發(fā)，對于互聯(lián)網(wǎng)開發(fā)不是很適合。已經(jīng)在主十上集成的

5、新功能，如果達不到里程碑的要求，穩(wěn)定分支就不能創(chuàng)建，很有可能 影響下一個發(fā)布的計劃。還有一個問題就是bug修改必須在各個分 支之間合并。2)、穩(wěn)定主干策略(The stable trunk)System version branch此種分支策略使用主干作為穩(wěn)定版的發(fā)布。主干上永遠是穩(wěn)定版本， 可以隨時發(fā)布bug的修改和新功能的增加，全部在分支上進行。而 且每個bug和新功能都有不同的開發(fā)分支，完全分離。而對主十上 的每一次發(fā)布都做一個標簽而不是分支。分支上的開發(fā)和測試完畢以 后才合并到主十。這種發(fā)布方法的好處是每次發(fā)布的內容調整起來比較容易。如果某個 新功能或者bug在下一次發(fā)布之前無法完成，

6、就不可能合并到主干， 也就不會影響其他變更的發(fā)布。另外，每個分支的生命期比較短，唯 一長期存在的就是主干，這樣每次合并的風險很小。每次發(fā)布之前， 只要比較主干上的最新版本和上一次發(fā)布的版本就能夠知道這次發(fā) 布的文件范圍了。此種分支策略的缺點之一是如果某個開發(fā)分支因為功能比較復雜或 者應發(fā)布計劃的要求而長期沒有合并到主十上，很可能在最后合并的 時候出現(xiàn)沖突。另外由于對于每一分支都要進行測試才能夠合并到主 于中，測試工作量較大。3)、敏捷發(fā)布策略(The agile release strategy)此種模式在采用敏捷開發(fā)模式（例如Scrum）的項目中廣泛采用，這 些項目有固定的迭代周期（例如Sc

7、rum中每個Sprint的兩周時間）， 新的功能開發(fā)都在Task branch（Feature branch）上進行，在接近迭 代周期的發(fā)布階段時候，新建Release branch來完成本迭代周期的 發(fā)布，各 Task branch（Feature branch的功能 merge 至U Release Branch中。在完成發(fā)布后，Release branch的功能merge到Trunk 和尚在進行的Task branch中。采用敏捷發(fā)布策略要求主干的版本：.任何時候都可以發(fā)布：在任何時候，產(chǎn)品所有者都可以基于主 十的最新版本，發(fā)布新版本的產(chǎn)品.希望盡早發(fā)布此種模式較適合敏捷開發(fā)軟件的要求，

8、但對程序員及SCM要求較高。關于敏捷發(fā)布策略可以參考：多個敏捷團隊之間的版本控制2、配置管理策略根據(jù)目前公司的實際情況，建議采用穩(wěn)定主十策略為主（The stable trunk）。參考淘寶網(wǎng)最佳實踐之ABS自動編譯可以看到，淘寶也 采用了類似的版本管理策略。具體操作策略如下（尚需要細化）：1 ） trunk保持穩(wěn)定，保證可以隨時發(fā)布。trunk只有SCM人員才 具有寫權限，開發(fā)人員等只有讀權限。2）、為降低SCM分支管理的壓力，branch的權限可以授予給指定 的幾個組長3）、在每一個項目開始前，采用 Branch per feature（Branch per Task） 的分支管理模式（C

9、ommon Branching Patterns），由各組長或SCM 人員按照branch管理規(guī)范建立對應項目的開發(fā)分支development branch，例如 airline_product1_feature_leader_dat& airline_product2_bug_leader_dateb項目定義：新功能開發(fā)、bug修復、需求變更等4）、在每周的上線發(fā)布后，在主干建立基線release版本（通過svn tag），以當前的主干作為基線，建立下一發(fā)布周期的test branch5）、開發(fā)人員在所在項目的development branch完成開發(fā)及集成測 試后提交上線單，由SCM人員

10、根據(jù)項目上線單的分支名稱merge分 支代碼到本發(fā)布周期的test branch，進行測試。如果在測試過程中 有新的上線單且有可能與其他上線單存在沖突，則在merge到test branch的過程中，SCM人員可以很容易及時排查問題。只要對上線單命名按照規(guī)范進行定義（例如與分支名稱相同），此部 分工作可以由腳本來自動化，存在沖突再人工干預。6）、測試人員完成本發(fā)布周期test branch所有上線單的功能測試后, 由SCM人員將本發(fā)布周期的test branch合并到trunk,并通過打tag 來release 一個上線版本7）、系統(tǒng)人員利用自動化部署腳本從trunk檢出對應的release版

11、本 進行上線部署此部分工作采用自動化腳本完成，自動化腳本主要完成如下操作：從 trunk檢出完整的release版本并打包，并包含部署包的md5驗證碼 -上傳部署包到生產(chǎn)系統(tǒng)各服務器校驗發(fā)布包的md5驗證碼是否 正確，保證文件正確傳輸- 完整備份生產(chǎn)系統(tǒng)的運行包-部署生產(chǎn)系 統(tǒng)8）、每日晚上對t runk進行持續(xù)集成，保證能夠正常編譯和部署。工具建議采用hudson9）、對于核心代碼及后臺代碼的修改，采用Pre-commit review模 式，必須通過code review后，才能夠提交到trunk中。工具可以采 用 reviewboard10）、其他一些值得討論的問題 開發(fā)分支的生命周期問

12、題：上線后，原有的development branch變?yōu)橹蛔x的或者可以定期刪除掉。緊急上線策略：緊急上線不遵循每周兩次的上線周期，因此對于需要 緊急上線的程序可以從trunk檢出最近的release版本代碼建立臨時 測試分支(test branch)，緊急上線仍然需要按照規(guī)范建立對應的 development branch,然后與臨時測試分支合并，測試通過后上線， 同時由SCM人員將緊急上線的development branch合并到當前的 測試分支，繼續(xù)進行測試。不同項目的配置管理策略：對核心框架、后臺應用、前端頁面開發(fā)可 以采用不同的配置管理策略，例如核心框架可以采用不穩(wěn)定主十策略(Th

13、e unstable trunk strategy)；后臺應用采用穩(wěn)定主干策略The stable trunk)3、版本控制工具選擇SVN的集中管理模式較為適合目前公司協(xié)作開發(fā)的需要，例如SVN 所提供的集中式權限控制，對代碼、二進制文件及文檔的集中管理， 類似TortoiseSVN的支持工具以及Eclipse插件等。而Git/Mercurial (hg)的分布式管理特性，很適合開發(fā)人員本地版本開發(fā)管理。因此可以結合SVN和Git/Mercurial (hg)來作為版本控制工具。用 SVN進行集中管理，用MercuriaKhg)在多個不同機器上進行開發(fā)， 功能完善并測試完成后再提交至SVN R

14、epository?？梢越柚鷊it-svn、 HgSubversion、hgsvn這樣的工具來結合使用?？紤]到目前的開發(fā)環(huán)境為Windows環(huán)境，建議采用Mercurial值得一提的是SVN從1.5版本開始，對branching merge的支持有 很大的提升，大大簡化了分支合并的難度，可以參考Whats Newin Subversion 1.6?4、一些工具code review HYPERLINK / /持續(xù)集成 HYPERLINK / /自動部署 HYPERLINK / / HYPERLINK 商業(yè)軟件中采用atlassian的系列產(chǎn)品倒是不錯的選擇：Jira+Crucible+Fish

15、Eye+Bamboo5、參考文檔 HYPERLINK /3223 /3223/ HYPERLINK http:/svnbook.red-bean.cOm/en/1.5/svn-book.html%23svn.branchme http:/svnbook.red-bean.cOm/en/1.5/svn-book.html#svn.branchmermonpatterns.feature HYPERLINK /bliki/FeatureBranch.html /bliki/FeatureBranch.html HYPERLINK http:/codicesoftware.blogspot.eom/

16、2010/03/branching-strategies http:/codicesoftware.blogspot.eom/2010/03/branching-strategies.h tml HYPERLINK /en-us/library/bb668955.aspx /en-us/library/bb668955.aspx HYPERLINK /en-us/library/aa730834(VS.80).aspx /en-us/library/aa730834(VS.80).aspx HYPERLINK /bradapp/acme/branching/ /bradapp/acme/branching/ HYPERLINK /steve/perforce/Branching_Strategies.htm /steve/perforce/Branching Strategies.html HYPERLINK http:/blog.gravityfree.ca/2009/02/using-feature-branches