自动化发布工作流：Maven分支更新项目版本

Question

我有一个关于Maven自动化项目版本控制的棘手问题需要解决，希望能基于您的经验和建议找到合适的解决方案。

问题如下： 我们有一个巨大的Maven Java产品，由约200个高度相互依赖的不同项目组成。 我们都同意每个项目应该独立开发，因此每个项目都应该有自己的生命周期。 在开发阶段一切都很好，没有问题。问题出现在我们为这些项目准备发布时：因为项目数量太多，手动更改非常麻烦，因此我们决定寻找自动化解决方案来解决发布流程。

前提条件如下： 我们都同意从SVN的角度来看，发布策略应该是这样的： - 所有开发都应该在SVN主干上进行，发布应该在分支上创建和维护。每次发布都应该自动创建一个标签。

从MAVEN的角度来看，策略如下： - 在发布项目之前，我们首先将主干复制到一个分支中，以便对分支代码上的项目进行维护控制。我们选择的版本控制系统是：Major.Minor.BuildNumber-SNAPSHOT（例如1.0.0-SNAPSHOT）。当分支代码时，我们希望通过增加MinorVersion（例如trunk-1.0.0-SNAPSHOT将变为1.1.0-SNAPSHOT，而1.0.0-SNAPSHOT将被复制并发布到新创建的分支上） - 当我们决定项目已经足够成熟以进行发布时，我们使用maven-release-plugin (mvn release:clean release:prepare release:perform) 进行发布，这样我们的项目版本将从Major.Minor.BuildVersion-SNAPSHOT（例如1.0.0-SNAPSHOT）转换为Major.Minor.BuildVersion（例如1.0.0），然后准备进行下一轮开发迭代，如：Major.Minor.BuildVersion+1-SNAPSHOT（例如1.0.1-SNAPSHOT）

我们面临的问题与项目版本控制有关。 因此，在主干的开发阶段，所有项目都使用其依赖项的最新SNAPSHOT版本（mvn versions:use-latest-versions -DallowSnapshots=true -DupdateDependencies=true），但当我们认为是时候开始发布流程并准备分支代码时，问题就开始了： 我们开始分支。

1. parent-pom

   (mvn -B release:clean release:branch -DbranchName=${project.artifactId}_${project.version} -Dusername=${username} -Dpassword=${passwd} -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT)

   • 将项目从主干复制到新创建的分支，将主干上的pom版本从1.0.0-SNAPSHOT更改为1.1.0-SNAPSHOT。

2. 非依赖项目

   (mvn -B release:clean release:branch -DbranchName=${project.artifactId}_${project.version} -Dusername=${username} -Dpassword=${passwd} -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT versions:update-parent -DallowSnapshots=true)

   • 将项目从主干复制到新创建的分支。
   • 将主干上的pom版本1.0.0-SNAPSHOT变为1.0.1-SNAPSHOT。
   • 更新parent-pom.version：将1.0.0-SNAPSHOT变为1.1.0-SNAPSHOT。

3. 依赖项目：

   (mvn -B release:clean release:branch -DbranchName=${project.artifactId}_${project.version} -Dusername=${username} -Dpassword=${passwd} -Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT versions:update-parent -DallowSnapshots=true versions:use-latest-versions -DallowSnapshots=true -DupdateDependencies=true)

   • 将项目从主干复制到新创建的分支。
   • 将主干上的pom版本从1.0.0-SNAPSHOT更改为1.1.0-SNAPSHOT。
   • 将主干上的parent-pom从1.0.0-SNAPSHOT更改为1.1.0-SNAPSHOT。
   • 将已经分支的依赖项目从1.0.0-SNAPSHOT更新为1.1.0-SNAPSHOT。

这里的第一个问题是，还没有一种方法可以通过参数来增加MinorVersion以便在分支项目时进行自动化。当分支时，maven-release-plugin 2.2.2不会递增主干上的pom MinorVersion，因此我们需要手动使用-Dproject.rel.${groupId}:${projectId}=1.0.0-SNAPSHOT -Dproject.dev.${groupId}:${projectId}=1.1.0-SNAPSHOT参数并针对每个项目进行更改，因此每次准备发布新版本时需要重复200次。

我想知道是否有一种自动化地完成所有已描述过程的方法，而且不需要一直手动进行这些更改。我们考虑将此产品模块化，以便将200个项目合并为100个，但由于想要细粒度项目版本控制，并使所有项目具有其自己的生命周期，因此聚合器（我指的是经典聚合器）在这里不适用。

我们使用SVN作为VCS，使用Maven作为构建工具（您可能已经猜到了: )），以及Bamboo作为CI服务器（实际上，除了“Maven Dependency Processor”功能外，Bamboo在版本控制问题方面没有太多帮助）。

您们是否有任何想法，以便为这个问题找到一个合适的解决方案，也许是另一个可以帮助的插件（versions-maven-plugin在分支时不会自动更改版本），或者对此事的另一个看法，我不知道...，欢迎任何帮助或建议。

谢谢！

- Asgard

---

为什么要使用插件来滚动版本？为什么不在根POM的单个属性和dependencyManagement部分中维护您的版本，并在每个分支的一个位置“手动”更改版本？ - ianpojman

Answer 1

我尽量避免将内部项目版本保存在父POM的<properties>部分中，因为每次发布项目时，<version>${project.version}</version>变量都会被替换为项目的显式版本，例如：

<properties>
        <project_A.version>1.0.0-SNAPSHOT</projectA.version>
</properties>

存储在父POM中，像这样在项目的POM中翻译：${project.version}，当发布该项目时将变为1.0.1-SNAPSHOT，并将覆盖来自父POM <properties> 的<project_A.version>版本。因此，在像父POM这样的集中位置中将项目版本保留为属性的技巧只有在不发布项目的情况下才有效。

这与分支问题严密相关。

---

---

现在，如果你想的话，我可以告诉你更多关于使用<properties>替换来发布项目的信息： 假设你想要发布你的project_A，当你开始发布父pom时，存储在<properties>中的<projectA.version>是一个-SNAPSHOT版本，那么你会怎么做呢？我的意思是，为了发布一个项目，你必须先发布它所有的依赖项和相关的父POM，否则你的项目发布将会失败，因为它指向了一个父POM的-SNAPSHOT版本。 现在，你正在发布保留着project_A的-SNAPSHOT版本的父POM，接下来，当你发布project_A时，你的项目将引用新创建的父POM发布版本，而该父POM发布版本又引用了你project_A的1.0.0-SNAPSHOT版本，这还不是一个问题，因为你的父POM保留了真实的project_A版本，直到你的project_A发布版本（比如1.0.0）将引用包含1.0.0-SNAPSHOT版本project_A的相同父POM发布版本，此时，你已经有了一个问题，因为你的父POM<properties>中保留了错误的信息。 当然，在发布父POM时，你可以“黑”一下它并存储project_A的发布版本，但这是违反规则的，我不同意这种做法，而且还有其他情况下，这种“黑客”行为会带来更多问题而不是帮助。

如果这听起来相当复杂和详细，我很抱歉，但我只是想尽可能地解释现实情况，而不仅仅是理论上的，另外我还需要记住我有200多个项目需要保持一致。

- Asgard