配置管理分支策略指引

1、分支策略指南1. 分支的重要性在日常的軟件開發(fā)工作中，項目經(jīng)常會遇到下面需求：1、 開發(fā)新版本的同時，希望能夠修改項目早期版本中的某個bug,并在修復(fù)后立即發(fā)布早 期版本的補(bǔ)?。?、 其它的小組成員為了開發(fā)某個功能占有了你希望處理的文件，因為該功能開發(fā)時間較長， 你希望不要等待他釋放后再開發(fā)自己的功能，而是同時進(jìn)行，以便節(jié)省開發(fā)時間；3、 你所做的工作涉及到許多文件，你希望能夠避免經(jīng)常打亂別人的工作，其他人的工作也不會對你產(chǎn)生影響，而且你可以將所有的工作測試完后再將它們集成到你的項目中。以上的需求都可以采用并行開發(fā)的模式來實現(xiàn)。并行開發(fā)能夠提升團(tuán)隊協(xié)作能力，提高開發(fā)效率。但是，并行開發(fā)為項目帶

2、來好處的同時，也增加了管理的難度， 需要一定的過程和方法的支持。軟件分支是軟件版本控制、軟件構(gòu)建管理和版本發(fā)布管理的重要組成部分，是支持軟件并行開發(fā)的常用機(jī)制。運(yùn)用分支使得并行開發(fā)新的系統(tǒng)、同步更改多個并行版本的錯誤、同時集成和發(fā)布多個版本成為可能。許多版本管理工具， 如ClearCase、SVN等，都支持分支。工具為我們解決了大部分并行開發(fā)的問題，我們要做的就是根據(jù)項目的具體情況，制定適合的分支策略并采用工具來實現(xiàn)。2. 常見的分支類型及適用場景軟件開發(fā)團(tuán)隊經(jīng)常使用的有幾種分支：2.1.1.組件分支概念：按照開發(fā)組所負(fù)責(zé)的組件或模塊來分，每個小組一個分支；作用：隔離模塊或組件之間的相互影響。

3、模塊或組件可單獨(dú)發(fā)布， 有獨(dú)立的發(fā)布周期或計劃。適用場景：組件或模塊需要單獨(dú)發(fā)布，發(fā)布周期不同。合并或集成策略： 每當(dāng)某個組件發(fā)布了新基線或版本，就要進(jìn)行一次集成。 為了保證“盡早并經(jīng)常集成”，可以通過發(fā)布計劃等，提高組件發(fā)布基線或版本的頻率。合并后，分支繼續(xù) 使用。2.1.2.任務(wù)分支概念：每個開發(fā)任務(wù)一個分支。例如設(shè)立新功能A開發(fā)分支，新功能 B開發(fā)分支等；作用：隔離開發(fā)周期不同的多個功能，避免相互之間的影響， 使得并行開發(fā)多個功能成為可能，節(jié)省開發(fā)時間。每個功能可獨(dú)立合并、測試，降低了集成的難度與風(fēng)險。適用場景：對軟件質(zhì)量要求較高，希望新功能可獨(dú)立測試；多個功能發(fā)布時間點不同，希望 能夠

4、同時開發(fā)，節(jié)省開發(fā)時間；一個任務(wù)所要修改的文件， 通常與其他任務(wù)要修改的文件重 疊。合并或集成策略：一旦完成，該分支就應(yīng)該被合并到其父分支中，之后該分支就會被廢棄掉。2.1.3. 活動分支概念：一個變更識別為一個活動，為每個活動創(chuàng)建一個分支。作用：使得軟件能夠快速測試、發(fā)布針對某個變更的補(bǔ)丁。容易控制軟件補(bǔ)丁的質(zhì)量。適用場景：每個變更一個分支， 管理成本較高，因此常用在需要嚴(yán)格控制變更的軟件維護(hù)階 段，或變更較少的某個開發(fā)、測試階段。才2.1.4. 開發(fā)分支概念：未發(fā)布的版本使用的分支，只進(jìn)行“新"的開發(fā)；作用：開發(fā)某個發(fā)布版的多個新功能。適用場景：不同于任務(wù)分支，一條開發(fā)分支可以用

