推荐理由
我为啥推荐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雀食是一个十分不错的选择，并且其实价格也还好。
