版本化不同分支的Maven最佳实践[开发,qa /预发布]

Question

我有几个项目是在不同的分支上开发和发布的,即开发和发布.这个过程运行得很顺利,但不幸的是它有一些缺点,我一直在想是否有更好的版本控制方案适用于我的情况.

主要开发发生在一个开发分支(即Subversion 主干,但并不重要)开发人员团队提交他们的更改.在构建和打包工件之后,Jenkins将它们部署到maven存储库和开发集成应用程序服务器.这是一个开发快照,基本上只是一个功能分支,包含一个公共分支上的所有开发功能:

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>D.16-SNAPSHOT</version>

当QA团队完成并请求某个特定业务更改时,此单个更改将合并到发布分支(分支/发布).Jenkins将生成的工件部署到QA应用程序服务器:

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>R.16-SNAPSHOT</version>

然后有一个版本通过发布分支版本的软件上的maven-release-plugin发生(它创建了一个维护标签/分支,用于快速修复bug).(R.16-SNAPSHOT => R.16)

开发和发布分支机构目前分别为D.16-SNAPSHOT和R.16-SNAPSHOT版本.这允许在maven存储库中分离工件,但是使用依赖于标准maven版本控制样式的不同maven机制产生问题.这也打破了OSGI版本.

现在,您如何在这样的方案中命名和编辑maven工件？有没有更好的办法？也许我可以对maven结构进行一些更改,而不仅仅是更改版本控制和命名方案？但我需要将开发和QA(发布)SCM分支分开.

"开发"/"生产"的maven分类器是否是一个合理的选择？

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>16-SNAPSHOT</version>
<classifier>D</classifier>

Answer 1

据我所知，发布工件的常见命名扩展只是工件的名称，没有任何内容，只有指定的版本。开发分支将具有相同的工件名称，但带有快照。

以 twitter4j 为例。发布版本的工件名称是

twitter4j-2.5.5

他们（他的）开发版本的快照

twitter4j-2.6.5-快照

这是几乎每个人都使用的命名约定，并且被大多数工具识别。例如，我的 Nexus 存储库可以指定忽略开发版本的策略，这基本上意味着它会忽略名称中包含 -SNAPSHOT 的工件。

编辑：对于您的后续问题：

那么，根据您的构建工具，您可以创建具有时间戳或其他唯一标识符的快照。但是，我从未听说过将某些分支逻辑嵌入到工件的名称中，以便连续 int 服务器可以区分它。从工件的角度来看，它要么是一个版本，要么是一个快照，我没有看到将更多逻辑嵌入到工件名称中的好处，只是因为你的 Hudson 允许你这样做。老实说，你的发布周期对我来说似乎不错，但它需要对你的 Maven 工具进行一些微调。如果您不能忍受这一点，我建议您使用分类器而不是依赖名称，因为调整集成服务器总是比许多依赖标准命名约定的插件更容易。总之，我相信您走在正确的道路上。