5、于多個新功能的開發(fā)。常用在功能之間依賴性較強(qiáng)的項目中；對變更控制要求不太嚴(yán)格、軟件產(chǎn)品相對不太穩(wěn)定的開發(fā)初期或中期， 減少分支合并的工作量。合并或集成策略：按照軟件發(fā)布計劃制定合并的計劃，或周期性合并。注意，在合并時間點要確保只合并邏輯上完整的變更。2.1.5. 維護(hù)分支：概念：用于已發(fā)布版本的缺陷修復(fù)和次要的功能增強(qiáng)；作用：開發(fā)新功能的同時，維護(hù)已發(fā)布版。能夠針對特定的發(fā)布版發(fā)布補(bǔ)丁版本。隔離未發(fā)布版新功能開發(fā)對已發(fā)布版的影響。適用場景：項目組經(jīng)過一段時間的開發(fā)工作，已經(jīng)發(fā)布了一個或多個版本。為了保證維護(hù)與后續(xù)開發(fā)互不影響，同時進(jìn)行，可為每個發(fā)布版本創(chuàng)建維護(hù)分支。維護(hù)分支最終會與新版本開發(fā)作

6、集成。合并或集成策略：維護(hù)分支上每發(fā)布一個補(bǔ)丁，就要將其變更同步到開發(fā)分支?；蛘呔S護(hù)分支經(jīng)過測試后，將變更同步到開發(fā)分支。確定該版本不再維護(hù)后，該分支才可以廢棄。2.1.6.項目分支概念：按照項目創(chuàng)建的分支。例如，軟件開發(fā)過程中，從 1.0的基礎(chǔ)上開發(fā)2.0的版本，如 果1.0需要繼續(xù)開發(fā)或維護(hù)，2.0可以單獨(dú)創(chuàng)建一個分支。作用：在同一個倉庫中開發(fā)不同的項目。適用場景：在項目的某個版本上開發(fā)新版本，并且該新版本與已發(fā)布版不會被合并。7.第三方代碼分支2.1.7.第三方代碼分支合并或集成策略：通常情況下，項目分支之間只進(jìn)行通用功能或基礎(chǔ)代碼的缺陷修復(fù)的同步。 除非項目不再開發(fā)或維護(hù)，否則項目分支

7、一直存在。概念：為了保存和維護(hù)第三方代碼而創(chuàng)建的分支。在版本控制系統(tǒng)中同時保存來自供應(yīng)商的版本和項目組提供給客戶的版本。使用該分支跟蹤供應(yīng)商代碼的開發(fā)適用場景：項目需要維護(hù)和移植第三方的代碼。第三方代碼可能直接被使用， 或者經(jīng)過簡單的定制、重新打包。因項目經(jīng)常需要與供應(yīng)商發(fā)布的新版本做同步，或復(fù)制代碼供應(yīng)商的早期版本。作用：很容易獲知項目對第三方代碼修改的內(nèi)容及變更，所以很清楚需要對供應(yīng)商的某個發(fā)布版做哪些修改；很容易得知供應(yīng)商的兩個版本之間的變更內(nèi)容合并或集成策略：當(dāng)收到供應(yīng)商的新版本后，把它作為供應(yīng)商代碼分支的新版本，并將代碼從該分支合并到項目的開發(fā)分支。ohteined from ven

8、dorohteined from vendorobtained from vendor3. 常見問題及解決方案3.1.1. 如何降低變更的集成風(fēng)險？Context:開發(fā)人員完成了變更任務(wù)，準(zhǔn)備做變更的合并。因為變更所在的多個分支具有高風(fēng)險、高復(fù)雜性，需要保證合并的可靠性和一致性。Problem :誰來負(fù)責(zé)合并？誰保證集成的正確性？Solution：設(shè)置集成分支負(fù)責(zé)人。集成負(fù)責(zé)人負(fù)責(zé)將變更同步到集成分支。如果出現(xiàn)沖突，集成 負(fù)責(zé)人組織變更的所有者或代碼所有者來解決，并保證合并的正確性。合并成功之后，負(fù)責(zé)人再次將集成分支的 merge到開發(fā)分支。對于使用了ClearCase的項目來說，集成流可實現(xiàn)

