java - 使用 Jenkins 内部版本号安装/部署 Maven

Question

更新#1 9/18

我的公司已决定彻底改造他们的开发/发布周期，以适应越来越多的开发者。

git 进程将类似于 successful branching model有一些变化。开发人员无需直接推送访问“开发”分支，而是需要发出合并/拉取请求，需要代码审查和基本单元测试。

版本系统将是 Major.Minor.Patch，其中 Major 版本标记向后兼容性中断，Minor 版本标记新功能和小错误修复，Patch 标记关键热修复。这个新版本系统将删除作为有用信息的 Jenkins 构建号，但出于历史目的将其附加到已部署的 Artifact 。

“开发”分支将由 Jenkins 跟踪以构建快照并将其部署到我们本地的 Nexus，因此开发人员可以使用未发布但已接受的功能。 “master”分支也将由 Jenkins 跟踪以构建和部署发布 Artifact 。

发布过程将:

• 根据已发布的功能更新 POM 版本
• Git 用新版本标记分支
• 执行单元、集成和系统测试。
• 构建、混淆发布 Artifact 并将其部署到我们的 Nexus
• 将“develop”分支版本更新为“Major.Minor++-SNAPSHOT”以获得新的开发 SNAPSHOT。

原帖

我正在尝试构建一个经过混淆处理的 JAR 库，使用基于 Jenkins/Hudson 构建的动态构建编号，并部署到内部 Sonatype Nexus。

我的问题是 Maven 安装/部署不接受对 finalName 的更改，并且使用如下表达式设置版本被认为是“不良做法”:

    <version>1.0.${buildNumber}</version>

尽管这是不好的做法，但它会正确安装/部署具有正确版本的 Artifact ，包括本地和远程。内部版本号基于一对配置文件，这些配置文件链接到 Jenkins 构建系统的内部版本号环境变量的存在，并且在没有该变量的情况下默认为 0:

    <profile>
        <id>static_build_number</id>
        <activation>
            <property>
                <name>!env.BUILD_NUMBER</name>
            </property>
        </activation>
        <properties>
            <buildNumber>0</buildNumber>
        </properties>
    </profile>
    <profile>
        <id>dynamic_build_number</id>
        <activation>
            <property>
                <name>env.BUILD_NUMBER</name>
            </property>
        </activation>
        <properties>
            <buildNumber>${env.BUILD_NUMBER}</buildNumber>
        </properties>
    </profile>

我们不使用 SNAPSHOT 版本，因为任何提交并推送到 Nexus 的版本都被视为经过测试的发布版本。

是否有一种“正确”的方式来根据 Jenkins/Hudson 动态构建号设置 Maven 版本，从而允许它与更新后的版本一起部署？

Answer 1

maven 方式表示版本仅在您发布代码时更改，并且相同版本的两个连续构建应该产生相同的输出。

在您的情况下，您将违背这两个良好做法。

如果真的每个 提交都是一个新版本，那么您所做的事情听起来并没有什么大错(但对我来说确实很有趣)。一个缺点是它看起来不像是从 VCS 创建标签(这是另一种好的做法)。

我会说实话。我不敢相信每次提交都是生产就绪的版本。我从未见过这种情况，即使在持续交付环境中，每次提交都需要通过大量自动化测试，有时修订会被拒绝(可能出于功能或性能原因)。