更新#1 9/18 我的公司决定彻底改进他们的开发/发布周期,以适应越来越多的开发人员. git进程类似于successful branching model,只有一些变化.开发人员需要进行合并/拉取请求,而不是开发人员直接推送访问“开发”分支,需要进行代码审查和基本单元测试. 版本系统将是Major.Minor.Patch,其中主要版本标记向后兼容性中断,次要版本标记新功能和小错误修复,Patch标记关键热修复.此新版本系统将删除Jenkins构建号作为有用的信息,但出于历史目的将其附加到已部署的工件. Jenkins将跟踪“开发”分支,以构建和部署SNAPSHOT到我们的本地Nexus,因此开发人员可以使用未发布但已接受的功能. Jenkins还将跟踪“主”分支,以构建和部署发布工件. 发布过程将: >根据已发布的功能更新POM版本 原始邮政 我正在尝试构建一个混淆的JAR库,使用基于Jenkins / Hudson构建的动态构建号,并部署到内部的Sonatype Nexus. 我的问题是,Maven install / deploy不会更改finalName,并且使用如下表达式设置版本被视为“不良做法”:
尽管这是不好的做法,但它正确地安装/部署具有适当版本(本地和远程)的工件.构建号基于一对配置文件,这些配置文件链接到Jenkins构建系统的构建号环境变量的存在,并且在缺少该变量时默认为0:
我们不使用SNAPSHOT版本,因为任何提交并推送到Nexus的版本都被视为测试版本. 是否有一种“正确”的方法来设置基于Jenkins / Hudson动态内部版本号的Maven版本,允许它使用该更新版本进行部署? 解决方法: maven方式表示只有在释放代码时才更改版本,并且相同版本的两个连续版本应该产生相同的输出. 在你的情况下,你反对这两个好的做法. 如果真的每次提交都是新版本,那么你所做的并不是非常错误(但对我来说听起来很有趣).一个缺点是它看起来不像是你从VCS创建一个标签(这是另一个好习惯). 我会说实话.我无法相信每个提交都是生产就绪版本.我从来没有见过这个,即使在持续交付环境中,每个提交都需要通过大量自动化测试,有时修订被拒绝(可能出于功能或性能原因). 来源:https://www./content-1-311301.html |
|