4

更新 #1 9/18

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

git 过程将类似于成功的分支模型，但有一些更改。开发人员不需要直接推送访问“开发”分支，而是需要提出合并/拉取请求，需要代码审查和基本单元测试。

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

Jenkins 将跟踪“开发”分支以构建和部署 SNAPSHOT 到我们本地的 Nexus，因此开发人员可以使用未发布但已接受的功能。Jenkins 还将跟踪“master”分支以构建和部署发布工件。

发布过程将：

  • 根据发布的特性更新 POM 版本
  • Git 用新版本标记分支
  • 执行单元、集成和系统测试。
  • 构建、混淆和部署发布工件到我们的 Nexus
  • 将“develop”分支版本更新为“Major.Minor++-SNAPSHOT”，用于新的开发 SNAPSHOT。

原帖

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

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

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

尽管这是一种不好的做法，但它会正确安装/部署具有正确版本的工件，包括本地和远程。内部版本号基于一对配置文件，这些配置文件与 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 版本，从而允许使用该更新版本进行部署？

4

1 回答 1

1

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

在你的情况下，你违背了这两个好的做法。

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

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

于 2012-09-17T19:14:53.360 回答