在进行持续交付时,自动项目版本的Maven方式是什么？

Question

我有一个Web应用程序,我们可以在功能准备就绪时部署到生产环境,有时可能每天运行几次,有时可能需要几周时间才能发布.

目前,我们没有为我们的项目增加我们的版本号,而且所有版本都在版本中0.0.1-SNAPSHOT保存了一年多.我想知道为Web应用程序进行持续交付的Maven方式是什么.在每次提交时提高版本号并且从不像我们现在所做的那样碰撞版本号似乎有点过分,似乎也是错误的.

对于此类Maven使用,建议的最佳做法是什么？

问题实际上是双重问题:

• 在单个pom.xml文件中推进项目版本号(可以有很多).
• 更新所有相关组件中的版本号以使用彼此的最新版本号.

Answer 1

我推荐以下演示文稿,讨论使用Maven进行持续交付的实际情况:

• 你用Maven在CD上播放演示文稿
• 幻灯片

关键点是每个构建都是一个潜在的版本,所以不要使用快照.

Answer 2

这是我根据Mark O'Connor的回答链接的视频摘要.

• 该解决方案需要像git这样的DVCS和像Jenkins这样的CI服务器.
• 不要在Continuous Delivery管道中使用快照构建,也不要使用maven release插件.
• 快照版本,如1.0-SNAPSHOT都变成了现实版本,如1.0.buildNumber在buildNumber是詹金斯作业号.

算法步骤:

1. Jenkins使用源代码克隆git repo,并说源代码有版本 1.0-SNAPSHOT
2. Jenkins创建了一个名为git的分支,1.0.JENKINS-JOB-NUMBER因此快照版本变成了真实版本1.0.124
3. Jenkins调用maven版本插件将pom.xml文件中的版本号从1.0-SNAPSHOT更改为1.0.JENKINS-JOB-NUMBER
4. 詹金斯援引 mvn install
5. 如果mvn install成功,那么Jenkins将提交分支,1.0.JENKINS-JOB-NUMBER并且在git中使用适当的标记创建真正的非快照版本以便稍后再现.如果mvn install失败,那么Jenkins将删除新创建的分支并使构建失败.

我强烈推荐Mark的答案链接的视频.

Answer 3

从Maven 3.2.1开始,支持开箱即用的交付友好版本:https://issues.apache.org/jira/browse/MNG-5576 您可以在版本中使用3个预定义变量:

${changelist}
${revision}
${sha1}

所以你基本上做的是:

1. 将您的版本设置为eg 1.0.0-${revision}.(您可以使用mvn versions:set在多模块项目中快速正确地执行此操作.)
2. <revision>SNAPSHOT</revision>为当地发展投入房产.
3. 在CI环境中运行mvn clean install -Drevision=${BUILD_NUMBER}或类似甚至是这样的mvn clean verify -Drevision=${BUILD_NUMBER}.

您可以使用例如https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin来生成有趣的构建号.

一旦发现构建稳定(例如通过验收测试),您就可以将版本推送到Nexus或其他存储库.任何不稳定的构建都会变成垃圾.

Answer 4

有一些很好的讨论和建议如何处理maven版本号和持续交付(CD)(我将在我的部分答案之后添加它们).

首先我对SNAPSHOT版本的看法.在maven中,SNAPSHOT显示当前正在开发到SNAPSHOT后缀之前的特定版本.因此,像Nexus或maven-release-plugin这样的工具对SNAPSHOTS有特殊的处理方式.对于Nexus,它们存储在一个单独的存储库中,并允许使用相同的SNAPSHOT版本更新多个人工制品.所以SNAPSHOT可以在你不知道的情况下改变(因为你永远不会增加你的pom中的任何数字).因此,我不建议在项目中使用SNAPSHOT依赖项,特别是在CD世界中,因为构建不再可靠.

由于上述原因,当您的项目被其他项目使用时,SNAPSHOT作为项目版本将是一个问题.

对我来说,SNAPSHOT的另一个问题是不再可追溯或可重复.当我在生产中看到版本0.0.1-SNAPSHOT时,我需要进行一些搜索以找出它是从构建的修订版本构建的.当我在文件系统上找到该软件的版本时,我需要查看pom.properties或MANIFEST文件,看看这是旧垃圾还是最新最好的版本.

为了避免手动更改版本号(特别是当您每天构建多个版本时),让构建服务器为您更改编号.所以对于开发我会选择

<major>.<minor>-SNAPSHOT

版本,但在构建新版本时,构建服务器可以用更独特和可追踪的东西替换SNAPSHOT.

例如其中一个:

<major>.<minor>-b<buildNumber>
<major>.<minor>-r<scmNumber>

因此,主要和次要数字可用于营销问题或仅显示达到新的重要里程碑,并且可以在您需要时手动更改.buildNumber(来自Continuous Integration服务器的编号)或scmNumber(SUbversion或GIT的修订版)使每个版本都是唯一且可追踪的.使用buildNumber或Subversion修订时,项目版本甚至可以排序(不使用GIT编号).使用buildNumber或scmNumber也很容易看出此版本中有哪些更改.

另一个例子是使用的stackoverflow的版本控制

<year>.<month>.<day>.<buildNumber>

这里缺少链接:

• 管道中的版本控制
• 持续交付和Maven

Answer 5

不要这样做!

<Major>.<minor>-<build>

因为Maven在连字符之后将任何东西视为LEXICAL,所以会在背后咬你.这意味着版本1将在词法上高于10.

这很糟糕,好像你在maven中要求最新版本的东西,然后上述点获胜.

解决方案是使用小数点而不是构建号之前的连字符.

做这个!

<Major>.<minor>.<build>

在本地拥有SNAPSHOT版本是可以的,但作为构建的一部分,最好使用它

mvn versions:set -DnewVersion=${major}.${minor}.${build.number}

有一些方法可以从pom派生主要/次要版本,例如使用help:在调用版本之前评估和管道到环境变量:set.这很脏,但我真的摸不着头脑(以及我团队中的其他人)让它更简单,而且(当时)Maven还不够成熟,无法处理这个问题.我相信Maven 2.3.1可能会有一些帮助这个的东西,所以这些信息可能不再相关.

对于一群开发人员来说,在同一个major.minor版本上发布是可以的 - 但是要注意微小的更改是非破坏性的,并且主要的版本更改会导致一些重大的API更改或功能/行为的弃用.

从持续交付的角度来看,每个构建都可能是可释放的,因此每次签入都应该创建一个构建.