38

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

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

  • 分支：主
  • 分类： 无

  • 工件：foo-${version}.jar、foo-${version}-sources.jar、foo-${version}-javadoc.jar

  • 分支：特征-X

  • 分类： myfeature
  • 文物：foo-${version}-feature.jar, foo-${version}-sources-feature.jar,foo-${version}-javadoc-feature.jar

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

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

4

4 回答 4

10

我建议将分支限定符添加到版本组件中，因为它与该部分更相关。这也允许您的快照依赖于主分支旁边的那些版本。

于 2012-07-10T12:51:13.707 回答
9

我建议使用代表分支的适当版本以及版本，例如：

1.0.0-SNAPSHOT 主控

和

功能 F1 的 1.0.0-F1-SNAPSHOT

等等

这也给出了一个指标，该功能分支是从哪个版本 1.0.0 生成的。

于 2012-07-10T13:20:38.050 回答
8

正如其他人所建议的那样，使用版本号存储分支名称是一个快速的胜利，但如果您使用版本范围会导致问题。版本号并不是要那样使用的。我们在持续集成过程中使用它们来使集成测试依赖于被测试的工件：

[1.8-SNAPSHOT,1.9-SNAPSHOT)

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

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

这就是为什么上面的版本范围会捕获上面的内容并且 Maven 会按这个顺序排列它们：

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

任何在版本号 ( ) 中带有功能分支名称的工件1.8-featureA-SNAPSHOT都将比没有限定符的快照排序。但是功能分支是一个“不同的”代码库，而不是相同代码库的更新表示。对于我们的集成测试场景，这导致了无用的测试失败。功能分支尚未准备好通过集成测试进行测试。

我们现在遵循这条规则：如果您无论如何都必须更改某些内容，为什么不更改工件 ID？我们更改了功能分支的工件 ID，它工作得很好。

于 2015-02-19T08:47:34.537 回答
5

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

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

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

The beauty of this is that external users of the SNAPSHOT dependencies are completely isolated from the internal work on topic branches.

于 2017-04-11T17:34:16.287 回答