如果您正在考慮從 Maven 遷移到 Gradle，我希望了解更多有關 Spring Boot 團隊的經驗是有用的。 如果你是一個快樂的Maven 用戶，請繼續使用和支持適合你的工具。

原文地址：https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle

我們在 2.3.0.M1 中對 Spring Boot 進行了相當大的改變。 這是使用 Gradle 而不是 Maven 構建的項目的第一個版本。 關于遷移的 Twitter 上的帖子 有很多人問我們為什么切換以及我們看到的好處（如果有的話）。 這篇博文旨在回答這些問題。

Spring 產品套件中的每個項目都以相當自主的方式運行。 我們力求在用戶最容易看到的地方保持一致性--例如 API 設計，但選擇最能滿足項目需求的工具就不太明顯。 一個例子是構建系統。 對構建系統的改變會影響那些為項目做出貢獻的人，但如果我們做對了，它對用戶是沒有影響的。 這導致混合了基于 Maven 和 Gradle 的構建。 例如，自 2012 年 3.2.0.M1 以來，Spring Framework就一直使用 Gradle 構建；而 Spring Boot一年后誕生的，Spring Cloud也在此后不久開始，兩者當時都使用基于 Maven 的構建。 與 Spring Boot 不同的是，Spring Cloud目前沒有切換的計劃，因為Maven滿足他們的需求。 簡而言之，如果您從這篇博文中只得到一件事，那就是您應該選擇最能滿足您項目需求的任何工具。

我們為什么要切換?

Spring Boot 團隊考慮切換到Gradle的主要原因是減少構建項目所需的時間。 在進行測試修改時，我們對反饋循環的長度感到沮喪。 等待構建完成所花費的時間增加了修復錯誤和實現新功能所花費的時間。 我們在其他Spring 項目中看到了Gradle 的增量和并行構建以及在第三方項目中的 Gradle 構建緩存的好處。 我們希望我們可以在 Spring Boot 的構建中獲得類似的好處。

我們過去曾嘗試利用 Maven 對并行構建的支持。 由于 Spring Boot 構建的復雜性，尤其是對 Invoker 插件的使用，我們的嘗試失敗了。 我們通過在CI（持續集成）上將構建分成四個部分來解決這個問題。 該項目的主要核心是先構建的，然后并行構建三個獨立的部分。 這種安排雖然有所幫助，但CI構建任務仍然需要一個小時或更長時間。 此外，由于拆分結構是特定于 CI 構建的，它并沒有使開發人員的本地構建更快。

Gradle 有一個構建結構的廣泛模型，了解每個任務的輸入和輸出及其相互依賴關系。 這種建模的承諾是它允許任務并行運行，同時也可以增量、緩存或完全避免。 換句話說，Gradle 旨在最大限度地減少構建任何給定更改所需的工作量，并行執行必要的工作。 如果我們堅持并廣泛重組 Spring Boot 的構建，那么使用 Maven 并行構建可能是可行的。 而且，如果我們使用 Gradle Enterprise 的Maven支持，我們也可以享受構建緩存和避免的好處。 然而，為了充分享受這四個方面的好處，我們覺得我們必須嘗試切換到 Gradle。

我們怎么切換?

我們看到的對 Gradle 的一種批評是，它導致構建比基于 Maven 的同類產品更難維護和理解。 Gradle的靈活性允許以微妙不同的方式完成任務，即使是在同一構建中的模塊之間也是如此。 如果要成功切換，我們需要避免這種情況發生。 我們已經發布了四個Spring Boot 2.3 里程碑（候選版本和 Gradle 的最終版本），看起來已經成功了。 核心團隊或任何其他貢獻者都沒有看到任何重大的構建問題。

Spring Boot 的一個關鍵特性是“約定優于配置”，我們也將這種方法應用于構建。遵循“ 避免在 build.gradle 文件中包含命令式邏輯 ”的建議，我們編寫了幾個可以找到的小插件在項目的 [buildSrc]（https://github.com/spring-projects/spring-boot/tree/d4c7315369e7e9dce6eb1c77e5f23d1e670247c8/buildSrc）中。例如我們有一個starter plugin 應用于每個 Spring Boot 啟動模塊，確保它們都被一致地配置、構建和發布。我們還有一個約定插件對正在應用的其他插件做出反應，并配置諸如源代碼編碼、JUnit 平臺的使用以及使用“-parameters”編譯等內容。

這種方法導致 build.gradle 文件幾乎完全是聲明性的。 盡管我們編寫了許多插件來應用我們的約定并填補Gradle 生態系統中的空白， 但遷移到 Gradle 的提交 卻從代碼庫中刪除了近 9500 行。

切換有好處嗎?

在減少項目的構建時間方面，將構建遷移到 Gradle 無疑是成功的。 如上所述，在 CI 和開發人員自己的機器上，一個完整的基于 Maven 的構建需要一個小時或更長時間。 在過去的四個星期里，使用 Gradle平均成功構建時間為 9 分 22 秒，如下面的屏幕截圖所示：

我們從 JDK 8 CI 構建發布快照。 專注于那些，它在過去 4 周內成功了 183 次 與 平均構建 時間 19 分 37 秒。 查看成功的本地構建，我們可以看到:

過去 4 周內成功構建了 273 個

平均構建時間為 2 分 30 秒

Gradle 吸引我們的另一個好處是 我很享受 在為 Testcontainers 做貢獻時的體驗。 我們希望 Spring Boot 的貢獻者能夠盡快克隆和構建項目。 感謝遠程構建緩存，可以 3 分鐘內構建完成，這包括下載大量依賴項所花費的時間。

如果您對構建性能的更多細節感興趣，可以在我們的公共 Gradle Enterprise 實例 上獲得更多數據。

除了性能改進之外，我們還開始研究其他一些可用的數據。例如，我們已經意識到我們有一些不穩定的測試一段時間了。由于它們，構建失敗的頻率超出了我們的預期，我們現在可以在 Tests dashboard中看到這一點。我們已經開始使用 Gradle 的易碎測試緩解來識別 CI 上發生的任何易碎測試幫助我們了解我們是否已成功解決或解決問題。

結論

我們對遷移的進展以及我們所看到的構建時間的減少感到非常滿意。 CI 構建現在平均需要大約 20 分鐘，比以前快 3-4 倍。 本地構建平均需要 2 分 30 秒，比以前快 20-30 倍。

我想借此機會感謝 Gradle 團隊在遷移過程中提供的幫助，并慷慨地為我們提供了 Gradle Enterprise 許可證以用于我們的開源項目。 我們已經將它與 Spring Framework、Spring Security 和 Spring Boot 一起使用，其他團隊計劃開始將它用于基于 Gradle 和 Maven 的構建。

我還要感謝我們正在使用的各種第三方插件的維護者。 他們提出了建議的更改并合并了拉取請求，以改進對增量構建和緩存的支持。 沒有它們，我們將無法實現我們所看到的構建時間的減少。

如果您正在考慮從 Maven 遷移到 Gradle，我希望了解更多有關 Spring Boot 團隊的經驗是有用的。 如果你是一個快樂的 Maven 用戶，請繼續使用和支持適合你的工具。

文章出自：??愛科學的衛斯理??，如有轉載本文請聯系愛科學的衛斯理今日頭條號。