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