11

我正在設置Hudson以使用批量任務插件向我們的內部存儲庫執行maven發佈。通過Hudson發佈Maven

mvn --batch-mode release:prepare 
mvn --batch-mode release:perform 

我感興趣的人使用其他方法和這些方法的利弊:我通過這樣做。此外,任何人都遇到過的陷阱。

回答

8

我傾向於手工幾個原因總是做發佈。首先,如果您必須回滾,則可以在返回到原始發佈位置時執行此操作。其次,因爲您需要解決所有快照依賴性作爲過程的一部分。

我們的開發流程讓我們在當前版本的以前發佈版本之外留下依賴關係,直到修復需要升級。這意味着,如果我發佈Nexus,Maven等,那麼我會看到快照,這意味着我必須先發布並釋放這些快照。這個過程實際上不可能自動化,因爲它會根據自上次發佈以來發生的更改而變化。

這就是說,我們有一個特殊的機器(在Sonatype它只是一個虛擬機)設置只爲構建。這樣做是爲了確保不會發生可能會影響構建意外的環境變化(如jdk更改)。這也使得任何人都可以輕鬆掌握髮布流程,因爲它隨時可以發佈。

+3

不幸的是,我認爲手動發佈是一個技術上可以接受但在政治上不可接受的解決方案。我會提到,Sonatype的一位資深人士建議我們手動發佈。 – sal 2009-04-27 14:40:47

+5

另一種方法是您執行發佈操作:手動準備目標,或者至少發佈:準備-Ddryrun = true,直到您確信所有條件都已完成,然後才能啓動構建過程併合理確定它會起作用。 – 2009-04-28 11:55:46

0

我一直觸發具有明顯的優點和缺點手動釋放:-)

0

我們一直在試驗Hudson Maven發佈插件,儘管我有點想讓它能夠正確地評價版本,沒有像編碼密碼這樣的惡意代碼到我們的構建文件中。

2

最近,一個m2release插件引起了我的注意。看起來不錯。儘管如此,我希望我的發佈過程完全可以「無需任何調整」。我的意思是,我們必須提供4個輸入參數來處理一個完整的版本:(前1.0.0)

  1. 發行版本
  2. 新的開發版本(如1.0.1-。快照)在SCM
  3. 釋放標籤(例如:釋放-1.0.0或1.0.0)
  4. 標籤基本路徑在SCM

第一2具有可接受的默認值。碰到bug修復版本數字的版本對我來說完全沒問題。

可以在pom中指定數字4。它不會改變。

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-release-plugin</artifactId> 
    <configuration> 
     <tagBase>https://example.com/svn/myProject/releases</tagBase> 
    </configuration> 
</plugin> 

這是第三個阻止我在按下按鈕時完全自動化發佈的版本。默認版本標記標籤不會爲我們做,所以我們必須指定它:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-release-plugin</artifactId> 
    <configuration> 
     <tag>release-${pom.version}</tag> 
     <tagBase>https://example.com/svn/myProject/releases</tagBase> 
    </configuration> 
</plugin> 

現在,雖然這可能是我需要的,我最終不得不用在了-SNAPSHOT一個svn標籤結束。 :(所以我必須在Hudson作業配置中傳遞標籤參數。此外,我必須對每個版本進行更改......這不完全是我需要的。


那麼,到底,其在哈德森的Maven2類型的項目+的m2release哈德森插件+ Maven的插件版本正確配置是迄今爲止我見過的所有釋放過程的母親。雖然不完美,但它爲我節省了很多工作。

JS。