持续集成构建 - 版本控制

Question

我有一个关于版本号、RELEASE 版本和持续集成的使用的问题。

到目前为止，在我们的构建中，我们一直使用 RELEASE 作为每个构建中所有组件的版本。

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

这样做的优点是我们始终使用每个依赖项的最新版本，但主要缺点是我们的构建不可重现，因为您不知道过去某个时刻应该使用哪些依赖项（如例如，版本显示 RELEASE 而不是 1.3.2）。

如果我们改用固定的版本号，我们会得到可重复的构建，但我们是否会失去持续集成的优势，告诉我们现在出了什么问题？这不就是持续集成的意义吗？

这样做的标准方法是什么？

问候， D

Answer 1

首先，计划停止使用RELEASE。 Maven 中不再支持 3 为插件版本；似乎对它的引用已从有关 Maven 的在线书籍中删除，并且我希望它最终会在依赖版本中被弃用（如果还没有的话）（我无法以某种方式找到权威信息）。如果您对此不确定，请查看/询问用户邮件列表以进行确认。您已经通过艰难的方式了解了构建可重复性。

其次，我同意以下答案：您通常希望为项目的依赖项定义固定版本，除非您一次对多个项目进行更改，在这种情况下您需要 SNAPSHOT 依赖项版本。但这只能在他们准备好被释放之前进行。此时，您应该发布最低级别的版本，将其他项目中的依赖项说明符切换到新的固定版本，并对每个项目重复此操作直至完成。仅当所有依赖项都是固定版本时，您才应该发布项目的新版本。 发布插件可以帮助解决这个问题。

第三，了解多个项目的当前“提示”是否可以协同工作仍然非常有用或有趣，即使它们按照独立的发布计划进行！向后/向前兼容性规划，对吧？随着项目的增多，这一点变得更加重要。我认为这就是您所说的“持续集成”（尽管现在 CI 通常指的是在单个分支上工作的多个开发人员不断构建和测试更改）。

在这种情况下，您应该创建一个顶级聚合器项目，将所有相关项目定义为模块。您可以在工作区中执行此操作，而无需提交对版本控制的更改，也可以为跟踪主线更改的每个项目创建特定于集成的分支。无论哪种情况，您都需要使用版本： use-latest-versions 目标自动更新 POM，或使用 版本范围 让 Maven 选择与您当前使用“RELEASE”类似的方式（尽管我更喜欢让版本尽可能明确）。

（严格来说，您不需要顶级聚合器，但否则您必须独立地对每个项目执行此操作，而实际上您对它们如何协同工作感兴趣。）

Answer 2

如果我们改用固定版本
数字，我们得到可重复的构建，
但我们不会失去优势
持续集成告诉我们什么
现在已经坏了？这不是重点吗
持续集成？

不，我不同意。每个引用的项目都应该有自己的 CI 构建，并且应该报告损坏的内容。

如果您的 CI 项目是项目 a 并且依赖于项目 b，则构建 a 应该测试项目 a 的有效性，而不是 b。因此，Build a 唯一有趣的是 Project a 与 Project b 的指定版本一起工作。 （项目 b 的最新版本所做的事情无关紧要）

Answer 3

对于您的问题，有几种可以想到的解决方案，其中最常见的是：

1）您可以将多个项目组合在一起，如果它们都必须构建并形成依赖关系树，则将它们组合成一个连贯的模块集。这使用了 Maven

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

格式，这种格式很简洁，并且在将所有应该一起进行版本控制的项目分组为一组时很有帮助。然后，您只需要一个脚本，在每次发布时将所有子 pom.xml 文件的版本号更新为正确的修订版（或者，我不太喜欢的选项，使用 maven-release-plugin）。这样，项目的每个部分都会作为一个整体移动并一起进行版本控制；然后您可以开始添加真正的修订号（即 1.3.2）。

2) 如果您无法将常见的子项目整理成具有模块的连贯解决方案，那么下一个最佳选择是使用快照。通过将依赖项项目中的版本设置为以下内容：

<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 dependency-A 进行重建时，Hudson 都可以自动启动依赖于 dependency-A 的任何项目的构建。当您有一个共同的、不断更新的依赖项时，这会非常方便。