如何使用Maven连续构建和部署功能分支？

我的团队正在使用功能分支来实现新功能，并不断将快照构建部署到远程回购中供我们的用户使用。因此'部署'实际上只意味着'分发到远程Maven仓库'。我们目前只为master分支运行持续集成构建，而不是基于以下原因：我们使用Maven构建项目并将JavaDoc和源代码与JAR一起分发。如何使用Maven连续构建和部署功能分支？

我的计划是现在的分类添加到每个功能分支建立并期待一个创建和部署像这样的文物时使用：

科：主
分类：无
工件：foo-${version}的.jar，foo-${version}-sources的.jar，foo-${version}-javadoc.jar
科：功能-X
分类：我的功能
文物：foo-${version}-feature.jar，foo-${version}-sources-feature.jar，foo-${version}-javadoc-feature.jar

我真的不关心的神器确切的命名，我只需要一个特性分支独立的主，来源及文物的JavaDoc 。事实证明，JavaDoc插件和源代码插件都不考虑配置的分类器，因此可以有效地覆盖为我的主版本创建的工件。

我真的不想改变artifactId，虽然这可能会解决问题。你如何处理特性分支并与Maven持续集成？

来源

2012-07-10 Oliver Gierke

topoc分支的静态程度如何？你期望多久设定一份新工作，多久他们会被淘汰？你在CI服务器中用什么来帮助你？这是阻止我思考这样一个构建的事情之一。也许网守模型或开发人员本地CI服务器更适合。 – eckes 2012-07-10 12:52:32

你不应该使用分类器来反映分支的差异，因为你会对其他插件产生不好的副作用。分类器应该是来源，javadocs等...... 为了您的需要，您应该更改artifactId或版本。 – Farid 2012-07-10 12:54:54

@eckes - 我们使用Bamboo，它支持根据分支名称上的正则表达式自动触发基于不同分支的构建作业。只要它检测到与该表达式匹配的分支，如果通常指示这样做，它几乎可以克隆构建作业。 – 2012-07-10 14:06:06

我会建议将branch-qualifier添加到版本组件中，因为它与该部分更相关。这也允许您在主分支旁边的这些版本的快照依赖关系。

来源

2012-07-10 12:51:13 eckes

虽然这看起来是一种很好的方法，但在使用版本号范围（f.e.用于持续集成）时会导致问题。看到我的答案。 – 2015-02-19 08:48:01

我会建议使用它代表了分支以及版本之类的适当的版本：

1.0.0快照对于主

和

1.0.0-F1-快照功能F1

等

这给予也是一个指标从1.0.0版本新特性分支已经取得进展。

来源

2012-07-10 13:20:38 khmarbaise

* 1.0.0 **相当于* 。。 - *。 * -SNAPSHOT *是Maven的一部分。此外还有什么问题吗？根本没有。 – khmarbaise 2013-04-30 17:08:29

如何指示mercurial或maven在合并回主人时不包含pom版本？我的意思是我不认为你想在每次合并时手动解决这个问题，对吧？ – Asgard 2014-03-08 22:11:14

我们有一个功能分支设置脚本，只创建对版本号进行更改的第一次提交。在合并时，我们简单地放下这个提交并压缩并合并这个分支上的所有后续的（或者如果只有第二次提交，就简单地选樱桃）。 – 2014-05-09 09:25:06

使用版本号来存储分支名称，正如其他人所建议的那样，这是一个快速获胜，但是如果使用版本范围会导致问题。版本号并不意味着要这样使用。我们用它们在连续的一体化进程，使集成测试取决于测试的神器：

[1.8-SNAPSHOT,1.9-SNAPSHOT)

版本号内的限定部分表示相同的代码库的不同的增量阶段：

1.8-alpha1-SNAPSHOT 
1.8-alpha1-SNAPSHOT 
1.8-beta1-SNAPSHOT

这就是为什么版本范围之上将捕获的上方，Maven会order them in this order：

1.8-SNAPSHOT 
1.8-alpha1-SNAPSHOT 
1.8-alpha1-SNAPSHOT 
1.8-beta1-SNAPSHOT

任何神器携带的特性分支版本号（1.8-featureA-SNAPSHOT）中的名称将比无限定符的快照更新。但功能分支是一个“不同的”代码库，而不是相同代码库的更新代表。对于我们的集成测试场景，这导致无用的测试失败。功能分支尚未准备好通过集成测试进行测试。

我们现在遵循这个规则：如果您必须改变某些东西，为什么不是神器ID？我们更改了功能分支的工件ID，它工作得很好。

来源

2015-02-19 08:47:34

虽然功能分支是“不同的”代码库，但它仍然是与主版本相同的项目。似乎应该有一个解决方案，而不是修改工件ID。我没有一个=（也许Maven版本要么功能齐全（支持范围），要么太不灵活（只支持3个点阵版本abc作为数字，并且默认为abcd字符串） – 2015-06-16 20:34:23

FWIW：我要完全功能分支上的不同版本在功能分支上具有'1'，'2'，'3'，'4' ...以及特征分支上的'featureA-001'，'featureA-002'，...考虑'featureA- SNAPSHOT'也是，但看起来像是一个更复杂的方法 – 2015-06-16 23:15:10

这是事实 - 然而，使用Maven中的版本范围无论如何都存在各种问题（例如需要坚持Maven的版本号格式），所以我不认为它们是在实践中使用很多，如果你从不使用版本范围，这个问题不适用。 – sleske 2016-02-05 09:09:13

您可以使用maven-branch-extension为每个功能分支有效地创建单独的SNAPSHOT名称空间，而不是更改工件的maven坐标，而是使用maven-branch-extension。从项目页面引用：

而不是在功能分支上更改版本号时，我们更改存储库。每个功能都部署到一个子目录中，基于其分支名称，位于仅用于功能分支的远程存储库中。没有人工制品被覆盖的风险。版本号不会更改。分支和合并与Git保持简单（就像它的意思！）！

该扩展插件获取当前Git 分支并解析存储库的URL中的属性，以便可以正确存储和检索工件。它还管理将工件缓存和提取到本地存储库，以便工件从功能分支存储库（如果存在）获取，从功能分支工作时获取。

这样做的好处在于，SNAPSHOT依赖关系的外部用户与主题分支的内部工作完全隔离。

来源

2017-04-11 17:34:16

如何使用Maven连续构建和部署功能分支？

回答

相关问题