持续集成构建 - 版本控制

Question

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

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

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

这样做的好处是我们总是使用每个依赖项最新的版本，但主要缺点是我们的构建不可重复，因为您不知道在过去某个时间点应该使用哪些依赖项（例如版本说RELEASE而不是1.3.2）。

如果我们切换到使用固定的发布版本号，我们可以获得可重复的构建，但是我们会失去持续集成告诉我们现在已经出了什么问题的优势吗？这不是持续集成的目的吗？

那么，标准的做法是什么呢？

问候， D

- DD.

Answer 1

首先，计划停止使用RELEASE。在Maven 3的插件版本中已经不再支持；从Maven在线书籍中删除了对它的引用，我希望它在依赖版本方面也会被弃用（如果还没有的话），如果您对此不确定，请查看用户邮件列表以确认。您已经从困难的方式中学到了构建可重复性的重要性。

第二，我同意答案中的观点，通常情况下您会想要为项目的依赖项定义固定版本，除非您正在同时更改多个项目，这种情况下您需要一个 SNAPSHOT 依赖版本。但这只应该是在它们准备好发布之前。此时，您应该发布最低级别的那个，将其他项目中的依赖规范器切换到新的固定版本，并重复每个项目，直到完成。如果所有依赖关系都是固定版本，则只应发布项目的新版本。发布插件 可以帮助实现此目的。

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

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

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

- Zac Thompson

---

希望不用说，对于“万物之尖”的构建，您实际上并不关心可重现性，因为它实际上并不代表任何当前的项目配置。它只是一个早期警告系统。 - Zac Thompson

+1 提到版本插件可以更轻松地更新POM文件。 - Noremac

Answer 2

您的问题有几种可行的解决方案，其中最常见的是：

1）如果所有项目都必须构建并形成依赖树，则可以将它们合并为一个一致的模块集。这使用maven。

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

格式简洁，特别适用于需要将项目进行版本控制的分组项目。只需编写一个脚本，更新所有子pom.xml文件的版本号至正确修订版（或者使用我不太偏爱的maven-release-plugin），这样，项目的每个部分都会整体移动和进行版本控制；然后，您可以开始添加真正的修订号（例如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的项目构建。当您有一个共同、不断更新的依赖项时，这可能非常方便。

- Gabe Mc

Answer 3

如果我们转而使用固定的版本号，我们可以获得可重复构建的好处，但是难道我们不会失去持续集成告诉我们哪些内容现在已经损坏的优势吗？这不是持续集成的关键吗？

不，我不同意。每个被引用的项目都应该有自己的CI构建，并且应该报告什么已经损坏了。

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

- Sean Patrick Floyd

---

即使当前版本的 b 做什么是“无关紧要”的，但这并不意味着了解它是否引入了破坏性更改是没有用处的。+1 - Zac Thompson

@Zac 是的，但这需要一个专门的构建，测试所有已连接项目的当前版本。 - Sean Patrick Floyd

同意，如果他有兴趣的话，那正是我提出的做法。我完全赞同你对每个项目的方法，尽管有时候像 OP 那样从“始终使用最新的一切”方法开始的团队可能不清楚项目边界。 - Zac Thompson