Question

我的团队正在使用功能分支来实现新功能，并不断将快照构建部署到远程仓库中供我们的用户使用。因此，“部署”实际上只意味着“分发到远程Maven存储库”。我们目前只为主分支而不是功能分支运行持续集成构建，原因如下：我们使用Maven构建项目并将JavaDoc和源代码分布在JAR旁边。

我的计划是为每个功能分支构建添加一个分类器，并期望在创建和部署这样的工件时使用该分类器：

分支：主人
分类器：无
工件：foo-${version}。jar，foo-${version}-sources。jar，foo-${version}-javadoc.jar
分支：feature-X
分类器：myfeature
工件：foo-${version}-feature.jar，foo-${version}-sources-feature.jar，foo-${version}-javadoc-feature.jar

我并不真正关心工件的确切命名，我只需要为功能分支单独的main，source和JavaDoc工件。事实证明，JavaDoc插件和源插件都没有考虑配置的分类器，因此有效地覆盖了为我的主构建创建的工件。

我真的不想更改artifactId，尽管这可能会解决问题。你如何处理功能分支和与Maven的持续集成？

Answer 1

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

Answer 2

我建议使用代表分支的适当版本以及类似的版本：

主人的1.0.0-SNAPSHOT

和

1.0.0-F1-SNAPSHOT for feature F1

等

这也给出了一个指标，从中发布了1.0.0特征分支。

Answer 3

使用版本号来存储分支名称，如其他人所建议的那样快速获胜，但如果使用版本范围则会导致问题。版本号不应该像那样使用。我们在持续集成过程中使用它们，以使集成测试依赖于测试的工件：

[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，它可以正常工作。

Answer 4

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

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

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

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

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

4 个答案: