通过 Hudson 发布 Maven [英] Maven release via Hudson

问题描述

我正在设置 Hudson 以使用批处理任务插件向我们的内部存储库执行 maven 发布.我正在通过:

I'm setting up Hudson to use the batch-task plugin to do maven releases to our internal repository. I'm doing it via:

mvn --batch-mode release:prepare
mvn --batch-mode release:perform

我对人们使用的其他方法以及这些方法的优缺点很感兴趣.此外，人们遇到的任何问题.

I'm interested in other methods people have used and the pros and cons of those methods. Also, any gotchas people have come across.

推荐答案

出于几个原因，我倾向于总是手动发布.首先，如果您必须回滚，则可以回到原始发布位置并执行此操作会更容易.其次，因为您需要在流程中解决所有快照依赖项.

I have tended to do the releases always by hand for a few reasons. First if you have to roll back it's easier when you can go back to the original release location and do it. Secondly because you need to resolve all snapshot dependencies as part of the process.

我们的开发过程要求我们将依赖项留在当前版本的当前版本之外，直到修复需要升级.这意味着如果我要发布 Nexus、Maven 等，那么我会看到快照，这意味着我必须先发布这些快照.这个过程实际上不可能自动化，因为它会根据自上次发布以来的变化而有所不同.

Our development process has us leaving dependencies external to the current build at the previous release version until a fix requires an upgrade. This means that if I'm releasing Nexus, Maven, etc, then I see snapshots and it means I have to go off and release those first. This process isn't really possible to automate since it varies based on what's changed since the last release.

也就是说，我们有一台专门用于构建的机器(在 Sonatype 中它只是一个 vm)设置.这样做是为了保证不会发生可能会意外影响构建的环境更改(例如 jdk 更改).它还使任何人都可以更轻松地了解发布过程，因为它随时准备就绪.

That said, we have a special machine (at Sonatype it's just a vm) setup only for builds. This is done to guarantee no environmental changes occur that could influence a build accidentally (like a jdk change). It also makes it easier for anyone to pick up the release process because it's always ready to go.

这篇关于通过 Hudson 发布 Maven的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！