Maven 不同分支版本控制的最佳实践 [开发、质量保证/预发布]
我有几个在不同分支上开发和发布的项目，即开发和发布。这个过程运行得很好，但不幸的是它有一些缺点，我一直想知道是否有更好的版本控制方案适用于我的情况。
主要开发发生在开发分支（即 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 进行发布（它创建一个维护标签/分支以快速修复错误）。 (R.16-SNAPSHOT => R.16)
开发和发布分支当前版本分别为 D.16-SNAPSHOT 和 R.16-SNAPSHOT。这允许在 Maven 存储库中分离工件，但会产生依赖于标准 Maven 版本控制风格的不同 Maven 机制的问题。这也破坏了 OSGI 版本控制。
现在，您将如何在这样的方案中命名和版本 Maven 工件？有更好的办法吗？除了简单地更改版本控制和命名方案之外，也许我可以对 Maven 结构进行一些更改？但我需要将开发和 QA（发布）SCM 分支分开。
“开发”/“生产”的专家分类器是一个合理的选择吗？
<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>16-SNAPSHOT</version>
<classifier>D</classifier>
I have a couple of projects which are developed and released on different branches, namely development and release. The process works pretty well but unfortunately it has some drawbacks and I have been wondering if there is a better versioning scheme to apply in my situation.
The main development happens on a development branch (i.e. Subversion trunk but it doesn't matter much) where team of developers commit their changes. After building and packaging artifacts, Jenkins deploys them to maven repository and development integration application server. This is a DEVELOPMENT-SNAPSHOT and basically is just a feature branch containing all developed features on one common branch:
<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>D.16-SNAPSHOT</version>
When one particular business change is done and requested by QA team, this single change is then being merged to the release branch (branches/release). Jenkins deploys the resulting artifact to QA application server:
<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>R.16-SNAPSHOT</version>
Then there's a release which happens via maven-release-plugin on the release branch version of software (which creates a maintenance tag/branch for quick bug fixing). (R.16-SNAPSHOT => R.16)
Development and release branches are currently being versioned as D.16-SNAPSHOT and R.16-SNAPSHOT respectively. This allows to separate artifacts in maven repository but creates a problem with different maven mechanisms which rely on standard maven versioning style. And this breaks OSGI versioning as well.
Now, how would you name and version maven artifacts in such a scheme? Is there a better way? Maybe I could make some changes to maven structures other than simply changing the versioning and naming schemes? But I need to keep development and QA (release) SCM branches separate.
Would a maven classifier of 'development'/'production' be a reasonable alternative?
<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>16-SNAPSHOT</version>
<classifier>D</classifier>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我所知，发布工件的常见命名扩展只是工件的名称，没有任何内容，只有指定的版本。开发分支将具有相同的工件名称，但带有快照。
以 twitter4j 为例。发布版本的工件名称是
他们（他的）开发版本的快照
这是几乎每个人都使用并被大多数工具识别的命名约定。例如，我的 Nexus 存储库可以指定忽略开发版本的策略，这基本上意味着它会忽略名称中包含 -SNAPSHOT 的工件。
编辑：
对于您的后续问题：
嗯，根据您的构建工具，您可以创建具有时间戳或其他唯一标识符的快照。但是，我从未听说过将某些分支逻辑嵌入到工件的名称中，以便连续 int 服务器可以区分它。从工件的角度来看，它要么是一个版本，要么是一个快照，我没有看到将更多逻辑嵌入到工件名称中的好处，只是因为你的 Hudson 允许你这样做。老实说，你的发布周期对我来说似乎不错，但它需要对你的 Maven 工具进行一些微调。如果您不能忍受这一点，我建议您使用分类器而不是依赖名称，因为调整集成服务器总是比许多依赖标准命名约定的插件更容易。总之，我相信您走在正确的道路上。
As far as I know, a common naming extension for a release artifact would be just the name of the artifact, without any stuff, only the version specified. A development branch would have the same artifact name but with snapshot.
For example, take twitter4j. The artifact name of the release version is
Snapshot of their(his) development version
That is the naming convention almost everybody uses and is recognized by most tools. For example, my Nexus repository can specify a policy to ignore development releases which basically means it ignores the artifacts containing -SNAPSHOT in their name.
EDIT:
To your followup question:
Well, depending on your build tool, you can create your snapshots to have the timestamp or some other unique identifier. However, I have never heard of some branching logic being embedded in the artifact's name just so the continuous int server can distinguish it. From the artifact's perspective, it is either a release, or a SNAPSHOT, I don't see the benefit of embedding more logic into the name of the artifact just cause your Hudson allows yo to do so. To be honest, your release cycle seems OK to me, but it would require some fine tweaking of your maven tools. If you can't live with that I would suggest you to use a classifier instead of relying on the name as it is always easier to tweak the integration server than a lot of plugins that rely on standard naming convention. In conclusion, I believe you are on the right track.
我认为就maven而言，您可以通过只有两种类型来简单地处理
我会以稍微不同的方式处理您的分支，如果您查看迭代/Scrum 开发模型，您的代码应该在迭代/冲刺结束时可发布/可交付
I think you could simply the process by having only two types as far as maven is concerned
I would handle your branching a little differently, If you look at the iterative/scrum development model your code should be releasable/shippable at end of a iteration/sprint
Maven 的发布插件支持分支。它似乎是通过假设创建分支来支持下一版本的代码来工作的。
就我个人而言，我更倾向于使用 versions 插件，并显式设置我的 Maven 项目的版本号。
The release plugin from Maven supports branching. It appears to work by assuming that the branch is created to support the next version of your code.
Personally, I'm more inclined to use the versions plug-in, and explicitly set my Maven project's version numbers.