 一：主干發(fā)布先說主干發(fā)布模式: 以SVN庫為例,大致將庫分為trunk, branch,tag三種,主線發(fā)布就是公司要發(fā)布某個(gè)產(chǎn)品的V1版本,之前大家都做會(huì)在SVN的trunk上做開發(fā),等trunk穩(wěn)定了.開出一個(gè)分支B1,在B1分支上做V1版本的其它功能添加,bug修改等,并使用持續(xù)集成來驗(yàn)證B1的穩(wěn)定性.直到V1版本達(dá)到要求,可以對(duì)外發(fā)布,并且發(fā)布成功后,進(jìn)行從branch到trunk的merge操作,此時(shí)trunk上的內(nèi)容變成了V1版本的內(nèi)容,而后trunk上的內(nèi)容不再允許修改.然后,再發(fā)布V2,這個(gè)時(shí)候,比如下一個(gè)版本要發(fā)布V2版,這時(shí)從trunk的V1版發(fā)布的那個(gè)點(diǎn),開一個(gè)分支B2出來,再進(jìn)行V2版的開發(fā),并做持續(xù)集成驗(yàn)證V2版的穩(wěn)定性.直到V2版也達(dá)到要求,并且對(duì)外發(fā)布以后,將B2merge到trunk上,此時(shí)的trunk上的內(nèi)容又變成了V2版本的內(nèi)容. 依次類推, 直到V3,V4,V5等.我們稱這種發(fā)布模式為主干發(fā)布,因?yàn)橹鞲缮系臇|西永遠(yuǎn)都是發(fā)布后的產(chǎn)品, 而且不允許修改. 如下圖:
如果按照這種方式發(fā)布的優(yōu)點(diǎn)：
第一：可以隨時(shí)保證trunk上的東西的穩(wěn)定性，使trunk隨時(shí)可用；
第二：大部分開發(fā)人員不會(huì)去觸碰trunk，用分支的方式解決實(shí)際開發(fā)過程中的一些變更（需求變更或設(shè)計(jì)變更等）；
第三：可以從trunk上隨時(shí)拿到已發(fā)布的任意一個(gè)版本。
如果按照這種方式發(fā)布存在的不足:
第一: 開發(fā)的時(shí)候, 持續(xù)集成一直在驗(yàn)證著Branch上的穩(wěn)定性和正確性,而對(duì)于release完成后merge到trunk上后, 沒有對(duì)trunk進(jìn)行集成驗(yàn)證, 難以保證trunk的穩(wěn)定性；
第二：違背了SVN的規(guī)范，把trunk庫當(dāng)成了tag庫去使用；
第三：某些開源項(xiàng)目會(huì)采用這種開發(fā)（發(fā)布）模式，但其中對(duì)于驗(yàn)證要求非常嚴(yán)格，merge起來很費(fèi)時(shí)，鑒于開源項(xiàng)目的特殊性，暫不做討論；
第四：一般采用這種模式發(fā)布，是有自己的考慮在里面的。那就是trunk上的東西是不能損壞的，必須隨時(shí)是好的，即使偶爾出現(xiàn)問題也能及時(shí)修正，但trunk已經(jīng)完全失去了它做為主干的意義，也很難保證SVN庫的一致性。
二：分支發(fā)布 再說分支發(fā)布模式: 以SVN庫為例,大致將庫分為trunk, branch, tag三種,所有開發(fā)人員基于trunk進(jìn)行開發(fā),比如也是要發(fā)布V1版本的產(chǎn)品,到trunk上的內(nèi)容穩(wěn)定后,版本達(dá)到了要release的要求,這時(shí)從trunk上開分支出來,我們可以稱這個(gè)B1分支上的內(nèi)容為pre-release版,此時(shí)這個(gè)B1分支只為fixbug, 除非有必須要加的新功能.這個(gè)時(shí)候呢,大部分的開發(fā)人員就可以在trunk上開發(fā)下一次的發(fā)布,而只需要少部分開發(fā)人員基于B1分支fix bug.如果有bug需要在B1和trunk里面都fix的話,就會(huì)有少量的merge操作,如非必要,就省心了. B1分支開出來后,一旦release了,可以根據(jù)發(fā)布計(jì)劃,選擇是否需要保留.如果近期有發(fā)B1的update計(jì)劃,則可以保留;如果近期都不會(huì)再有基于B1的開發(fā),可以將V1發(fā)布這一時(shí)刻點(diǎn)的B1狀態(tài)通過tag的方式記錄下來,然后消亡B1分支.我們稱這種模式為分支發(fā)布,因?yàn)榉种Р攀前l(fā)布的線,主干可以一直進(jìn)行開發(fā),而沒有必要停止. 如下圖:
如果按照這種方式發(fā)布的優(yōu)點(diǎn)：
第一：trunk做為開發(fā)主線，開發(fā)人員可以隨時(shí)將自己符合要求的代碼提交到trunk上，如果在沒有必要的條件下，不開分支。同時(shí)對(duì)trunk做持續(xù)集成驗(yàn)證，最大程度上保證trunk的穩(wěn)定性。
第二：對(duì)每次成功的持續(xù)集成都同時(shí)對(duì)庫和集成環(huán)境做tag操作，發(fā)揮tag庫的強(qiáng)大作用。
第三：最大量的減少了merge操作，降低了誤差。一旦要發(fā)布產(chǎn)品，只需從一個(gè)穩(wěn)定的版本（公司上層同意的）發(fā)一個(gè)分支出來，然后再投入少量的開發(fā)人員去進(jìn)一步優(yōu)化，主要是fixbug。而這時(shí)，大部分開發(fā)人員就可以投入到下一個(gè)版本的開發(fā)中,最大力度的使用人力資源。
第四：其它.
如果按照這種方式發(fā)布存在的不足:
第一：配置管理需要隨時(shí)了解pre-release的分支是否需要保留，以為下一次發(fā)布update等做準(zhǔn)備。
第二：如果有大型的變更，trunk可能會(huì)被破壞，但是如果有一套規(guī)范，可以把風(fēng)險(xiǎn)降到最低。（或者也可以通過開分支的方式來解決這種問題）
第三：如果想要真正發(fā)揮這種發(fā)布模式的威力，配置管理，變更管理，持續(xù)集成，質(zhì)量管理，發(fā)布管理每一個(gè)模塊都是不可少的。
|
|
|
