【问题标题】:Feature-based development with Sonatype Nexus OSS使用 Sonatype Nexus OSS 进行基于功能的开发
【发布时间】:2025-11-28 06:25:01
【问题描述】:

我想知道是否可以同时在多个功能分支上处理一个 Maven 项目,并避免不断覆盖 Nexus 中其他功能分支产生的工件。

我在一个跨国项目中工作,该项目使用 gitflow 工作流来开发多个组件 (30+)。每个组件都有一个 git 存储库,因此 gitflow 工作流程适用于每个组件。所以每个组件都有一个开发和几个功能分支。一般来说,每个组件都会产生至少一个由其 GAV 识别的人工制品。

假设我们有组件 A(具有功能分支 feature/A-foo 和 feature/A-bar)和 B(具有功能分支 feature/B-foo)

Component A:
A:develop
A:feature/A-foo
A:feature/A-bar

Component B:
B:develop
B:feature/B-foo

A:feature/A-foo 和 B:feature/B-foo 工作在同一个主题上,需要交换快照版本以测试它们的交互(例如客户端/服务器功能)。组件 A 和 B 只能通过 Nexus 交换工件(无法访问其他组件的源代码)。因此 A:feature/A-foo 必须部署其快照工件以使其可用于 B:feature/B-foo ,反之亦然。

但是,当 A:feature/A-bar(适用于完全不同的主题)之后部署时,由于相同的 GAV 和更新的时间戳和 B:feature/B-foo,它会“覆盖”Nexus 中的快照工件将在下一次构建中导入错误的工件。

一种解决方案是使用功能名称(例如 foo)扩展 GAV:

some.company.componentA-1.2.3-foo.jar
some.company.componentA-1.2.3-bar.jar
some.company.componentB-3.2.1-foo.jar

这样可以避免 A:feature/A-foo 覆盖 A:feature/B-bar 的工件,因为它们具有不同的 GAV。但这很容易出错(分支时重命名 GAV,再次合并到开发时重命名它;如果有人忘记重命名它,它会弄乱构建)。

有没有更好的解决方案?还是应该禁止在功能分支上部署?

【问题讨论】:

标签: maven nexus git-flow


【解决方案1】:

功能分支不应长期存在,因此在许多情况下您最终根本不会部署。但是,如果您确实想部署(这是一件好事),版本字符串中的分支限定符是​​最好的方法。如果您使用负责版本更改的脚本自动创建分支,则根本不会容易出错,并且实际上是您整体策略的良好理智。添加一个特定于功能的 CI 作业(或其中一些),也许使用版本 Maven 插件,你应该准备好滚动了。

【讨论】:

  • 我在 Jenkins 中定义了两种不同的工作类型。一种用于持续构建(监听 feature/* 分支),另一种用于夜间构建(仅监听开发分支)。一般来说,持续构建作业不会部署在特性分支上生成的工件;只是部署了开发分支。但在某些情况下,您需要在功能分支上部署 SNAPSHOTS。调整版本号结果是有效的,但对我来说这不是令人信服的解决方案。但显然没有更好的解决方案。 “使用版本 Maven 插件”是什么意思?
  • 版本 Maven 插件可用于脚本中,通过一个命令将整个多模块项目的版本设置为不同的版本。您可以自动更改版本号以轻松包含分支名称。
最近更新 更多