Jenkins New Maven和Gradle发布管理以及为什么你应该关注它?
Jenkins现在以Jenkins Artifactory Plugin的形式为发布阶段和推广提供了一个新的健壮的解决方案。此解决方案快速、轻量级且适用于为Maven和Gradle的构建
需要一个更好的发布替代方案
如果你是使用詹金斯(或者之前的Hudson)，然后发布和推广构建工件不是必须是完美无瑕的体验，或者可能无法完全解决。为了了解造成这种情况的主要原因，我想分别看看Maven和Gradle的构建。
Maven和M2发布插件
首先,Maven。Jenkins已经有了一个解决方案来发布Maven工件
M2发布插件
。该插件本质上是客户端的包装器
Maven发布插件
。当它执行时，它运行一个out-Maven过程使用发布任务进行构建。这对于一个被设计为在用户机器上运行的插件来说是很自然的，但是在服务器端运行它有几个严重的问题:
- m2发布插件调用自己的Maven实例，该实例的版本可能与为作业定义的版本不同。Jenkins，不控制这个构建，不会记录任何关于发布工件的信息，也不会存档它们
- 该插件还使用不同的SCM设置和凭证，而不是在Jenkins中定义的。这种双重配置容易出错，并且难以再现
- 回滚很难。由于没有内置的自动回滚，当发布流中发生故障时，回滚就变成了一项手动任务。如果没有CLI，并且考虑到运行不是交互式的，这将变得更加困难。此外，SCM标签是用用户可能无法访问的凭据创建的
- 这是不必要的缓慢。事实上，一个发布流程包括3个完整的清理/编译/测试周期(您可以在本文中了解更多相关信息)博客）
Gradle
如果您正在使用Gradle，那么您已经在使用优雅的Groovy模型+脚本驱动构建了。你可能想利用这一点，并通过Gradle插件来丰富你的构建，使用自定义的发布逻辑，这可能足以满足你的需求。然而，这种方法也有一些缺点:
- 您需要在每个新项目中复制插件配置，并在构建逻辑中引入发布配置。如果您从开发人员机器上运行这个版本，这是可以的。然而，在大多数情况下，情况并非如此，从具有更大控制和可追溯性的CI服务器发布要求配置成为作业的一部分
- 如果没有Jenkins能够理解的关于释放“动作”的强大概念，那么在Jenkins中就不可能有任何指标构件库(在这种情况下是工件)，构建实际上已经发布，工件是发布的一部分
- 与Maven一样，回滚可能需要人工干预，并且在服务器上运行版本构建将不会重用Jenkins作业的设置(如SCM细节)，从而导致双重配置
认识一下Jenkins Artifactory插件
- 轻量级和快速-只需要1个编译/测试周期
- 与Jenkins退出配置紧密集成，因此可以重用SCM和构建设置。插件的执行直接集成Jenkins Maven插件和Jenkins Gradle插件
- 提供非常健壮和可靠的回滚——该插件主要关注GIT和Subversion的正常工作，尊重工具之间的差异，以及VCS中与DVCS相比如何处理标记和分支，因此我们不必在公分母上妥协
- 提供更好的控制哪些属性(在Gradle中)或POM版本(对于Maven)应该在发布时更改，哪些属性也应该在下一个开发周期中更改
- 所有提交注释都是可调整的，可以使用Jenkins参数
当与Artifactory一起用于管理构建工件时，插件也-
- 提供对分级和升级流程的高级控制——构建工件可以分级到某个存储库，分级工件可以直接从Jenkins UI发布或回滚，在Artifactory中更改发布状态，而无需重新构建
- 审核所有发行和推广活动
- 使发布版本完全可跟踪build-infoJson对象以及二进制工件，包含以下信息:环境变量;生产的所有人工制品;使用了所有有效的依赖关系;甚至是那些依赖项使用的所有许可证
- 允许用户在部署时附加自定义可搜索属性以发布工件
从用户反馈来看Jenkins Artifactory Plugin确实有所作为通过为Maven用户提供一个更好的替代方案，为Gradle用户提供一个集成的jenkins端解决方案，实现快速可靠的分期和推广体验。
现在就试一试，自己看看
Jenkins Artifactory插件可以在Jenkins插件中心，带有发布管理的特定页面在这里。所有资源都打开了Github在Apache 2许可下。
期望JFrog在下一个版本中提供类似的发布管理支持TeamCity Artifactory插件和竹工艺品插件
