Gradle Enterprise 牛逼 | 还债了

推荐理由

我为啥推荐Gradle Enterprise呢，我们在试用完之后其实感觉这部分功能还是非常非常强大的。后续我们从实际开发的痛点出发，会比较容易理解为什么打算吹一波。

1 因为开发人员比较多 编译问题又很恶心 如果是异地协作的情况下 排查问题的成本无限上升 2 编译的异常堆栈经常被吃掉，回溯问题需要添加编译参数

3 编译依赖问题难排查 尤其是buildscript的依赖 4 task 耗时以及模块编译耗时问题难以统计排查 以及很难对比两次编译结果 --scan则经常需要翻墙 5 模块数量 不同gradle生命周期的耗时情况难以统计

上述这些问题都是我在实际排查比较容易碰到的问题，但是一般的公司是没有什么人力投入到这种事情的建设上的，Gradle Enterprise雀食是个非常不错的选择。

但是在我们这波试用的过程中，这部分能力我们在enter中都是有感受到的，整体就非常酷，而且页面也很酷炫。图片进行了一部分脱敏操作啊，各位见谅啊。

日志

会把编译过程中所有的log日志整合并上报，我们可以在编译结果上看到当前所有的编译日志，并且会对崩溃和堆栈进行额外的展示，这样就可以避免我们需要额外添加-stacktrace(-s)参数进行额外的堆栈输出。

首先这样就不需要在编译时添加额外参数，并能保证每次都触发上报逻辑，所以当问题发生的情况下，只需要对应的同学把这部分编译日志给到我们，就可以让我们去帮忙定位和排查对应的编译问题了。

另外就是各位要接这个表明大概率是已经出现了编译问题了，所以一次编译时间也长，会额外增加排查问题的难度。这样12的两个问题都能被有限的解决了，美滋滋啊。

依赖树

这部分确实很酷了，我们可以在Gradle Enterprise中看到当前编译模块的依赖树。而且内部也会详细输出当前使用版本，以及变更策略等等。因为编译时依赖变更的问题排查难度较大，这样就可以方便我们在编译的最后对依赖变更问题进行排查。比如说依赖丢失，依赖策略问题导致的依赖版本升高，并且可以配合比较功能dif出两次编译的依赖变化。

如果是直接使用命令行的话，我们需要再茫茫多的依赖输出中寻找，成本其实是非常高的，官方对其进行了折叠，以及所有configuration的输出，雀食是有他们的独到之处。

插件版本

在复合构建中经常容易碰到的问题，由于上篇文章介绍的内容了，所以很容易出现一些Gradle Plugin版本不同步问题，这些问题如果出现了就比较难以排查了。会出现一些方法不匹配的问题，然后也会出现也写崩溃异常，但是说实话问题是真的非常难排查，尤其是被Settings Plugin所拉高的版本。

有了这个功能就可以快速的在Gradle Enterprise中查看当前编译的中所有混合编译相关的插件版本信息。

这个功能还是真香警告的。

编译耗时

编译耗时其实一直都是一个老大难的问题。首先我们还是要知道哪些东西慢，然后才能着手对这些进行优化。其中又要对于不同的阶段进行不同的处理，所以需要对其中的生命周期有一个完善的了解。

另外就是我们需要知道这些task相关的状态，能做编译缓存的任务就做编译缓存，所以之前我介绍的Gradle Build Cache 引发的编译问题 | Gradle Task 缓存，有对Task状态的分析。

官方也帮助我们去排查了一个kotlinCompile的增量问题，这点要给官方点个赞。

比较

我们可以对两个不同的编译任务进行比较，这种尤其对与在某个代码合入之后发生编译劣化的情况尤其有帮助的。

总结

整体上来说我个人还是觉得Gradle Enterprise是非常非常好用的，但是奈何现在节奏是降本增效，所以没有这方面的预算。而且我们也在这部分其实已经投入了一部分人力了，所以其实一些基础功能我们都是具备的。

详细可以参考下我copy我大佬写的plugin-monitor。但是个人看法，如果是小中型企业，然后对这方面有痛点的情况下，Gradle Enterprise雀食是一个非常不错的选择，而且其实价格也还好。