Maven 发布过程问题（发布插件的任何替代方案）答案

【问题标题】：Maven release process issues (Any alternative to release plugin)Maven 发布过程问题（发布插件的任何替代方案）
【发布时间】：2011-10-07 18:58:01
【问题描述】：

在过去的 2 个月里，我一直在使用 Maven。我想我已经理解够了，但还不确定 :) 我已编译、安装并部署到我们的团队存储库中的 Snapshot 版本。

因此计划是为开发环境使用快照构建，一旦稳定告诉 QA 团队将其用于 QA，一旦 QA 接受构建，将相同的构建推广到生产环境。

如果发现快照构建良好，我的要求。我想要关于生产的确切信息。如果我使用发布插件，它会标记并重建源代码并签出标记并部署它（在此过程中从版本字符串中删除 SNAPSHOT）。这里的问题是我不能保证它与 QA 接受的快照版本具有相同的位。

另外，我觉得标记构建是多余的，因为 Jar 清单具有 SVN 修订版。所以我总是可以回到那个 SVN 版本，从 Maven 工件 Jar 追溯构建。

所以我的问题是，有没有一种简单的方法来推广 QA 团队可以接受的快照构建？

【问题讨论】：

【解决方案1】：

我也在研究这个问题。我是 Maven 的铁杆用户，但我仍然用发布插件（尤其是与 Mercurial 一起使用时）碰壁。

以下是我遇到的一些其他相关链接：

最后一个仍然依赖于maven-release-plugin，但至少它更深入地了解了使用它的陷阱。

我们正在考虑采用更简单的方法，使用我们自己的脚本来管理流程，使用 Maven 更新版本号（例如mvn versions:set -DnewVersion=1.1.0），但实现我们自己的分支/标记/提交工作流。

【讨论】：

您可以让 CI 服务器负责部署。这是Artifactory integrates with TeamCity 的示例。我确信 Jenkins/Nexus 或您使用的任何组合都可以做到这一点。我实际上会将其添加为答案。

【解决方案2】：

如果您使用快照，则不能有“相同的位”。您可以从完全相同的来源构建位。使用 build-number-plugin 将源代码控制修订捕获到构建中。当 QA 喜欢它时，标记该版本并创建一个分支。然后手动将版本号设置为所需的发布版本。

或者，停止用砖头砸自己的脚，并按预期使用发布插件。

您需要使用发布阶段。运行发布插件以生成带有标签的真实发布，但工件被关押在暂存区域（通过 Nexus Pro、Archiva 的下一个版本或使用 altDeploymentUrl）。让 QA 测试暂存区版本。如果他们祝福它，请将这些位推广到正式发布区域。如果 QA 确定了，请删除标签并删除暂存区。

这样您就完成了对您想象中要运送的部分的测试。

【讨论】：

感谢您的回复。虽然我希望 Maven 有一种简单的方法来推广快照而不打扰位。
不能。在你的 jar 里面是一个包含 POM 的 META-INF 区域，它包含 ....-SNAPSHOT。如果您的项目是多部分的，则这些部分相互依赖，并且所有那些版本都是 -SNAPSHOT。他们不能原封不动地升级。

【解决方案3】：

【讨论】：

【解决方案4】：

这里有一篇精彩的博客，描述了使用 maven 发布插件的一个相当简单的替代方案。我们将在我们的项目中使用此策略的改编版，它避免了发布插件的许多问题和复杂性。

【讨论】：

【解决方案5】：

一种方法是让 CI 服务器与您的二进制存储库一起使用。你可以完全跳过maven-release-plugin。

我相信，如果您使用另一个 CI 服务器（如 Jenkins）以及另一个二进制存储库（如 Nexus），也会有同样的可能性。

【讨论】：