在2.3.0中对SpringBoot进行了相当大的突破性更改，这是使用Gradle而不是Maven构建项目的第一个版本。Spring的每个项目都是由一个独立的项目团队开发和运营的。在用户最常用的白盒部分（如API设计）保持一致性。对于用户不可见的黑盒部分，各项目组选择适合自己的工具。没有统一协议。例如：项目构建工具。Spring框架从2012年的3.2.0开始使用Gradle构建，一年后使用SpringBoot，不久之后使用SpringCloud，两者都基于Maven。项目构建工具SpringFrameworkGradleSpringBootMavenSpringCloudMaven为什么要切换SpringBoot团队考虑从Maven切换到Gradle的主要原因是为了减少构建项目所需的时间。在开发和测试期间，等待构建完成所花费的时间增加了修复错误和实现新功能所花费的时间。为了解决这个问题，团队尝试利用Maven对并行构建的支持。由于SpringBoot构建的复杂性，尤其是Invoker插件的使用，尝试失败了。通过将构建分成四个部分来解决CI问题。首先构建项目的主要核心，然后并行构建三个独立的部分。但是CI构建仍然需要一个小时或更长时间。此外，由于它针对的是模块化CI构建，因此它不会对开发人员本地构建的效率产生影响。SpringBoot团队已经在其他使用Gradle作为构建工具的Spring项目中看到了Gradle的增量和并行构建的好处，以及Gradle在第三方项目中的构建缓存。希望通过使用Gradle为SpringBoot构建来获得类似的好处。Gradle有一个非常灵活的构建模型，可以定义每个任务的输入和输出及其相互依赖关系。这种构建模型的好处是它允许任务并行运行，同时也可以增量、缓存或完全跳过。换句话说，Gradle可以最大限度地减少必要的CI任务。虽然我们可以使用GradleEnterprise的Maven支持，但我们也可以享受构建缓存和跳过的好处。但要充分享受这四者的好处，您必须尝试切换到Gradle。如何切换Gradle配置过于灵活，使得其构建比基于Maven的构建更难维护和理解。例如：通过不同的配置可以实现相同的构建结果。如果切换到Gradle，则需要避免这种情况。从到目前为止的四个SpringBoot2.3里程碑版本中，核心团队或贡献者都没有发现任何重大构建问题。SpringBoot的一个关键特性是约定优于配置，将这种方法应用于构建。为了避免在build.gradle文件中有命令式逻辑，已经编写了几个小插件，可以在项目的buildSrc中找到。.虽然现有的Gradle生态系统对于SpringBoot构建几乎是空白的，需要从头开始编写许多通用的gradle插件才能应用于SpringBoot，但迁移到Gradle的提交从代码库中删除了近9,500行。切换结果将构建迁移到Gradle在减少项目构建时间方面取得了明确的成功。如上所述，一个完整的基于Maven的构建在CI和开发人员机器上都需要一个小时或更长时间。基于Gradle的平均成功构建时间为9分22秒，如下面的屏幕截图所示：如果您对构建性能的更多细节感兴趣，可以在SpringBoot的公共GradleEnterprise实例上获得更多数据。除了提高性能，探索其他功能。例如，在一段时间内，许多不稳定的测试。由于这些原因，构建失败的次数超过预期，这可以在测试仪表板中看到。使用Gradle分片测试替代CI的通用测试方案，帮助我们了解是否已成功解决问题。结论CI构建现在平均需要大约20分钟，比以前快3-4倍。本地构建平均耗时2分30秒，比之前快20-30倍。
