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

Question

我在过去2个月与Maven合作。我想我理解它已经足够但还不确定:)我将Snapshot构建编译，安装并部署到我们的团队存储库。

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

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

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

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

Answer 1

我也正在研究这个问题。我是一个硬核的Maven用户，我仍然用发布插件撞到了墙上（尤其是当与Mercurial一起使用时）。

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

• Why I Never user the Maven release plugin
• Maven Releases on Steroids: Adios Release Plugin!
• Get rid of your tedious and error-prone release process

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

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

Answer 2

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

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

您需要使用发布分段。运行发布插件以生成带有标记的真实版本，但是在临时区域（通过Nexus Pro，Archiva的下一个版本或使用altDeploymentUrl）中的工件被监禁。有QA测试暂存区版本。如果他们保佑它，将这些位推广到正式发布区域。如果QA对其进行处理，请删除标签并删除暂存区域。

因此，您完成了对您想象的运输的测试。

Answer 3

1. 您可以在将快照发送给QA后立即打开分支。
2. 锁定发送给QA的主分支/主干。
3. 如果接受，请使用已接受的分支/主干上的发布插件。
4. 将主网上的pom升级到下一个SNAPSHOT，如果添加了任何内容，则将其与openned分支合并。

Answer 4

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

Maven Releases on Steroids

Answer 5

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

以下是使用TeamCity Artifactory Plugin - Release Management执行操作的示例。

如果你使用像詹金斯这样的另一个CI服务器，还有像Nexus这样的另一个二进制存储库，我确信会有相同的可能性。