svn項(xiàng)目版本分支管理ppt課件.ppt

1、項(xiàng)目版本分支管理,1,問題,目前公司配置管理在策略上采用的是不穩(wěn)定主干（unstable trunk）模式，所有的項(xiàng)目都在同一主干上進(jìn)行修改，在每次上線后并沒有明確的stable分支版本。 1）、多個項(xiàng)目組開發(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)出問題后

2、的代碼回滾很麻煩，嚴(yán)重影響了測試、上線效率。對于生產(chǎn)環(huán)境運(yùn)行的代碼的具體版本并沒有明確的管理，導(dǎo)致生產(chǎn)系統(tǒng)出問題后要排查問題也很難查。 3）、由于核心基礎(chǔ)包沒有與上層應(yīng)用隔離，導(dǎo)致大家都會對核心包進(jìn)行修改，修改后代碼質(zhì)量并沒有有效控制。于是出現(xiàn)因?yàn)樾薷幕A(chǔ)包影響整個系統(tǒng)功能等現(xiàn)象。,2,穩(wěn)定主干策略,使用主干作為穩(wěn)定版的發(fā)布。 bug的修改和新功能的增加，全部在分支上進(jìn)行。 緊急缺陷修改或新功能開發(fā)以分支隔離。 分支上的開發(fā)和測試完畢以后才合并到主干。 主干上的每一次發(fā)布都做一個標(biāo)簽而不是分支。 每次發(fā)布的內(nèi)容調(diào)整起來比較容易。 缺點(diǎn)是分支合并所增加的成本。,3,現(xiàn)狀及解決途徑,團(tuán)隊(duì)當(dāng)前情況：

3、 1）新專業(yè)的不斷開發(fā)，發(fā)布更新較為頻繁。 2）有固定的發(fā)布周期，同時(shí)也存在比較多的Bug。 3）修改任務(wù)通常比較小，改動范圍通常不大，時(shí)間通常較短。 4）不同的功能模塊有不同的小組負(fù)責(zé)，耦合度相對較低。,解決途徑： 1）、分支管理策略：采用適當(dāng)?shù)姆种Ч芾聿呗詠肀ＷC開發(fā)庫、測試庫、發(fā)布庫的隔離。 2）、適當(dāng)引入每日編譯、持續(xù)集成、Code Review等敏捷開發(fā)的最佳實(shí)踐。,4,Trunk,R1.0版本發(fā)布,建立開發(fā)分支1,建立開發(fā)分支2,主干復(fù)制測試分支,合并,bug fix,測試發(fā)布A,合并,tag01,B1.1.3集成,緊急缺陷測試分支,Hotfix,測試發(fā)布B,合并,tag02,主干時(shí)

4、刻處于穩(wěn)定狀態(tài)，隨時(shí)可以發(fā)布,B1.1.4集成,測試分支,bug fix,合并,測試發(fā)布C,tag03,V1.1發(fā)布,合并,改進(jìn)的版本分支管理方案,5,1、主干時(shí)刻處于穩(wěn)定狀態(tài)，隨時(shí)可以發(fā)布。設(shè)SCM人員對主干代碼進(jìn)行管理，普通開發(fā)人員只讀。 2、SCM為開發(fā)任務(wù)建立開發(fā)分支。常規(guī)的可以以小組為單位建立分支，較大的任務(wù)可以建立專門的分支。 3、B版本集成之日或提前，從主干復(fù)制一個測試分支，包含在該版本的各開發(fā)分支向此測試分支合并。 4、對測試分支代碼進(jìn)行測試，出現(xiàn)bug在測試分支上更改，無誤后發(fā)布。 5、測試分支代碼發(fā)布后，合并入主干，并在主干上進(jìn)行標(biāo)記。 6、對緊急修復(fù)（Hotfix）的情況

5、，可以從主干復(fù)制出測試分支，在測試分支上進(jìn)行緊急修改，并在測試后發(fā)布，發(fā)布后同樣將代碼合并會主干，做標(biāo)記（Hotfix僅限于可以很快解決的小問題，如果更改時(shí)間過長，則需采用常規(guī)方法完成）。 7、如果在測試分支測試過程中需要Hotfix工作，則再復(fù)制一個新的測試分支進(jìn)行Hotfix ，測試后發(fā)布。然后同時(shí)合并入原測試分支和主干，并在主干上做標(biāo)記（此過程未在上圖中畫出）。 9、測試分支發(fā)布后，開發(fā)分支可以刪除；測試分支合并入主干后，測試分支可以定期刪除。,實(shí)施過程,6,方案優(yōu)點(diǎn) 解決了沒有實(shí)施分支策略時(shí)，代碼不能經(jīng)常簽入的問題。 主干代碼始終處于穩(wěn)定的狀態(tài)隨時(shí)可以發(fā)布，降低了風(fēng)險(xiǎn)。 可以基于一個完整的測試分支進(jìn)行測試及發(fā)布，而不是以口口相傳的方式增量更新。 方案缺點(diǎn) 建立分支、合并分支增加了工作量?？紤]實(shí)際情況，以及版本控制工具的輔助，增加的工作量應(yīng)該可以接受。 如果某些開發(fā)分支工期跨越多個發(fā)布周期，修改過于劇烈，合并分支時(shí)