依附元件管理

翻閱先前的頁面時，有一個主題不斷重複：管理您自有的程式碼相當簡單，但管理其依附元件很變得更困難依附元件有很多種：有時候對特定工作的依賴 (例如「在將版本標示為版本前推送說明文件」有時也會有依附關係 (例如「我需要才能使用最新版的電腦視覺資料庫來建構程式碼」)。有時，您有程式碼集的另一部分有內部依附元件，且有時候，會對其他團隊擁有的程式碼或資料，造成外部依賴 (貴機構或第三方皆可)。但無論如何我必須先瞭解這點」，才能說是重複一次的。」以及管理依附元件是建構系統的基本工作

處理模組和依附元件

使用 Bazel 等構件型建構系統的專案會拆分成一組這些模組透過 BUILD 表示依附元件彼此檔案。妥善整理這些模組和依附元件對建構系統效能以及需要的工作量維護。

使用精細的模組和 1:1:1 規則

建構以構件為基礎的版本時，第一個想出的問題是決定個別模組應包含多少功能。在 Bazel 中模組是以指定可建構單元為目標， java_library 或 go_binary。例如，整項專案將一個 BUILD 檔案放在根目錄，然後以遞迴方式記錄專案的所有來源檔案。另一端不過，幾乎每個來源檔案都能加入各自的模組，有效要求每個檔案都列在 BUILD 檔案中，並依附於其他所有依附的檔案。

大多數專案介於這些極端之間在效能和可維護性之間取得平衡針對這可能表示您完全不需要輕觸 BUILD 檔案，但這意味著建構系統必須建議您一律同時建構整個專案也就是說平行處理或分配建構作業的各個部分預先建構完成每個檔案一個模組則相反：建構系統對建構在快取和排程步驟方面擁有最大的彈性，但因此工程師必須投入更多心力維護依附元件清單就會變更檔案參照

雖然確切的精細程度會因語言而異 ( 語言)，Google 傾向偏好小規模的模組，而非可能使用的字詞通常用於以任務為基礎的建構系統在實際工作環境中的一般實際工作環境二進位檔 Google 通常仰賴數萬個目標，甚至規模適中在程式碼集內可以擁有數百個目標對於像 Java 內建堅強的包裝概念，每個目錄通常包含一個套件、目標和 BUILD 檔案 (褲子、另一個建構系統) 並呼叫 1:1:1 規則)。包裝較弱的語言慣例通常會為每個 BUILD 檔案定義多個目標。

小型建構目標帶來的優勢確實會開始大規模顯示可以加快分散式建構作業的速度，並降低重新建構目標的頻率。測試輸入圖片後，優點更是更吸引人。目標越精細，建構系統就能變得更聰明只執行一部分可能受特定指定影響的測試變更。因為 Google 認為採用我們投注心力改善工具，自動管理 BUILD 檔案，避免開發人員感到負擔。

其中一些工具 (例如 buildifier 和 buildozer) 可透過執行 Bazel 作業的 buildtools 目錄。

最小化模組顯示設定

Bazel 和其他建構系統允許每個目標指定瀏覽權限。屬性來決定其他目標依附於該屬性。私人目標只能在自己的 BUILD 檔案中參照。設定目標可能會授權更廣泛的查看明確定義的 BUILD 檔案清單目標，或並將瀏覽權限設為「公開」至工作區中的每個目標

如同大部分的程式設計語言，一般來說，最好盡量減少能見度一般來說，只有在下列情況中，Google 團隊才會將目標設為公開：這些目標代表 Google 所有團隊都能使用的工具。團隊要求其他人協調使用程式碼前，維護客戶目標許可清單，以便監控客戶的成效。每項團隊的內部實作目標只能在目錄內由這個團隊所擁有，而大部分的 BUILD 個檔案只會有一個排除目標私人。

管理依附元件

模組必須能夠互相參照。將 Pod 名稱建構到精細模組中，藉此管理依附元件這些模組之間 (不過工具可以協助自動化這項作業)。傳達這些依附元件通常是由 BUILD 檔案中的大量內容組成。

內部依附元件

在大型專案中細分為精細模組，大部分的依附元件可能是內部資料；也就是部署於另一個目標上原始碼存放區內部依附元件與外部依附元件的而不是以預先建構的構件下載一併執行建構作業這也表示內部依附元件—目標及其所有內部依附元件一直都是以存放區的相同修訂版本/修訂版本為基礎建構而成您要解決的問題謹慎處理內部依附元件，也就是遞移依附元件 (圖 1)。假設目標 A 依附於目標 B，這取決於通用的程式庫目標 C。目標 A 應該可以使用類別目標 C 所定義？

