持續集成構建 - 版本

我對使用版本號，RELEASE版本和持續集成有疑問。持續集成構建 - 版本

到目前爲止，在我們的構建中，我們一直使用RELEASE作爲每個構建中所有組件的版本。

<dependency> 
    <groupId>com.mycompany</groupId> 
    <artifactId>mydependency</artifactId> 
    <version>RELEASE</version> 
</dependency>

這樣做的好處在於，我們總是使用最先進的每個依賴的最新版本，但有重大缺陷，我們的版本是不可再生的，你不知道被認爲是什麼依賴性在使用指向過去（因爲版本說RELEASE不是1.3.2例如）。

如果我們轉向使用固定版本號，我們會獲得可複製的版本，但是我們是否失去了持續集成的優勢，告訴我們現在破碎了什麼？這不是持續集成的重點嗎？

這樣做的標準方法是什麼？

問候， d

來源

2011-01-19 DD.

首先，計劃停止使用RELEASE。在Maven 3中插件版本爲no longer supported;它似乎已經從關於Maven的在線書籍中刪除了對它的引用，並且如果它不是已經存在的（我無法以某種方式找到權威信息），我預計它最終會被依賴版本所棄用。如果您對此不確定，請查看/詢問用戶郵件列表以確認。您已經瞭解了構建重現性的難題。

第二，我同意答案，您一般會想要爲項目的依賴項定義固定版本，除非您一次對多個項目進行更改，在這種情況下您需要SNAPSHOT依賴項版本。但是，這應該是直到他們準備好發佈。此時，您應該釋放最低級別，將依賴項說明符切換到其他項目中的新固定版本，並對每個項目重複，直到完成。如果所有依賴項都是固定版本，則只應發佈新版本的項目。 release plugin可以幫助解決這個問題。第三，即使它們處於獨立發佈時間表，多個項目的當前「提示」是否可以一起工作仍然非常有用或有意義！向後/向前兼容性規劃，對嗎？隨着更多的項目，這變得更加重要。我認爲這是您所談論的「持續集成」（儘管這些日子CI通常指的是不斷構建和測試多個開發人員在單個分支上工作的變化）。

在這種情況下，您應該創建一個頂級聚合器項目，將所有相關項目定義爲模塊。您可以在工作區執行此操作，而無需更改版本控制，也可以爲每個跟蹤主線更改的項目創建一個特定於集成的分支。無論哪種情況，你都會想要使用versions：use-latest-versions的目標來自動化POM的更新，或者使用version ranges來讓maven選擇類似於你當前如何使用'RELEASE'的方式（雖然我更喜歡使用版本儘可能明確）。

（嚴格說來，你不需要頂級聚合，但除此之外，您有與每個項目單獨做到這一點，當你真正感興趣的是他們如何一起工作。）

來源

2011-01-20 08:47:56

如果我們切換到使用固定的發佈數字，我們得到重現的構建，但不輸球持續集成告訴我們的優勢是什麼現在已經壞了嗎？這不是持續集成的點嗎？

不，我不同意。每個引用的項目都應該有它自己的CI構建，並且應該報告破壞的內容。

如果您的CI項目是項目a並且對項目b有依賴關係，則構建a應該測試項目a的有效性，而不是b。因此，Build a的唯一有趣之處在於Project a與指定版本的Project b一起工作。（什麼項目B的最新版本則是無關緊要的）

來源

2011-01-19 09:26:36

甚至+1儘管：也許最新版本的b所做的是「不相關的」，但這並不意味着它不知道它是否引入了重大更改。 – 2011-01-20 08:56:54

@Zac是真實的，但是這需要一個專門的構建，以某種方式測試所有項目的當前版本。 – 2011-01-20 08:58:45

有你的問題，有幾個可能的解決方案，其中最常見的是：

1）你可以幾個項目結合在一起，如果他們都必須無論如何建立和形成一個依賴樹，成爲一個連貫的模塊集。它使用maven的

<modules> 
    <module>submodule-A</module> 
    <module>submodule-B</module> 
</modules>

格式，它是簡潔，和分組都應該作爲一個組一起版本化項目時，它是有幫助的。然後你只需要一個腳本，當你發佈一個版本（或者，我不太喜歡的選項，使用maven-release-plugin）時，將所有子pom.xml文件的版本號更新爲正確的版本。這樣，項目的每個部分都會移動並作爲一個整體進行版本管理;然後您可以開始添加實際修訂版本號（即1.3.2）。

2）如果您不能將常用子項目與模塊整合爲一個一致的解決方案，則下一個最佳選擇是使用SNAPSHOTS。通過將依賴項目中的版本設置爲如下形式：

<project> 
    ... 
    <artifactId>dependency-A</artifactId> 
    <groupId>com.company</groupId> 
    <version>1.3.2-SNAPSHOT</version> 
    ... 
</project>

您可以一次移動到不同的代碼庫中。您的主要項目具有快照上直接依賴關係可以跟蹤對存儲庫的變化：

<dependencies> 
    ... 
    <dependency> 
     <artifactId>dependency-A</artifactId> 
     <groupId>com.company</groupId> 
     <version>1.3.2-SNAPSHOT</version> 
    </dependency> 
    ... 
</dependencies>

，或者你可以依賴於舊版本的繼續（即使用1.3.1）目前的開發週期，然後在1.3.2版本發佈後更新依賴關係。

這個選項在跟蹤多個獨立項目時稍微複雜一點，但它確實保留了什麼取決於什麼版本的明確性，明確地在源代碼中。與版本控制模塊相比，這是不利的一面。另一方面，大多數CI系統（包括Hudson）在配置部分末尾都有一個複選框，用於詢問「構建相關項目？」的工作。（或類似的東西）。當作爲maven構建進行檢查和運行時，只要您的SNAPSHOT依賴關係-A執行重建，Hudson就可以自動啓動依賴於依賴關係-A的任何項目的構建。當你有一個共同的，不斷更新的依賴關係時，這可能非常方便。

來源

2011-01-20 07:30:46

持續集成構建 - 版本

回答

相關問題