9、集成分支AWCKjngjine的功能。SVN的主線也能夠?qū)崿F(xiàn)集成分支的功能。stabilize3.1.2. 如何在沒有相互影響的情況下進(jìn)行兩個發(fā)布版的開發(fā)？Context:項目組需要在短時間內(nèi)開發(fā)兩個主要的發(fā)布版。這兩個交付的日程表相當(dāng)具有挑戰(zhàn)性。Solution：因為時間不充足，必須避免一切不必要的等待和延退。在當(dāng)前的開發(fā)分支上創(chuàng)建一個新的發(fā)布分支，用于下一個增量開發(fā)。也可以將當(dāng)前開發(fā)分支合并到主線后，在主線上創(chuàng)建新的發(fā)布分支。這樣兩個增量開發(fā)可以在不同的分支上進(jìn)行。在相對較早發(fā)布的開發(fā)分支上，每隔一段時間需要將其特性和變更合并到相對較晚發(fā)布的分支中。確保變更的合并在適當(dāng)?shù)摹⒎€(wěn)定的基線級別進(jìn)

10、行、盡早并經(jīng)常進(jìn)行。新的發(fā)布分支，通常在開始為這個發(fā)布做開發(fā)時創(chuàng)建。當(dāng)然，如 果你不需要隔離兩個發(fā)布的全部工作，也可以在需要的時候再創(chuàng)建分支。3.1.3. 如何在進(jìn)行下一個版本開發(fā)的同時，及時響應(yīng)上一個版本的缺陷和功能增強(qiáng)請求，并對當(dāng)前發(fā)布版本的開發(fā)不產(chǎn)生任何影響？Context :項目的已經(jīng)完成一個發(fā)布版，準(zhǔn)備進(jìn)行下一個發(fā)布版的開發(fā)。Solution:不要在一個分支上同時進(jìn)行新版本的開發(fā)和已發(fā)布版本的維護(hù)，應(yīng)該將兩者分開 放在不同的分支上進(jìn)行。已發(fā)布版本的缺陷修復(fù)和功能增強(qiáng)在維護(hù)分支上進(jìn)行。下一個發(fā)布版本的開發(fā)在獨(dú)立的開發(fā)分支進(jìn)行。確保維護(hù)分支上的變更按一定的頻率合并到開發(fā)分支。方法一：如下

11、圖，創(chuàng)建兩個分支，一個是開發(fā)分支，一個是維護(hù)分支。方法二：更常見的做法是創(chuàng)建一個維護(hù)分支，下一個版本的開發(fā)仍然在原代碼線 上進(jìn)行。如下圖：3.1.4. 如何將分支的數(shù)雖控制在一個可管理的范圍，使項目的版本樹不會越來越寬，越來越深？Context:在開發(fā)和維護(hù)的生命周期內(nèi)，因為多種原因創(chuàng)建了很多分支。例如：開發(fā)分支、維 護(hù)分支、發(fā)布分支等。隨著時間的推移，出現(xiàn)大量的級聯(lián)分支，使項目的版本樹越來越寬。如下圖：Solution：在主線上，或貼近主線的位置保留一個“home branch ”。需要創(chuàng)建一個主要發(fā)布版本分支的時候，不要在當(dāng)前的分支上創(chuàng)建，而是先將當(dāng)前分支合并到"home bra

12、nch”，然后在"home branch”上創(chuàng)建新的分支。這條主線上不進(jìn)行任何開發(fā)工作，所有的變更都來自 于其他分支。唯一能夠在主線做的變更是，為了保證在該主線上的集成和構(gòu)建的一致性所做 的變更。3.1.5. 如何組織遠(yuǎn)程的開發(fā)任務(wù)，使得其不會對本地開發(fā)主線產(chǎn)生不利影響，并且不會對遠(yuǎn)程開發(fā)者的工作產(chǎn)生不必要的延時。Context:項目組與地理上相距較遠(yuǎn)的開發(fā)者合作開發(fā)。遠(yuǎn)程開發(fā)者可能是與項目組簽訂分包協(xié)議的分包商。本地和遠(yuǎn)程所作的變更任務(wù)最終都會被集成到同一開發(fā)線。但是你希望遠(yuǎn)程修改的代碼在合并到本地開發(fā)線之前，經(jīng)過必要的驗證。Solution:在本地使用主開發(fā)線，為每個遠(yuǎn)程站點建立

