Question

更新＃1 9/18

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

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

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

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

发布过程将：

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

原始帖子

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

我的问题是，Maven install / deploy不会更改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版本，允许它使用该更新版本进行部署？

Answer 1

maven方式表示版本只有在您发布代码时才会更改，并且相同版本的两个连续版本应该生成相同的输出。

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

如果真正每个提交都是新版本，那么你所做的并不是非常错误（但对我来说听起来很有趣）。一个缺点是它看起来不像是从VCS创建标签（这是另一个好习惯）。

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

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

1 个答案: