Java項目版本管理規(guī)范

版本命名規(guī)則

Prong Boot / Prong Cloud的版本命名規(guī)范在maven的規(guī)范上做了進(jìn)一步的嚴(yán)格要求森爽，具體格式為：

<主版本>.<次版本>.<增量版本>-<代號>

代號的取值范圍：

例子：

• 開發(fā)版本：0.1.0-SNAPSHOT祈纯、0.2.0-SNAPSHOT、2.1.0-SNAPSHOT
• 穩(wěn)定版本：
  • 候選發(fā)布版本：0.1.0-RC1叼耙、1.2.0-RC2
  • 正式發(fā)布版本：0.1.0-RELEASE、0.1.1-RELEASE粒没、0.1.2-RELEASE筛婉、1.2.0-RELEASE

git-flow流程介紹

Prong Boot 和 Prong Cloud 項目遵循的是 git-flow 的分支流程規(guī)范。git 客戶端我們建議使用 SourceTree癞松，因為SourceTree 對 git-flow 提供了內(nèi)置的可視化支持爽撒，而不需要你去記住一大堆的命令。菜單入口是 倉庫 - git-flow响蓉，不同的 SourceTree 版本可能會有差異硕勿。

如果你堅持用命令行，可以參考這里枫甲。

git-flow 的總體流程示意圖如下：

image.png

branch（分支）

在 git-flow 中源武，我們有兩個永久分支：

• develop：開發(fā)分支。日常開發(fā)使用的分支想幻，項目協(xié)作者主要工作在這個分支上粱栖，同時所有的 pull request 都應(yīng)該發(fā)到這個分支；
• master：主分支脏毯。所有提供給用戶使用的正式版本（RELEASE）闹究，都在這個主分支上發(fā)布。

其實食店，永久分支只需要這兩條就夠了渣淤，不需要其他了赏寇。但是，除了永久分支以外价认，還有一些臨時分支蹋订，用于應(yīng)對一些特定目的的版本開發(fā)。臨時分支主要有三種：：

• feature/xxx：功能分支刻伊。它是為了開發(fā)某種特定功能露戒，從develop分支上面分出來的，開發(fā)完成后捶箱，要再并入develop智什。功能分支可以有多個，這些分支通常只是個人使用丁屎，存在開發(fā)者本地庫中荠锭，如果需要多人協(xié)作，則需要推送到遠(yuǎn)程倉庫晨川；
• release/xxx：發(fā)布分支证九。它是指發(fā)布正式版本之前（即合并到master分支之前），我們可能需要有一個預(yù)發(fā)布（RC）的版本進(jìn)行測試共虑。發(fā)布分支對代碼進(jìn)行了封版愧怜，不允許在發(fā)布分支上開發(fā)新功能，只允許修復(fù)測試發(fā)現(xiàn)的bug妈拌；
• hotfix/xxx：補(bǔ)丁分支拥坛。軟件正式發(fā)布以后，難免會出現(xiàn)bug尘分。這時就需要創(chuàng)建一個分支猜惋，進(jìn)行bug修補(bǔ)。補(bǔ)丁分支是從master分支上面分出來的培愁，修補(bǔ)結(jié)束以后著摔，再合并進(jìn)master和develop分支。

tag（標(biāo)簽）

標(biāo)簽是用于對應(yīng)每個預(yù)發(fā)布版本或發(fā)布版本的版本標(biāo)識定续，即 x.y.z-RCx 或 x.y.z-RELEASE

開發(fā)角色

我們在項目中定義兩類角色：

開發(fā)工程師

作為開發(fā)工程師谍咆，你有兩類分支：

• **develop **開發(fā)分支，用于下一個發(fā)布版本香罐。
• feature/xxx 功能分支卧波，用于開發(fā)新功能 xxx，根據(jù)需要可能會有多個功能分支庇茫。

新功能開發(fā)流程

要開發(fā)下一個版本的功能港粱，你要從develop分支開出新的功能分支，最后合并回develop分支，如此往復(fù)：

*    4. (develop)  合并 'feature/work-with-correcting-a' 到 develop 
|\  
| *  3. (feature/work-with-correcting-a) Correcting a
|/  
*    2.  合并 'feature/work-with-a' 到 develop 
|\  
| *  1. (feature/work-with-a)  a 
|/  
* 

