Maven最佳实践，用于对不同分支进行版本控制[开发，质量保证/预发布] [英] Maven best practices for versioning different branches [development, qa / pre-release]

问题描述

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

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.

主要开发发生在开发分支(即，Subversion trunk 无关紧要)上，开发团队在此进行更改.在构建和打包工件之后，Jenkins将它们部署到maven存储库和开发集成应用程序服务器.这是一个开发快照，基本上只是一个功能分支，其中包含一个公共分支上的所有已开发功能:

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>

当质量检查团队完成并要求进行一项特定的业务更改时，此单个更改将被合并到发布分支( branches/release ). Jenkins将结果工件部署到QA应用程序服务器:

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>

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

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)

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

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.

现在，您如何在这种方案中命名和版本Maven工件?有没有更好的办法?也许除了简单地更改版本和命名方案之外，我还可以对Maven结构进行一些更改?但是我需要将开发和QA(发布)SCM分支保持分开.

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>

推荐答案

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

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.

例如，使用twitter4j.发行版本的工件名称为

For example, take twitter4j. The artifact name of the release version is

twitter4j-2.5.5

twitter4j-2.5.5

其开发版本的快照

twitter4j-2.6.5-快照

twitter4j-2.6.5-SNAPSHOT

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

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.

对于您的后续问题:

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

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最佳实践，用于对不同分支进行版本控制[开发，质量保证/预发布]的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！