在Hudson的构建目标和发布的标准方法中进行'mvn deploy'

时间:2010-12-24 01:44:07

标签: java maven-2 hudson release release-management

我使用构建目标mvn clean deploy site:site为我的项目设置Hudson,每隔午夜运行一次构建,并且每当有新的更改时。

我一直想知道的一件事是我是否应该在构建目标中包含deploy,因为如果我刚刚发布了我的项目的1.0.0版本(我已经将pom更改为版本)可能会发生这种情况1.0.0并提交了它)但是几天之后版本号还没有增加到1.0.1-SNAPSHOT,我最终可能会在不同的时间部署多个不同的1.0.0版本。

但是我看到人们在他们的Hudson构建目标中使用deploy - 我想知道他们是如何处理这个问题的。

实际上与Maven一起发布的正确方法是什么?感谢您的任何指示!

1 个答案:

答案 0 :(得分:9)

您应该继续从Hudson进行自动夜间部署,但是关于如何处理版本号和版本的更大问题与您的源代码控制系统无关。你没有提到你正在使用什么样的源代码控制系统,但我可以解释如何使用Subversion做到这一点。

首先,出于您提到的原因,您应该永远将中继中源代码的版本标识符更改为快照版本以外的任何内容(例如,最后使用-SNAPSHOT )。否则,您将在重新部署时覆盖。最佳做法是(暂时)将主干pom(s)中的版本标识符更改为要发布的版本,标记主干,从标记构建,然后部署从标记生成的构建,然后立即提升trunk中的快照版本标识符,最后使用较新的较高快照版本号提交trunk。

如果这看起来很麻烦,那么您应该知道Maven Release Plugin会依靠Maven SCM Plugin自动完成对源控制系统的处理,自动为您完成所有这些工作。

虽然我已经喜欢从哈德森那里调用Maven Release Plugin,但这是一件非常敏感的事情。为了使其正常运行,这里有一些提示:

  • 真正的版本需要由Hudson执行,但开发人员可以 当然也是从他们的 开发机器来测试 发布过程。一定要确定 删除Subversion中的任何标签和任何标签 在Nexus中发布工件 之后。
  • 它使用maven-scm-plugin,而后者又需要外部 安装版本的subversion 在当前的道路上。因此版本 颠覆也必须已经存在 缓存了必要的凭据 写入subversion源 库中。
  • 如果一个发布过程中途退出,你可以做一个 release:rollback来修复poms,但是 这不会消除任何虚假标签 已经承诺的 颠覆。你必须这些 执行svn后手动删除 更新
  • 发布:回滚目标有时不会返回pom.xml 版本回到SNAPSHOT。如果 出了什么问题,检查一下POM 版本以确保使用“SNAPSHOT”。
  • 发布:回滚目标有时不会返回SCM URL 回到原来的位置。如果 什么都出错了,检查一下这些 指向“后备箱”或原产地 分支。
  • 因为我们使用Subversion,所以maven-release-plugin的配置启用了 {{suppressCommitBeforeTag}}选项 这消除了额外的提交 将其他修改trunk pom.xml 修改它们之前的文件。

另请注意,有一个Maven Release Plugin integration with Hudson,但不需要从Hudson调用Maven发布插件目标,它只是让它更容易,但是,我已经no luck获得了该插件工作。

总结一下:

  1. 仅使用中继部署 快照
  2. 使用Maven版本 插件在一段时间内从标签部署 释放。
  3. 希望这会有所帮助。