注意示意圖順序都是從下往上看查坪！

為了更輕松地與其他開發(fā)工程師合作開發(fā)一個大功能寸宏，你可以從這個功能分支再開出新的功能分支。你可以將這個大型功能分支叫做集成分支偿曙。

• 在該 feature 分支上進(jìn)行開發(fā)氮凝，提交代碼，如需多人協(xié)作望忆，push 該分支到遠(yuǎn)程（origin）倉庫罩阵。
• 你應(yīng)定期rebase（變基）或合并 develop 分支的代碼到你的 feature 分支，使你的代碼保持最新启摄，并避免合并沖突稿壁。
• 你應(yīng)在完成某個功能后，盡可能快地合并 feature 分支代碼到 develop 分支并刪除該 feature 分支歉备，快速傳播你的提交以避免合并沖突傅是。

配置管理員

作為配置管理員，你有兩類分支：

• **master **生產(chǎn)分支蕾羊，代表正式發(fā)布的版本（生產(chǎn)版本）喧笔。
• release/xxx 發(fā)布分支，用于準(zhǔn)備發(fā)布版本龟再。

版本發(fā)布流程

當(dāng)準(zhǔn)備封版的時候书闸，假設(shè)你這次要發(fā)布的版本是 0.2.0-RELEASE，你需要：

• 創(chuàng)建一個候選發(fā)布版本（release candidate）吸申，即從 SourceTree 中選擇“建立新的發(fā)布版本”梗劫，發(fā)布版本號 填寫 0.2.0-RELEASE。
• 將 release/0.2.0-RELEASE 分支的版本號修改為 0.2.0-RC1截碴，發(fā)布到測試環(huán)境進(jìn)行測試。
• 將 develop 分支的版本號修改為下一個版本蛉威，即將 develop 分支的版本號修改為 0.3.0-SNAPSHOT日丹。

| *  3. 發(fā)布 RC1 到測試環(huán)境測試
| *  2. (release/0.2.0-RELEASE) 修改版本號為 0.2.0-RC1，打標(biāo)簽: 0.2.0-RC1
* |  1. (develop) 修改版本號為 0.3.0-SNAPSHOT
|/

注意蚯嫌，release/xxx 發(fā)布分支起到了凍結(jié)代碼的作用哲虾，此時不應(yīng)在這個分支上開發(fā)新的功能，RC1 版本如果測試沒有問題择示，就可以發(fā)布了束凑。但如果有bug需要修復(fù)，有以下幾種做法：

• 從 develop 進(jìn)行 Cherry Pick（遴選）
  這是最漂亮的栅盲，但也可能不可行汪诉，因為合并沖突可能會阻礙。 還有一個風(fēng)險是 develop 分支太遙遠(yuǎn)，因此很難知道修復(fù)程序在 release 分支中是否會起作用扒寄。 但我覺得它為配置管理員提供了對發(fā)布過程的最大控制權(quán)鱼鼓。
• 開發(fā)工程師從 release 分支開一個新分支并合并回去
  這通常是在大型團(tuán)隊中的首選。 它使配置管理員可以控制發(fā)布中包含的內(nèi)容该编，避免了合并沖突的風(fēng)險迄本。 可以信任在該 feature 分支上完成的測試。 可以通過PR的方式（pull requests）來完成這一切课竣。
• 直接提交到 release 分支
  這種適合純技術(shù)型團(tuán)隊嘉赎，例如配置管理員同時也是開發(fā)工程師。 在 release 分支上修復(fù)bug的同時于樟，開發(fā)工程師也可以在 develop 上繼續(xù)開發(fā)下一個版本公条。這種做法缺乏代碼審查，但在小項目中可能也不需要隔披。

如果RC1還有bug赃份，則需要在修復(fù)后發(fā)布下一個版本 RC2。

如果你用到 Cherry Pick（遴選）奢米，大概是這樣子：

| *  7. 發(fā)布 RC2 到測試環(huán)境測試
| *  6. 修改版本號為 0.2.0-RC2抓韩，打標(biāo)簽: 0.2.0-RC2
| *  5. 修改RC1中的bug
| *  4. 修改版本號為 0.2.0-SNAPSHOT
| *  3. 發(fā)布 RC1 到測試環(huán)境測試
| *  2. (release/0.2.0-RELEASE) 修改版本號為 0.2.0-RC1，打標(biāo)簽: 0.2.0-RC1
* |  1. (develop) 修改版本號為 0.3.0-SNAPSHOT
|/

