建置快取的用例

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

在處理有多個變異的專案時，例如 Android 專案，本機快取也可能很有用。每個變異都有一些與之關聯的任務，而這些任務變異維度中有些儘管名稱不同，但最終可能會產生相同的輸出。啟用本機快取後，在適用的情況下，任務變異之間的重複使用會自動進行。

建置快取的功能不只於在時間中來回移動：它還能跨越電腦之間的物理距離，允許在一部機器上產生的結果被另一部機器重複使用。在團隊中導入建置快取時，典型的第一步是僅針對作為「持續整合」一部分執行的建置啟用它。使用共用 HTTP 建置快取後端（例如 Develocity 提供的後端）可以大幅減少 CI 代理需要執行的作業。這表示開發人員可以獲得更快的回饋，並減少花費在 CI 資源上的費用。建置速度加快也表示每個建置中包含的提交較少，這使得除錯問題更有效率。

從 CI 上的建置快取開始是一個良好的第一步，因為 CI 代理程式上的環境通常比開發人員電腦更穩定且可預測。這有助於識別建置中任何可能影響快取性的問題。

如果您受到有關運送給客戶的成品稽核要求的約束，您可能需要針對特定建置停用建置快取。Develocity 可以協助您滿足這些要求，同時仍對所有建置使用建置快取。它讓您可以透過建置掃描輕鬆找出哪個建置產生來自建置快取的成品。

當多位開發人員處理同一個專案時，他們不只要建置自己的變更：每當他們從版本控制中提取時，他們最終也必須建置彼此的變更。每當開發人員處理獨立於提取變更的事項時，他們可以安全地重複使用已在 CI 上產生的輸出。比方說，您正在處理模組「A」，而您提取一些變更到模組「B」（它不依賴於您的模組）。如果這些變更已在 CI 中建置，您可以從快取下載模組「B」的任務輸出，而不是在本地產生它們。這項功能的典型使用案例是開發人員開始他們的一天，從版本控制中提取所有變更，然後執行他們的第一次建置。

這些變更也不需要完全獨立；我們將在關於 不同形式的正規化 的部分中探討涉及相依性的結果重複使用策略。

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

允許開發人員將他們的結果上傳到共用快取是可行的，但不建議這麼做。開發人員可以在任務執行時變更任務輸入或輸出。他們可以無意間且在不知不覺中執行此動作，例如在建置執行時在他們的 IDE 中進行變更。目前，Gradle 沒有良好的方法來防範這些變更，而且一旦任務完成，它只會快取輸出目錄中的任何內容。這可能會導致損毀的結果上傳到共用快取。當 Gradle 加入必要的防護措施來防範任務輸入和輸出的無意修改時，此建議可能會有所變更。