[原創]maven release 配合svn/git的版本控制使用

[原創]maven release使用說明

maven release插件的介紹

    maven release是用於提供在將maven工程，從開發轉爲發佈的時候自動修改包版本使用的；在工程依賴負責的時候，避免了手工修改可能致使的問題；具體舉個例子：     這個是一個很現實的工程，工程中 ecp-services 是全部的服務包，服務包之間根據業務的需求會有部分的耦合；原來開發的時候全部的版本都是使用了 snapshot；而到了正式發佈的時候，須要修改成release；那麼這麼多個包，就須要挨個修改；並且其中依賴的版本也須要從 snapshot 修改成release ;很容易出現錯漏；     針對這樣的問題，引入 maven release插件能夠很智能得解決這個問題；

使用介紹

在工程的頂級父pom.xml中增長如下配置

其中引用了 release插件，目前建議使用2.5.3 的版本；

幾個實例的測試

例子中的源碼是使用了git

release:update-version

修改當前工做區的pom的版本號，包括子模塊，及模塊之間相互依賴的版本號； mvn --batch-mode release:update-versions -DdevelopmentVersion=1.3.3-SNAPSHOT -DupdateDependencies=true

updateDependencies的參數在2.5.2以後的版本支持，因此release-plugin的版本要求爲2.5.2 ，以上命令執行以後，會修改當前工做分支的pom的版本號爲1.3.3-SNAPSHOT，包括將子模塊和子模塊互相依賴的版本進行調整；update-release的描述

release:branch

打分支，並修改分支的版本號；官方release:branch的參數說明

1. mvn release:branch -DbranchName=1.1.1 -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DdryRun=true -DpushChanges=false

• 這個打分支的腳本，版本不會修改成 release，仍是原來的snapshot
• -DdevelopmentVersion=1.0.3 -DupdateWorkingCopyVersions=true 執行當前工做區新的版本號，若是當前工做區版本號不須要修改，則 DupdateWorkingCopyVersions 設置爲false;
• -DdryRun=true 用於在進行驗證的時候使用，該參數設置爲true，則不會提交到版本控制區，只會在當前版本修改版本號；會生成一個pom.xml.branch的文件；這個是分支的文件；
• -DpushChanges=false 用於git，表示是否往遠端推送當前的變動；默認true 會推送；
• -DreleaseVersion=1.0.1-SNAPSHOT -DupdateBranchVersions=true 用於指定新的分支的版本號；新分支的版本號若是要修改，則：updateBranchVersions 必須設置爲true;
• -DupdateVersionsToSnapshot=true 是否將分支版本修改成 Snapshot

2. mvn release:branch -DbranchName=1.2.1 -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DdryRun=true -DpushChanges=false

本地不會有分支，多出了pom.xml.branch的文件，在該文件中修改了版本號；

3. mvn release:branch -DbranchName=1.2.1 -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DpushChanges=false

本地有分支，建立分支以後，又退回到當前branch ； git的路線以下圖所示

4. mvn release:branch -DbranchName=1.3.1 -DreleaseVersion=1.3.1-RELEASE -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DdryRun=true -DpushChanges=false

這樣寫是沒用的，同樣不會變成 release 版本；出來的版本號，因爲原來是1.0.0-SNAPSHOT；新的分支的版本號變成是：1.3.1-RELEASE-SNAPSHOT；

release:prepare

先給一個prepare的官網說明；如下是一些經常使用的參數特別說明和例子；

1. mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-RELEASE -Dtag=busi-1.0.1-RELEASE -DignoreSnapshots=true

-DupdateWorkingCopyVersions=false 設置爲false 表示不修改當前工做區的版本號；若是設置爲 true，則須要增長一個參數：-DdevelopmentVersion=1.0-SNAPSHOT表示當前工做區新的版本號； -DreleaseVersion=1.0.1-RELEASE 表示打的tag的版本號； -Dtag=busi-1.0.1-RELEASE -DtagNameFormat=@{project.artifactId}-@{project.version} 表示tag的名字，默認的tagNameFormat就是@{project.artifactId}-@{project.version}，因此沒有配置 tag ，也會有tag出來，並且tag的名字就是根據tagNameFormat出來的格式；

2. mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-RELEASE -Dtag=busi-1.0.1-RELEASE -DignoreSnapshots=true -DdryRun=true

帶上了 -DdryRun的參數，設置爲true，在執行以後並不會真的打tag了，而是生成一個對應的pom.xml.tag文件，這個文件是指tag中使用的pom.xml;

3. mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.1.1-RELEASE -Dtag=busi-1.1.1-RELEASE -DignoreSnapshots=true -DpushChanges=false

以上命令執行完成以後，會在本地生成一個tag，tag名稱爲：ecp-busi-1.1.1-RELEASE；其中對應得版本路徑以下所示； 特別說明

• 執行了 release:prepare以後，tag打了，在目錄下還會遺留下 pom.xml.releaseBackup 、release.properties的文件，這個是用於若是執行的時候，出現了錯誤，進行回退使用的；回退命令：release:rollback；回退以後會將以前打的tag刪除了；
• 若是執行正確，可使用release:clean 命令清理 pom.xml.releaseBuckup 和 relase.properties文件；
• 執行了release:prepare以後，能夠經過 release:perform進行打包生成；--固然也能夠不作這一步；注意：執行了release:prefomr會自動執行release:clean

結合 maven release插件進行的代碼發佈版本控制

流程1

    目前咱們爲了保證開發的流暢性，每次的要發佈的代碼是基於某個開發主幹進行打發布分支的；而發佈分支的包版本就已經調整爲 release 了，因此咱們使用的流程以下：

1. 基於開發主幹/或者某個開發分支，執行 release:prepare的操做，打出一個發佈的tag (release-tag); mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.1.1-RELEASE -Dtag=busi-1.1.1-RELEASE -DignoreSnapshots=true

2. 基於發佈的tag ，生成一個branch (release-branch)

• svn 使用 cp 命令
• git 使用 git checkout tagname -b branch_tagname 其中的tagname 是指tag的名稱

流程2

    爲了保證延續性，讓開發分支每次打了release以後，開發版本遞增；發佈分支剛開始的時候也使用snapshot版本，在正式發佈的時候使用release，就能夠採用如下的流程：

1. 基於開發/或者某個開發分支，執行 release:branch 命令，打出一個 release 分支；（包版本是 snapshot）； mvn release:branch -DbranchName=branch-1.2.1-release -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DdevelopmentVersion=1.2.2-SNAPSHOT -DupdateWorkingCopyVersions=true -DupdateVersionsToSnapshot=false

以上將會出現一個branch-1.2.1-release的分支，而且版本爲：1.2.1-SNAPSHOT，而且開發分支的版本修改成：1.2.2-SNAPSHOT；若是不但願修改開發分支的版本，則：-DupdateBranchVersions=false 並去掉 -DdevelopmentVersion=1.2.2-SNAPSHOT

2. QA 在發佈分支測試經過以後，對發佈分支打上tag ; mvn release:prepare的操做，執行成功以後，執行mvn release:preform 進行打包處理（或者 checkout tag的代碼，經過 maven 命令進行打包 deploy / package 之類的）；

目前咱們使用的是第一種方式；由於咱們爲了保證包的正確性，在QA打了tag以後，還須要不斷的測試；若是出現問題，要刪除tag，並經過2的命令從新進行release:prepare的處理；因此，咱們乾脆就開始就給release，以後QA每次清理本地maven倉庫的包，從新打release包；

本文檔是 maven release + git 驗證經過；實際上 maven release + svn 也是能夠的（咱們在遷移到git以前一直用的是svn），流程同樣