爲Java項目設置暫存過程

我目前有大量項目由50多個開發人員使用Maven 2/3與Nexus和Jenkins一起開發，具有複雜的依賴關係結構。我們的開發速度非常快，而且更多的時候我們並不是使用SNAPSHOT依賴項來構建和部署發行版。大多數情況下，我們不能等待一個或另一個團隊在部署之前構建發行版本。由於這個原因，我們已經有了一些有關錯誤和在製品進入生產的問題，並且不知道這些SNAPSHOTS有哪些變化。爲Java項目設置暫存過程

我期望做的是消除SNAPSHOTS，並使用versions-maven-plugin移動到自動發佈版本，並實施版本分段策略。

而這裏就存在這個問題。對於開發人員和CI構建人員，需要對其進行配置，以解決「分段」和「發佈」中的依賴關係，並僅將其發佈到「分段」。然後，我們希望能夠「推動」構建爲發佈版本，重新構建它以解決來自「發佈」的依賴關係併發布到「發佈」（最初，這將是手動升級，但我們可能希望將其自動化）。這一切聽起來合理嗎？

我不想使用maven-release-plugin，因爲我們之前曾嘗試過使用這個插件，而且我們不喜歡它自動修改pom並在我們的scm中進行更改並觸發更多構建的事實。

此外，是否有一種方法可以告訴maven使用一個存儲庫進行解析，另一個發佈到？我可以用gradle來做這個嗎？

任何意見/想法，將不勝感激。

來源

2012-09-19 liam.j.bennett

我建議不要使用maven release插件，不要使用快照。看看here以快速和乾淨的方式發佈。

來源

2012-09-24 21:09:42 Cengiz

看看maven-version-plugin，特別是鎖定/解鎖快照目標。他們可以幫助確定程序集正在使用哪些依賴關係，對您而言可能已足夠。

如果沒有，是的 - maven可以使用staging repositories，但如果您想要登臺的任何內容也被拉到本地開發人員存儲庫，可能會導致混淆。

我們現在用來解決類似問題的是一個'腳本'有點等同於maven-release-plugin（它實際上稱它爲某些操作），以及一個尷尬的版本控制方案：我們的開發分支保持1.2 -SNAPSHOT，但我們發佈/發佈的版本使用不同的版本控制方案（1.2.3,1.2.4）。我們的腳本標籤也是git。

來源

2012-09-19 17:46:37 ptyx

感謝您指向我的分段插件，我沒有看到。我們已經在考慮使用版本：use-latest-releases用於我們的依賴關係。 –

聽起來很像我的構建系統。

我使用gradle和2個獨立的nexus存儲庫（包括「release」存儲庫，1個分段和1個final）執行此操作。該版本具有目標成熟度的概念，並使用它來計算版本號（使用語義版本控制），因此RC版本生成1.0.0-rc1版本，最終版本生成版本1.0.0。然後我們用不同的方式標記測試（testng組，黃瓜標籤等），以便測試的不同片段在不同的時間運行。構建根據目標成熟度決定要依賴或發佈哪些存儲庫，並因此可以確保僅消耗足夠成熟的人工製品。

這被配置爲經由TeamCity的構建鏈自動運行所以在一些核心LIB漣漪提交通過下游（通過一組gradle這個任務通過其的Java API通過rundeck）構建和集成測試/部署如果必要的話。

Gradle發佈和解決方案存儲庫是分開配置的，因此可以不同。 maven也可以做同樣的事情。

例如，給定的依賴圖像

corelib的 - > MYLIB - >的myapp

每個事物都將有一組與它們相關聯的測試，被標記爲任一β或RC。其意圖是產生RC的構建是通過了beta測試的構建（即，如果你通過測試，那麼你已經足夠成熟到可以成爲RC）構建是一個快速完成的構建（例如，僅執行單元測試）而rc測試（產生最終構建）可能會進行一些集成測試或一些更長時間的運行測試。這個定義是我們自己的，完全是任意的，你可以做出任何你喜歡的區別。只有當您對產品具有一定的置信度時，我們纔會基於應用越來越嚴格和/或持久的測試。

然後，我們建立一個構建鏈，使得鋼筋混凝土基礎依賴於上游的鋼筋混凝土基礎，並最終建立依賴於上游的最終版本和你自己的RC版本

即

   --> mylib final -- 
     /     \ 
mylib rc --      --> myapp final 
      \     /
      --> myapp rc -----

等。在這個例子中，流量是

提交修改MYLIB
MYLIB RC版本運行
- 運行Beta測試
- 發佈結果的rc庫
MYLIB最終和MYAPP RC可以並行運行
mylib最終生成運行
- 運行RC測試
- 公佈結果，以最終處置庫
MYAPP RC版本運行
- 取決於RC資源庫，拿起以前MYLIB的結果RC版本
- 運行Beta測試
myapp最終運行
- 取決於最終存儲庫，所以選擇s上行以前MYLIB最終版本的結果
- 運行RC測試

版本號在每個點由查詢源控制

依賴，對我們自己的文物計算，是動態的（1.0。 +以常青藤術語爲例），major.minor是靜態設置的（在源代碼控制中），並且構建留下來產生補丁和候選數字本身，即myapp 1.0將取決於mylib 1.0。+。 IMO有兩個獨立的存儲庫作爲過濾機制要簡單得多，而不必深入gradle/ivy的解析邏輯來過濾掉我們不想要的那些。

來源

2012-09-19 18:04:05 Matt

*版本根據目標成熟度決定要依賴或發佈哪些存儲庫。* 這是我們的關鍵部分。你能提供一個如何存檔這個例子嗎？你如何定義目標成熟度？ –

增加了一個例子來嘗試和解釋 – Matt

這太棒了。我還研究瞭如何使用正確的和配置文件激活的組合來實現maven中的資源庫切換。 –

爲Java項目設置暫存過程

回答

相關問題