Maven 发布插件以及 ci 友好版本

Question

我只是设置一个 Maven 多模块项目，其版本为

${revision}

，如 https://maven.apache.org/maven-ci-Friendly.html

中所述

属性

${revision}

在父 POM 中设置，并在所有模块中用作版本号。

这对于 SNAPSHOT 构建来说效果很好，但是当我运行 Maven 发布插件时，版本会被替换为

1.0.0

和

1.0.1-SNAPSHOT

之类的内容。因此，ci 友好版本在发布后就消失了。

有没有办法以不破坏ci友好版本的方式配置Maven发布插件？

Answer 1

CI 友好版本方案旨在取代 Maven Release Plugin，而不是 补充它。在当今的开发世界中，大多数团队都依赖 CI 服务器进行集成测试、执行自动化测试以及持续交付或持续部署的发布。 当一切都可能是 SNAPSHOT

 时，

SNAPSHOT

 的概念确实受到限制。

值得注意的是，发布插件执行的进程比正确实施的 CI 友好配置多 4 到 5 倍。 想象一下使用发布插件的 50 分钟构建变成使用 CI 策略的 15 分钟构建。 现在这就是现代化！

基本思想是版本中使用的值将从

DVCS（Git

、

SVN

等）和

CIS（Jenkins

、

Travis CI

、

GitLab

等）收集。 ) 在构建时用于修改或设置 POM/发布版本。这些值是诸如内部版本号、缩短的 Git 哈希值或其他任何值。

实施 CI 友好 Maven 构建的过程：

Maven
• 仅支持 <version> 标签中的少数属性

  。它们是 

  ${revision}

  、

  ${changelist}

   和 

  ${sha1}

  。

您可以使用硬编码值和可接受的属性，也可以仅使用类似
• ${revision}

   的内容。 

  注意：我现在推荐${revision}

  。

在
• <properties>

   中，将值设置为可接受的默认值 - 明显来自非构建机器的虚假值，例如 

  0

   表示构建号。

在
• <properties>

   中，组合 

  <revision>

   的值，例如来自其他属性和硬编码值的版本。例如，

  <revision>1.0.0b${changelist}-${sha1}</revision>

  。

在构建时，使用
• -D

   标志来设置实际值。例如，

  ${BUILD_NUMBER}

  值被注入到每个 Jenkins 构建中——

  -Dchangelist=${BUILD_NUMBER}

  。

您现在可以灵活地更改版本号组件。

在 CI 管道中，您现在可以检测提交分支并通过清除全部或部分这些值来从

master

 执行发布。例如，功能分支可以计算并添加 Git 哈希值。语义版本在上面设置——开发人员现在拥有并控制它。他们必须知道自己的代码才能进行更改，并且可以自由地增加语义版本。这是非常宝贵的灵活性。

不过，这里合理的推理是加快速度并摆脱重量级流程，该流程实际上几乎没有添加将代码与其精确来源联系起来的相关信息。通过使用 CI 友好版本，您将让部署人员、测试人员和系统管理员看到编译号和代码提交哈希，从而使问题与实际代码发布精确相关。

应该指出的是，这需要一点哲学灵活性来接受范式转变。改变是好的，放弃发布插件将使你的发布管道变得更好。