建置快取的用途

即使僅由單一開發人員使用，建置快取也可能非常有用。Gradle 的增量建置功能有助於避免已完成的工作，但一旦您重新執行工作，任何先前的結果都會被遺忘。當您來回切換分支時，即使您正在建置先前已建置過的內容，本地結果仍會一遍又一遍地重建。建置快取會記住先前的建置結果，並大幅減少在已於本地建置過的情況下重新建置的需求。這也可以延伸到重建不同的提交，例如在執行 git bisect 時。

當處理具有多個變體的專案時，本地快取也可能很有用，例如 Android 專案的情況。每個變體都有許多與其相關聯的工作，而某些工作變體維度，儘管具有不同的名稱，最終可能會產生相同的輸出。啟用本地快取後，當適用時，工作變體之間的重複使用將自動發生。

建置快取可以做的遠不止時間上的來回：它還可以橋接電腦之間的物理距離，允許在一台機器上產生的結果被另一台機器重複使用。在團隊內導入建置快取時，典型的第一步是僅針對作為持續整合一部分執行的建置啟用它。使用共用的 HTTP 建置快取後端（例如 Develocity 提供的後端）可以顯著減少 CI 代理程式需要執行的工作。這轉化為開發人員更快的反饋，以及在 CI 資源上花費更少的資金。更快的建置也意味著每個建置中包含的提交更少，這使得偵錯問題更加有效率。

在 CI 上開始使用建置快取是一個很好的第一步，因為 CI 代理程式上的環境通常比開發人員機器更穩定和可預測。這有助於識別建置中可能影響快取能力的任何潛在問題。

如果您受到關於您交付給客戶的工件的稽核要求，您可能需要針對某些建置停用建置快取。Develocity 可以幫助您滿足這些要求，同時仍然為您的所有建置使用建置快取。它允許您透過建置掃描輕鬆找出哪個建置產生了來自建置快取的工件。

當多位開發人員在同一個專案上工作時，他們不僅需要建置自己的變更：每當他們從版本控制系統提取時，他們最終也必須建置彼此的變更。每當開發人員正在處理與提取的變更無關的內容時，他們可以安全地重複使用已在 CI 上產生的輸出。假設您正在處理模組「A」，並且您提取了對模組「B」的一些變更（該模組不依賴您的模組）。如果這些變更已在 CI 中建置，您可以從快取下載模組「B」的工作輸出，而不是在本地產生它們。一個典型的用途案例是當開發人員開始他們的一天，從版本控制系統提取所有變更，然後執行他們的第一個建置時。

變更也不需要完全獨立；我們將在關於不同形式的正規化的章節中查看在涉及相依性時重複使用結果的策略。

您可以同時利用本地快取和遠端快取以獲得複合效果。雖然從 CI 填充的遠端快取載入結果有助於避免由於其他開發人員的變更而需要的工作，但本地快取可以加速切換分支和執行 git bisect。在 CI 機器上，本地快取可以充當遠端快取的鏡像，顯著減少網路使用量。

允許開發人員將他們的結果上傳到共用快取是可能的，但不建議這樣做。開發人員可能會在工作執行時變更工作輸入或輸出。他們可能會在無意中且未注意到的情況下執行此操作，例如在建置執行時在他們的 IDE 中進行變更。目前，Gradle 沒有很好的方法來防禦這些變更，並且只會在工作完成後快取輸出目錄中的任何內容。這又可能導致損壞的結果被上傳到共用快取。當 Gradle 添加了必要的安全措施來防止意外修改工作輸入和輸出時，此建議可能會改變。