version-control - 不同分支版本控制的 Maven 最佳实践 [开发、质量保证/预发布]

Question

我有几个项目在不同的分支上开发和发布，即开发和发布。该过程运行良好，但不幸的是它有一些缺点，我一直想知道是否有更好的版本控制方案可以应用于我的情况。

主要开发发生在开发分支(即 Subversion 主干，但无关紧要)上，开发团队在其中提交更改。在构建和打包 Artifact 之后，Jenkins 将它们部署到 maven 存储库和开发集成应用服务器。这是一个开发快照，基本上只是一个 feature branch在一个公共(public)分支上包含所有已开发的功能:

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

当 QA 团队完成一项特定的业务变更并提出请求时，该单一变更将被合并到发布分支(分支/发布)。 Jenkins 将生成的 Artifact 部署到 QA 应用程序服务器:

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

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

开发和发布分支目前分别被版本化为 D.16-SNAPSHOT 和 R.16-SNAPSHOT。这允许在 maven 存储库中分离 Artifact ，但会产生依赖于标准 maven 版本控制风格的不同 maven 机制的问题。这也破坏了 OSGI 版本控制。

现在，您将如何在这样的方案中命名和版本化 Maven Artifact ？有没有更好的办法？除了简单地更改版本控制和命名方案之外，也许我可以对 Maven 结构进行一些更改？但我需要将开发和 QA(发布)SCM 分支分开。

“开发”/“生产”的 Maven 分类器会是一个合理的选择吗？

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

Answer 1

据我所知，发布 Artifact 的通用命名扩展只是 Artifact 的名称，没有任何东西，只有指定的版本。开发分支将具有相同的 Artifact 名称但带有快照。

例如，以 twitter4j 为例。发布版本的 Artifact 名称是

twitter4j-2.5.5

他们(他的)开发版本的快照

twitter4j-2.6.5-SNAPSHOT

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

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

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