Maven 版本控制的最佳实践，适用于不同分支（开发、QA/预发布）。

Question

Maven 版本控制的最佳实践，适用于不同分支（开发、QA/预发布）。

version-controlmavennaming-conventionsbranch

27

我有几个项目在不同的分支上进行开发和发布，分别是development和release。这个过程运作得相当不错，但不幸的是它有一些缺点，我一直在想是否有更好的版本控制方案适用于我的情况。

主要的开发是在一个开发分支上进行的（即Subversion的trunk，但这并不重要），团队成员提交他们的更改。构建和打包工件后，Jenkins会将它们部署到Maven仓库和开发集成应用服务器上。这是一个DEVELOPMENT-SNAPSHOT，并且基本上只是一个包含所有开发功能的特性分支：

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

当QA团队完成一项业务更改并请求后，这个单独的更改会被合并到发布分支（branches/release）中。 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。这样可以将artifact在maven存储库中分离，但会在依赖于标准maven版本控制的不同maven机制中出现问题，并破坏OSGI版本控制。

现在，在这种方案中，您应该如何命名和为maven artifacts命名版本？有更好的方法吗？也许我可以对maven结构进行一些更改，而不仅仅是更改版本控制和命名方案？但我需要保持开发和QA（发布）SCM分支分开。

使用'maven classifier' 'development' / 'production'是否是合理的替代方案？

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

- Mike Minicki

看 https://dev59.com/OGgu5IYBdhLWcg3wUljt。最好的方式似乎是使用 16-R-SNAPSHOT 和 16-D-SNAPSHOT 这样的版本，而不要使用分类器。 - itsadok

3个回答

1

我认为在Maven中，你可以通过只有两种类型来简化这个过程

快照（永久开发中）
可发布的版本（带有可以部署到Maven仓库或生产发布的版本号）

如果你看一下迭代/Scrum开发模型，我会稍微处理一下你的分支。你的代码应该在迭代/冲刺结束时是可发布的/可交付的。

主子版本主干是开发人员提交他们的代码的地方。
在冲刺/迭代结束时，将主干分支并称之为发布分支（不应该有QA分支，任何要发布的代码都应该经过质量测试）。
错误修复应该在发布分支上发生，并定期合并回主干。
这样，你就可以不断创建分支以进行发布，并将任何错误修复提交到分支上。
在从主干创建新分支之前，始终确保它具有来自先前分支的所有合并。

- Prasanna Talakanti

0

Maven的发布插件支持分支。它似乎是通过假设该分支被创建来支持您代码的下一个版本而工作的。

个人而言，我更倾向于使用versions插件，并明确设置我的Maven项目的版本号。

- Mark O'Connor

1

我同时使用Mark（在错误修复版本中通过版本插件进行版本升级）。但是我担心您没有注意到我的问题细节。无论如何，谢谢。 - Mike Minicki

好的，我会更明确一些...请查看发布插件文档，了解它如何支持分支。我的建议是停止试图通过创建相同版本的并行副本（“D”，“R”等）来对抗Maven。相反，创建一个将成为您下一个版本的分支。例如，版本1.0的分支将被称为1.1-SNAPSHOT。 - Mark O'Connor

2

马克，我确实有一个名为“branches/release”的分支，它有“1.1-SNAPSHOT”的版本。这个分支将被发布为1.1版。但我也有一个名为feature/development的开发分支，必须以某种方式标记，因为其他软件可能需要依赖于尚未计划在最近的发布中的开发版本。我不能放弃dev和qa分支，正如我在评论中向普拉萨纳解释的那样。此外，我并不是要与Maven斗争，这种设置已经足够好了（你知道，Maven支持字符串版本，这是有文档说明的）。我只是在寻找更好的处理这种情况的方法。 - Mike Minicki

2

明白了，我感同身受 :-) 我不建议使用分类器。虽然它可以用于多种目的，但其目标是区分附加到Maven模块的其他文件（例如源代码或javadoc档案）。我的离别之言是，你真正需要的是在Apache ivy存储库中称为模块“状态”的概念。不幸的是，这个概念不受Maven存储库支持... - Mark O'Connor

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Nikola Yovchev · Accepted Answer

据我所知，一个发布构件的常见命名扩展只是构件的名称，不包含任何附加内容，只指定版本号。开发分支将具有相同的构件名称，但会添加“snapshot”。

例如，以twitter4j为例。发布版本的构件名称为：

twitter4j-2.5.5

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

twitter4j-2.6.5-SNAPSHOT

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

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

好吧，根据你的构建工具，你可以创建时间戳或某些其他唯一标识符的快照。然而，我从未听说过将分支逻辑嵌入到构件名称中，仅仅是为了让持续集成服务器能够区分它。从构件的角度来看，它要么是发布版，要么是快照版，我不认为将更多的逻辑嵌入到构件名称中有什么好处，只是因为你的Hudson允许你这样做。老实说，你的发布周期对我来说还可以，但需要微调你的maven工具。如果你无法接受这一点，我建议你使用分类器，而不是依赖于名称，因为调整集成服务器总比依赖于标准命名约定的许多插件更容易。总之，我认为你正在正确的轨道上。