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

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

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

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

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

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

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

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

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

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

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

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

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

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

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