Question

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

主要开发发生在开发分支（即Subversion trunk ，但无关紧要）开发人员团队提交他们的更改。在构建和打包工件之后，Jenkins将它们部署到maven存储库和开发集成应用程序服务器。这是一个发展快照，基本上只是一个feature branch，包含一个共同分支上的所有开发功能：

<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 =＆gt; 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-SNAPSHOT

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

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

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

Answer 2

我认为就maven而言，只有两种类型就可以简单地完成这个过程

快照（永久开发）
可释放（可以部署到maven存储库或生产版本的版本号）

我会以不同的方式处理你的分支，如果你看一下迭代/ scrum开发模型，你的代码应该在迭代/ sprint结束时可释放/可发送

主要子版本主干是开发人员提交代码的地方
在sprint / iteration分支结束时，主干线称为释放分支（不应该有QA分支，任何要发布的代码都要进行质量测试）
错误修复应该在发布分支上发生，并定期合并回主干
这样您就可以继续为发布创建分支，并且任何错误修复都会提交到分支
在从主干线创建新分支之前始终确保它具有以前分支的所有合并

Answer 3

Maven的发布插件支持branching。它似乎通过假设创建分支以支持下一版本的代码来工作。

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

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

3 个答案: