maven - 使用 Sonatype Nexus OSS 进行基于功能的开发

标签 maven nexus git-flow

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

我正在从事一个跨国项目,该项目使用 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 交换 Artifact (其他组件的源代码不可访问)。因此 A:feature/A-foo 必须部署其快照 Artifact 以使其可用于 B:feature/B-foo,反之亦然。

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

一种解决方案是使用功能名称(例如 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 的 Artifact ,因为它们具有不同的 GAV。但这很容易出错(分支时重命名 GAV,再次合并到开发时重命名回来;如果有人忘记重命名,就会搞乱构建)。

还有更好的解决办法吗?或者应该禁止在功能分支上部署?

最佳答案

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

关于maven - 使用 Sonatype Nexus OSS 进行基于功能的开发,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20574620/

相关文章:

java - 了解 Maven 存储库和 Artifactory(如 Nexus)

git - 使用 maven + gitflow 发布

git - 两个补丁之间的差异

maven - Gradle Multi Project jar不包含依赖类

maven - 如何从Grails命令/SDK清除Maven缓存?

java - 具有多个模块的 Maven 项目无法找到模块的 pom.xml - Jenkins/Eclipse

java - 如何让一个Web Maven项目以优化的方式依赖于另一个Web Maven

rest - 组内的 Nexus REST API 查询工件

python - 使用 httplib2 处理身份验证和代理服务器

git - 使用 Git 特性分支工作流,什么时候更新 master 分支?