圖 1. 遞移依附元件

如果對基礎工具有疑慮，這並沒有問題；兩者皆是建構時，B 和 C 會連結至目標 A，也就是說， C 則稱為 A。Bazel 已提供這樣的技術多年，但隨著 Google 的發展，開始出現問題假設 B 經過重構，使其不再出現並依附於 C 語言如果 B 對 C 的依附元件遭到移除，則 A 和任何其他透過 B 上的依附元件使用 C 的目標則會中斷。實際上，目標依附元件成為公開合約的一部分已變更。也就是說，Google 會持續累積依附元件

為瞭解決這個問題，Google 最終採用了「嚴格遞移性」依附元件模式」在此模式下，Bazel 會偵測目標是否嘗試沒有直接參照符號的符號，如果是的話，將無法使用錯誤和殼層指令，可用來自動插入依附元件將這項變更導入 Google 的整個程式碼集重構每個數百萬個建構目標，明確列出依附元件通常需要多年時間，但絕對值得。我們的版本提高目標的非必要依附元件數量工程師有權移除不必要的依附元件破壞依賴這些目標。

與往常一樣，強制執行嚴格的遞移依附元件也需要取捨。成果建立檔案較為精簡，因為現在必須將常用程式庫不會被迫進來，而是工程師需要花費更多心力在 BUILD 檔案中新增依附元件。我們並開發出可自動偵測並在沒有開發人員的情況下將依附元件新增至 BUILD 檔案或緩解措施但就算沒有這類工具，我們仍認為權衡利弊等同於程式碼集調度資源：在 BUILD 檔案中明確新增依附元件是一次性費用，但處理隱含的遞移依附元件可能會導致持續性問題，只要建構目標存在即可。Bazel 強制執行嚴格的遞移依附元件安裝在 Java 程式碼中

外部依附元件

如果依附元件不是內部，則該依附元件必須是外部項目。外部依附元件在建構系統外建構和儲存的構件上，產生相應的預測結果。依附元件是從構件存放區直接匯入 (通常是存取 )，並依原樣使用，而非從原始碼建構。下列其中一項外部和內部依附元件的最大差異外部依附元件有版本，且這些版本獨立存在即可。

自動與手動依附元件管理

建構系統可允許管理外部依附元件的版本手動或自動如果是手動管理時，建構檔明確列出要從構件存放區下載的版本經常使用語意版本字串使用 1.1.4。如果自動管理，來源檔案會指定且建構系統會一律下載最新版本。適用對象例如，Gradle 允許將依附元件版本宣告為「1.+」可接受任何次要或修補程式版本，只要主要版本為 1

自動代管的依附元件對於小型專案是便捷的，但往往是一種災難因應做法，目前是由多位工程師合作自動指出的問題這表示您無法控管 YAML 檔案已更新。目前沒有任何方法能確保外部方不會造成破壞更新 (即使他們聲稱使用語意版本管理)，因此建構隔天工作可能會分崩離析或復原為工作狀態即使建構作業並未中斷可能是無法追蹤的細微行為或成效變化。

相對的，因為手動管理的依附元件需要變更來源所以您可以輕鬆尋找、復原查看舊版存放區，使用較舊的依附元件進行建構。 Bazel 規定所有依附元件的版本都必須手動指定。甚至中等規模，則手動版本管理的負擔非常值得確保穩定性

單一版本規則

不同的程式庫版本通常以不同的構件表示理論上來說無法在建構系統中以不同名稱宣告依附元件。如此一來，每個目標就能選擇想要的依附元件版本相關單位會如何運用資料，並讓他們覺得自己獲得充分告知，且能夠針對該使用方式表示同意這麼做會造成許多實務問題，因此 Google 嚴格執行相關政策單一版本規則用於程式碼集中的所有第三方依附元件