其中鬓长，第4谒拴、5兩個commit是從 develop 進(jìn)行 Cherry Pick過來的。

如果RC2版本測試OK涉波，就可以準(zhǔn)備發(fā)布生產(chǎn)版本了英上。

• 修改 release/0.2.0-RELEASE 分支的版本號為 0.2.0-RELEASE。
• 在SourceTree中啤覆，選擇完成發(fā)布版本苍日，此時SourceTree會自動做以下工作：
  • 將 release/0.2.0-RELEASE 分支代碼以及RC1、RC2標(biāo)簽合并到 master 分支窗声。
  • 將 release/0.2.0-RELEASE 分支代碼合并到develop相恃。

因為合并后 develop 的版本號被改成 0.2.0-RELEASE 了，所以此時需要將 develop 的版本號改回下一個開發(fā)版本笨觅，如 0.3.0-SNAPSHOT拦耐。

打補(bǔ)丁流程

并非每個 bug 都有打補(bǔ)丁的必要，對于不緊急的 bug见剩，可以在 develop 里修復(fù)后隨下一個版本發(fā)布杀糯。

打補(bǔ)丁是指對提供給用戶使用的正式版本進(jìn)行修復(fù)。

假設(shè)要對正式版本 0.1.0-RELEASE 打補(bǔ)丁苍苞。

• SourceTree中固翰，選擇 建立新的修復(fù)補(bǔ)丁，修復(fù)補(bǔ)丁版本為 0.1.1-RELEASE ，此時 SourceTree 從 master 分支創(chuàng)建了一個補(bǔ)丁分支倦挂。
• 在補(bǔ)丁分支上修復(fù)bug畸颅，修改bug的三種做法參考版本發(fā)布流程。
• 將 hotfix/0.1.1-RELEASE 分支的版本號修改為 0.1.1-RC1方援，發(fā)布到測試環(huán)境進(jìn)行測試没炒。
• 如果測試有bug，重復(fù)以上第2犯戏、3步送火，其中第3步中的RC版本號進(jìn)行遞增。
• 測試沒問題后先匪，將 hotfix/0.1.1-RELEASE 分支的版本號修改為 0.1.1-RELEASE
• 在 SourceTree中种吸，選擇 完成修復(fù)補(bǔ)丁，此時SourceTree會自動做以下工作：
  • 將 hotfix/0.1.1-RELEASE 分支合并到 master 分支呀非。
  • 將 hotfix/0.1.1-RELEASE 分支合并到 develop 分支坚俗。
  • 在master 分支上打標(biāo)簽 0.1.1-RELEASE。
  • 最后岸裙，刪除該補(bǔ)丁分支猖败。

版本發(fā)布環(huán)境

下表列出了 Prong Boot 和 Prong Cloud 的在不同分支上發(fā)布版本時的代號，以及發(fā)布的目標(biāo)環(huán)境降允。

Prong Boot 是一個開發(fā)腳手架，發(fā)布到maven倉庫中褂微，作為maven的組件來使用，用于快速開發(fā)一個業(yè)務(wù)微服務(wù)园爷。

Prong Cloud 是一個微服務(wù)運行框架宠蚂，發(fā)布docker的私有倉庫中，再從 CaaS 平臺拉取到相應(yīng)運行環(huán)境童社。

Prong Boot規(guī)范

1求厕、同一項目中所有模塊版本保持一致

2、子模塊統(tǒng)一繼承父模塊的版本

3、統(tǒng)一在頂層模塊Pom的<dependencyManagement/>節(jié)中定義所有子模塊的依賴版本號呀癣，子模塊中添加依賴時不要添加版本號

4美浦、開發(fā)測試階段使用SNAPSHOT

5、生產(chǎn)發(fā)布使用RELEASE

6项栏、新版本迭代只修改頂層POM中的版本

用于線上發(fā)布的代碼浦辨，不可以使用包含“SNAPSHOT 版本”的依賴包，從而確保每次構(gòu)建出的產(chǎn)物都是一致的沼沈。