Maven Release釋出指南---Git版

雲逸_發表於2018-09-05
MavenGit

1.RELEASE的說明

1.1snapshot與release的區別

大多數java開發的小夥伴都用過maven來對包進行管理。在自己寫專案的過程中，對自己的專案也會進行groupdId，artifactId,version的配置。下面我們來對著3個配置進行簡單說明。

  1. groupId:顧名思義，這個裡面包含的是本專案屬於哪一個group（即組織或公司）。一般我們會用公司或者自己的前幾級包名來進行定義。
  2. artifactId:這個值定義的是本專案的名字。
  3. version:這個就是我們今天講解的關鍵了。這個專案在maven進行釋出以後的版本號。

一般，我們在剛開一個專案以後會將version定義為1.0-SNAPSHOT。snapshot單詞從字面意思來說，是快照、照相的意思。為什麼我們新的專案要使用SNAPSHOT呢？而不是我們引入的那些公共包的.RELEASE或者只有版本號什麼都不帶呢？這兩個又有什麼區別呢？聽我慢慢道來：
一個專案在未上線釋出之前會在測試環境或者開發環境中進行測試和調整，也有可能有需求變更和重構。所以，snapshot說明了，這個包還未固化其自身提供的服務。在使用帶有snapshot的包的時候要特別小心。他很可能發生變化，不知道什麼時候你之前使用的功能就會被這個包的維護人員幹掉或者改變了。
而大家使用的類似Spring之類的公共開源包都是以RELEASE結尾的，這說明了當前這個版本號的包會穩定的提供功能服務，不會發生任何變化。如果需要變化只能通過修改版本號。

1.2release的必要性

當我們的專案達到了當前的目標，在經過檢測後不需要改變。這時我們就需要將SNAPSHOT版本打包成RELEASE版本。只有這樣，使用這個包的使用者才能放心的將這個版本的包放入自己的專案中使用。並且，不會擔心這個功能包提供的功能會隨時發生改變。
接下來我們就學習如何將在git中管理的功能包從snapshot打包成為release版本

2.scm的配置

scm是mvn為我們提供的，對版本管理軟體進行管理和操作的外掛。由於本指南只講解打包過程，不會詳細講解本工具的具體概念和使用方式。

<project>
<scm> 
        <!--release包需要放入的nexus或者其他maven release包的倉庫url地址-->
        <url>http://xxxx/nexus/content/repositories/releases/</url>
        <!--connection, developerConnection: 都是連線字串，其中後者是具有write許可權的scm連線 -->
        <!--需要打包專案的git地址-->
        <developerConnection>scm:git:http://xxxx/c-h5/portal-common-base.git</developerConnection>
         <!--需要打包專案的git地址-->
        <connection>scm:git:http://xxx/c-h5/portal-common-base.git</connection>
        <!---->
        <tag>HEAD</tag>
    </scm>
</project>
複製程式碼

3.maven-release-plugin的配置

<build>
 <plugins>
            <!-- 釋出外掛 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.5.3</version>
                <configuration>
                    <!--git使用者名稱-->
                    <username>xxxxx@shishike.com</username>
                    <!--git密碼-->
                    <password>xxxx</password>
                    <!--mvn目標指令-->
                    <goals>-f pom.xml deploy</goals>
                </configuration>
            </plugin>
        </plugins>
</build>        
複製程式碼

4.release的操作流程

4.1第一步release:prepare

這條命令主要是做打包前的準備。

  1. 輸入對應的release需要打包的版本等資訊，如果不輸入有預設的內容
  2. 將需要記錄和準備的內容快取到pom.xml目錄下的release.properties檔案中
  3. 在本地和遠端庫的GIT中打上對應版本的tag

在準備過程中還會run 單元測試等phase，如果沒有異常的話可以繼續最後一步。如果git還沒有commit或單元測試失敗會導致prepare失敗，這時候你就需要到下面一個命令了。

4.2後悔藥release:rollback

如果在準備階段發生錯誤，或者需要修改某些地方的話。就需要到這個命令了，這個命令執行以後會做以下這些事

  1. 刪除線上git庫tag，但是本地庫tag沒有被刪除，需要手動使用git tag -d XXX進行刪除。如果不將本地庫中的tag刪除將會導致prepare失敗。
  2. 刪除之前快取在pom.xml統一目錄下的配置

4.3最後一步release:perform

如果確認無誤了以後，就可以執行perform命令了。這個命令幹了以下這些事：

  1. 驗證程式碼合法性
  2. 將你之前的1.0-SNAPSHOT改為1.1-SNAPSHOT
  3. 將1.0版本deploy至scm配置的nexus release庫中
  4. 將程式碼source。jar版本 javacode。jar打包上傳至nexus庫

恭喜，你已經把你的1.0-SNAPSHOT成功的打包成1.0的release版本了。同時你會發現你的pom.xml檔案會自動的變成1.1-SNAPSHOT版本。雖然這一系列操作都可以通過手動完成。但是有這個工具的存在，免去了很多步驟。也規範了流程，何樂而不為呢。

相關文章