要允許多個版本的最大問題在於鑽石依賴性問題。假設目標 A 依附於目標 B 和外部 v1 資源庫。如果目標 B 之後遭到重構，以便在 V2 版本相同的 v2 中新增依附元件目標 A 將會破壞，因為現在其隱含仰賴兩個同一個程式庫的不同版本而且，新增將新的依附元件從目標轉移到擁有多個版本的第三方程式庫因為該目標的使用者可能取決於版本。遵循一版規則會導致無法發生衝突 (假設目標新增一個對第三方程式庫的依附元件，以及任何現有的依附元件全都位於相同版本，因此大家可以快樂共存。

遞移外部依附元件

處理外部依附元件的遞移依附元件可能包括就特別困難Maven Central 等許多構件存放區藉此指定雲端中其他構件特定版本的依附元件存放區Maven 或 Gradle 等建構工具通常會以遞迴方式下載預設遞移依附元件，意味著在可能會導致大量下載構件。

這種做法可說是非常方便：在新的程式庫中新增依附元件時必須逐一追蹤程式庫的遞移依附元件並手動新增也有一大缺點：程式庫可以依附同一個第三方程式庫的不同版本，策略一定違反一版規則，而且會導向鑽石級依附元件問題如果您的目標仰賴使用同一依附元件的不同版本，系統不會告訴您 get。這也表示更新外部依附元件如果新版本開始提取，則整個程式碼集中發生不相關的失敗錯誤某些依附元件的衝突版本

因此，Bazel 不會自動下載遞移依附元件。可惜的是，這沒有萬事通 — Bazel 的替代方案是列出存放區外部每一個外部的單一檔案整個依附元件中使用的依附元件和明確版本 Cloud Storage 也提供目錄同步處理功能幸好，Bazel 提供的工具能夠自動產生這類檔案，當中包含一組 Maven 的遞移依附元件導致學習失真性這項工具可讓您執行一次，以產生初始 WORKSPACE 檔案您就能手動更新該檔案來調整版本每個依附元件的結構中

當然，這裡的選擇是便利性和擴充性之間的考量。S 號因此，專案可能不需費心管理遞移依附元件並可能利用自動遞移性推動依附元件隨著機構規模變革，這項策略越來越缺乏吸引力隨著程式碼集不斷擴增衝突和非預期的結果也變得越來越豐富。採用更大規模的架構時，手動管理依附元件的成本大不相同低於自動依附元件導致的問題處理成本以自動化做法管理成本

使用外部依附元件快取建構結果

外部依附元件通常是由第三方提供穩定版的程式庫，可能不需要提供原始碼。只有部分通知機構也可能會選擇使用自己的程式碼可讓其他程式碼片段依附於第三方比內部依附元件多出理論上來說，如果構件是構件，即可加快建構作業的執行速度但下載速度較慢

然而，這也會產生許多負擔和複雜性：必須有人建構這些構件並上傳至構件存放區，以及用戶端必須最新版本。此外，偵錯作業也更加困難系統元件的運作原理是且不再為原始碼樹狀結構提供一致的檢視。

想要解決長時間建構的構件問題如前所述，使用支援遠端快取的建構系統。如此建構系統會將每次建構作業產生的構件儲存至位置因此，如果開發人員依賴模型會自動下載不必實際建構如此一來，您就能享有同時確保建構作業就像一律從相同來源建構一樣這是而 Bazel 也可設為使用遠端指令快取。

外部依附元件的安全性和穩定性

根據第三方來源的構件，可能會有風險。還有第三方來源 (例如構件存放區) 出現可用性風險如果無法下載，整個版本可能會停滯不前外部依附元件可能會有安全風險：若第三方系統完全被攻擊者入侵，攻擊者就可以可加入自行設計的構件融入建構作業這兩個問題都可以透過鏡像方式取決於您可以控管及禁止建構系統存取的伺服器第三方構件存放區，例如 Maven Central缺點就是建構這類架構需要耗費大量心力和資源維護，因此選擇是否使用時，資源往往會因專案規模而異。此外，安全性問題也藉由要求每個 Pod 的雜湊值來源存放區中指定的第三方構件導致建構作業就會失敗。另一種完全的替代方案而問題是廠商專案的依附元件。專案容器會整合所有依附元件和專案原始碼或二進位檔。這實際上意味著專案的所有外部依附元件都會轉換為內部依附元件依附元件Google 內部會使用這種做法，檢查每個第三方整個 Google 參照的程式庫，並編入根目錄的 third_party 目錄中這個開放原始碼專案的主要工具不過，這個做法只適用於 Google 經過特別設計的原始碼控管系統能處理極大型的單聲道存放區部分機構可能無法選擇供應商。