13、遠(yuǎn)程開發(fā)分支。遠(yuǎn)程開發(fā)人員在遠(yuǎn)程開發(fā)分支上工作，本地定期選擇合適的時機(jī)，驗證遠(yuǎn)程開發(fā)分支中的變更，并將變更合并到本地的主開發(fā)線。遠(yuǎn)程站點定義合適的周期，與本地開發(fā)主線做同步另外一種可行的方案是，本地也創(chuàng)建一個開發(fā)分支，本地和遠(yuǎn)程都將變更合并到本地另外一 條開發(fā)主線。這樣，本地和遠(yuǎn)程定期的與本地開發(fā)主線做同步。3.1.6. 開發(fā)人員如何知道他的代碼應(yīng)該保存在哪條分支中，什么時候保存？Context:在開發(fā)軟件系統(tǒng)的過程中，項目組使用了多種分支。開發(fā)人員很難弄清代碼應(yīng)該 保存在那條分支，什么時候保存等問題。Solution:首先，分支的名稱要有意義，易理解。其次，要制定分支的策略，策略中除了清晰簡

14、明的描述分支的目的外，還可以選擇性包含下面內(nèi)容：該分支上要做哪一類的工作。例如：開發(fā)、維護(hù)、某個特定的發(fā)布版、某個功能 或子系統(tǒng)。該分支上的元素，應(yīng)該在什么時候、如何checkout/checkin、創(chuàng)建子分支和合并？該分支對于不同組和角色的存取控制權(quán)限 該分支用于接收變更，還是將變更傳遞出去？ 該分支的使用期限和退休條件。預(yù)期的活動負(fù)載及集成頻率制定分支的策略之后，應(yīng)該將其放在大家容易獲取的位置。有些配置管理工具提供了分支命名和填寫分支注釋的功能，我們可以借用此功能保存分支策略。3.1.7. 如何判斷修改活動是否應(yīng)該在該分支執(zhí)行？由誰來決定并保證修改的完整性和一致性？Context:在眾多的

15、分支中，某個開發(fā)人員使用至少一條分支。分支策略中定義了 checkin/checkout的策略。某些人想對該分支做一些修改，但是此分支策略中并沒有描述相 關(guān)內(nèi)容，或者描述模糊Solution：為每個分支分配一個所有者，該所有的職責(zé)包括：澄清分支的策略等。決定是保留還是丟棄違反分支策略checkin的代碼。協(xié)助或執(zhí)行向該分支中合并變更。決定該分支什么時候應(yīng)該被凍結(jié)和解凍，什么時間結(jié)束并合并到主線。設(shè)置分支的訪問控制權(quán)限。分支的所有者有權(quán)限控制的職責(zé)。例如下面的權(quán)限設(shè)置：只有分支的所有者才能checkin文件；其他人在得到了分支所有者的授權(quán)才能checkin；在checkin之后立即通知分支所有者；通常存取次數(shù)多的分支，需要更嚴(yán)格的權(quán)限控制策略。4. 分支使用的幾點原則及注意事項使用有意義的分支名稱：有意義的分支名稱方便管理，便于開發(fā)人員選擇正確 的分支存取代碼。使用多分支而不是凍結(jié)代碼：例如使用主線集成開發(fā)分支的變更，而不是在主線上開發(fā)。否則版本發(fā)布時需要凍結(jié)主線代碼進(jìn)行驗證和修復(fù)，浪費(fèi)開發(fā)時間。盡早并經(jīng)常集成：分支中新的變更一旦準(zhǔn)備好，就應(yīng)該進(jìn)行變更合并。為不兼容的開發(fā)創(chuàng)建分支：使用分支作不兼容開發(fā)，能夠很好的避免相互影響， 提高質(zhì)量和開發(fā)速度。創(chuàng)建適當(dāng)數(shù)量的分支： 不要期望分支可以解決項目的所有問