翻閱先前的頁面時，有一個主題不斷重複： 管理 您自有的程式碼相當簡單，但管理其依附元件很 變得更困難依附元件有很多種：有時候 對特定工作的依賴 (例如「在將版本標示為版本前推送說明文件」 有時也會有依附關係 (例如「我需要 才能使用最新版的電腦視覺資料庫來建構程式碼」)。 有時，您有程式碼集的另一部分有內部依附元件，且 有時候，會對其他團隊擁有的程式碼或資料，造成外部依賴 (貴機構或第三方皆可)。但無論如何，「我需要那個東西才能擁有這個」的概念會不斷重複出現在建構系統的設計中，而管理依附元件可能是建構系統最基本的任務。
處理模組和依附元件
使用 Bazel 等構件型建構系統的專案會拆分成一組
模組，以及透過 BUILD 表示依附元件的模組
檔案。妥善安排這些模組和依附元件，可大幅影響建構系統的效能，以及維護所需的工作量。
使用精細的模組和 1:1:1 規則
在建構以構件為基礎的版本時，首先要決定個別模組應包含多少功能。在 Bazel 中
模組是以指定可建構單元為目標，
java_library 或 go_binary。例如，整項專案
將一個 BUILD 檔案放在根目錄，然後
以遞迴方式記錄專案的所有來源檔案。另一端
不過，幾乎每個來源檔案都能加入各自的模組，有效
要求每個檔案都列在 BUILD 檔案中，並依附於其他所有依附的檔案。
大多數專案都介於這兩個極端之間，因此選擇時必須在效能和可維護性之間取得平衡。為整個專案使用單一模組，可能表示您除了新增外部依附元件時，不需要再碰觸 BUILD 檔案，但這也表示建構系統必須一律一次建構整個專案。這表示它無法並行處理或分發建構作業的部分，也無法快取已建構的部分。每個檔案一個模組則相反：建構系統
對建構在快取和排程步驟方面擁有最大的彈性，但
因此工程師必須投入更多心力維護依附元件清單
就會變更檔案參照
雖然精確的精細程度因語言而異 (甚至在同一種語言內也可能不同)，但 Google 傾向於採用比以任務為基礎的建構系統中通常編寫的模組更小得多的模組。在實際工作環境中的一般實際工作環境二進位檔
Google 通常仰賴數萬個目標，甚至規模適中
在程式碼集內可以擁有數百個目標對於 Java 等具有強大內建封裝概念的語言，每個目錄通常都包含單一套件、目標和 BUILD 檔案 (Pants 是另一個以 Bazel 為基礎的建構系統，稱此為 1:1:1 規則)。包裝較弱的語言
慣例通常會為每個 BUILD 檔案定義多個目標。
較小的建構目標帶來的好處會在規模上開始顯現，因為這類目標可加快分散式建構作業，且不需經常重建目標。測試輸入圖片後，優點更是更吸引人。
目標越精細，建構系統就能變得更聰明
只執行一部分可能受特定指定影響的測試
變更。Google 相信使用較小目標可帶來系統性效益，因此我們已投資開發工具來自動管理 BUILD 檔案，以免造成開發人員負擔，並在一定程度上減輕了使用較小目標的缺點。
其中一些工具 (例如 buildifier 和 buildozer) 可透過
執行 Bazel 作業的
buildtools 目錄。
盡量減少模組可見度
Bazel 和其他建構系統允許每個目標指定瀏覽權限。
屬性來決定其他目標依附於該屬性。私人目標只能在其自己的 BUILD 檔案中參照。目標可以將更廣泛的瀏覽權限授予明確定義的 BUILD 檔案清單目標，或是在公開瀏覽權限的情況下，將瀏覽權限授予工作區中的每個目標。
如同大部分的程式設計語言，一般來說，最好盡量減少能見度
一般來說，只有在下列情況中，Google 團隊才會將目標設為公開：
這些目標代表了 Google 所有團隊廣泛使用的程式庫。
團隊要求其他團隊協調，才能使用他們的程式碼，
維護客戶目標許可清單，以便監控客戶的成效。每個團隊的內部實作目標都會受到限制，只能是團隊擁有的目錄，而且大多數 BUILD 檔案都只有一個非私密的目標。
管理依附元件
模組必須能夠彼此參照。將程式碼集區分割成精細的模組的缺點是，您需要管理這些模組之間的依附元件 (雖然工具可協助自動化這項作業)。傳達這些
依附元件通常是由 BUILD 檔案中的大量內容組成。
內部依附元件
在大型專案中，如果已細分為精細的模組，則大多數依附元件可能為內部依附元件，也就是在相同來源存放區中定義及建構的其他目標。內部依附元件與外部依附元件的差異在於，內部依附元件是從來源建構而成，而非在執行建構作業時以預先建構的構件形式下載。這也表示內部依附元件沒有「版本」的概念，也就是說，目標和所有內部依附元件一律會在存放區的相同提交/修訂版本中建構。您要解決的問題 謹慎處理內部依附元件，也就是 遞移依附元件 (圖 1)。假設目標 A 依附於目標 B，而目標 B 依附於共用程式庫目標 C。目標 A 應該可以使用類別 目標 C 所定義？
圖 1. 遞移依附元件
如果對基礎工具有疑慮，這並沒有問題；兩者皆是 建構時，B 和 C 會連結至目標 A，也就是說， A 是 A 這個名詞。Bazel 允許這麼做多年，但隨著 Google 的成長，我們開始發現問題。假設 B 已重構，因此不再需要依附 C。如果 B 對 C 的依附元件遭到移除，則 A 和任何其他 透過 B 上的依附元件使用 C 的目標則會中斷。因此，目標的依附元件實際上已成為其公開合約的一部分，無法安全地變更。也就是說，Google 會持續累積依附元件
Google 最終在 Bazel 中導入「嚴格傳遞依附元件模式」，解決了這個問題。在這個模式中，Bazel 會偵測目標是否會嘗試參照符號，但未直接依附該符號，如果是的話，就會失敗並顯示錯誤，以及可用來自動插入依附元件的殼層指令。將這項變更導入 Google 的整個程式碼集 重構每個數百萬個建構目標，明確列出 依附元件通常需要多年時間，但絕對值得。由於目標的非必要依附元件減少，因此我們的建構作業現在速度快得多，工程師也能移除不需要的依附元件，而不必擔心會破壞依附於這些依附元件的目標。
如往常，強制執行嚴格的遞移依附元件會涉及權衡。這會使建構檔案變得冗長，因為現在需要在許多位置明確列出常用的程式庫，而不是隨機擷取，而工程師需要花費更多心力在 BUILD 檔案中新增依附元件。我們開發了可自動偵測許多缺少的依附元件，並在不需要開發人員介入的情況下將其加入 BUILD 檔案的工具，藉此減少這項工作所需的勞力。不過，即使沒有這類工具，我們發現在程式碼庫擴充時，權衡利弊還是值得的：明確新增依附元件至 BUILD 檔案是一次性成本，但處理隱含的傳遞依附元件可能會導致持續性問題，只要建構目標存在，就會發生這種問題。根據預設，Bazel 會在 Java 程式碼上強制執行嚴格的間接依附元件。
外部依附元件
如果依附元件不是內部，則該依附元件必須是外部項目。外部依附元件是指在建構系統外建構及儲存的構件。依附元件會直接從構件存放區 (通常透過網際網路存取) 匯入，並且會原封不動地使用，而非從原始碼建構。下列其中一項 外部和內部依附元件的最大差異 外部依附元件有版本，且這些版本獨立存在 即可。
自動與手動依附元件管理
建構系統可允許管理外部依附元件的版本
手動或自動手動管理時，建構檔案會明確列出要從構件存放區下載的版本，通常會使用 1.1.4 等語意版本字串。如果自動管理，來源檔案會指定
且建構系統會一律下載最新版本。適用對象
例如，Gradle 允許將依附元件版本宣告為「1.+」
可接受任何次要或修補版本的依附元件，只要
主要版本為 1
自動管理的依附元件對小型專案來說相當方便，但對於規模較大或由多位工程師共同處理的專案，這類依附元件通常會造成災難。自動指出的問題 這表示您無法控管 YAML 檔案 已更新。我們無法保證外部廠商不會發布重大更新 (即使他們聲稱會使用語意版本)，因此某天可用的版本可能在下次更新後無法運作，而且我們無法輕易偵測變更內容或將版本回溯至可運作狀態。即使建構作業沒有中斷，也可能發生難以追蹤的細微行為或效能變更。
相較之下，由於手動管理的依附元件需要變更來源控管，因此可以輕鬆發現及還原，而且可以檢查較舊版本的存放區，以便使用較舊的依附元件進行建構。Bazel 要求您手動指定所有依附元件的版本。甚至 中等規模，則手動版本管理的負擔非常值得 確保穩定性
單一版本規則
不同的程式庫版本通常以不同的構件表示 理論上來說 無法在建構系統中以不同名稱宣告依附元件。 如此一來，每個目標就能選擇想要的依附元件版本 相關單位會如何運用資料，並讓他們覺得自己 獲得充分告知，且能夠針對該使用方式表示同意這會造成許多實務問題，因此 Google 會嚴格執行相關政策 單一版本規則 用於程式碼集中的所有第三方依附元件
要允許多個版本的最大問題在於鑽石依賴性 問題。假設目標 A 依附於目標 B 和外部第 1 版 資源庫。如果目標 B 之後經過重構，以便在 v2 上新增依附元件 目標 A 將會破壞，因為現在其隱含仰賴兩個 同一個程式庫的不同版本從目標新增依附元件至具有多個版本的任何第三方程式庫，從實務角度來看，這絕非安全的做法，因為目標的任何使用者都可能已依附於其他版本。遵循「單一版本規則」可避免發生這種衝突，如果目標在第三方程式庫中新增依附元件，任何現有的依附元件都會位於該版本，因此可以順利共存。
遞移外部依附元件
處理外部依附元件的遞移依附元件可能包括 就特別困難許多構件存放區 (例如 Maven Central) 都允許構件指定存放區中其他構件的特定版本依附元件。根據預設，Maven 或 Gradle 等建構工具通常會遞迴下載每個傳遞依附元件，也就是說，在專案中新增單一依附元件可能會導致總共下載數十個構件。
這種做法可說是非常方便：在新的程式庫中新增依附元件時 必須逐一追蹤程式庫的遞移依附元件 並手動新增但這也有很大的缺點：由於不同程式庫可能會依附相同第三方程式庫的不同版本，因此這種做法必然違反「一個版本」規則，並導致菱形依附元件問題。如果目標依附元件會使用相同依附元件的不同版本，您就無法得知會取得哪個版本。這也表示更新外部依附元件 如果新版本開始提取，則整個程式碼集中發生不相關的失敗錯誤 某些依附元件的衝突版本
因此，Bazel 不會自動下載傳遞依附元件。可惜的是，這沒有萬事通 — Bazel 的替代方案是
列出存放區外部每一個外部的單一檔案
整個依附元件中用於該依附元件的明確版本
Cloud Storage 也提供目錄同步處理功能幸好，Bazel 提供的工具可自動產生這類檔案，其中包含一組 Maven 構件間接依附元件。您可以執行這項工具一次，為專案產生初始 WORKSPACE 檔案，然後手動更新該檔案，以調整各依附元件的版本。
這裡的選擇又是便利性和可擴充性之間的抉擇。S 號 因此，專案可能不需費心管理遞移依附元件 並可能利用自動遞移性推動 依附元件隨著機構規模變革，這項策略越來越缺乏吸引力 隨著程式碼集不斷擴增 衝突和非預期的結果也變得越來越豐富 在更大規模的情況下，手動管理依附元件的成本遠低於處理自動依附元件管理功能所造成的問題的成本。
使用外部依附元件快取建構結果
外部依附元件通常是由第三方提供 穩定版的程式庫，可能不需要提供原始碼。只有部分通知 機構也可能會選擇使用自己的程式碼 可讓其他程式碼片段依附於第三方 比內部依附元件多出如果構件建構速度較慢，但下載速度較快，這項做法理論上可加快建構速度。
然而，這也會產生許多負擔和複雜性：必須有人 建構這些構件並上傳至 構件存放區，以及用戶端必須 最新版本。此外，偵錯作業也更加困難 系統元件的結構，是來自於 且不再為原始碼樹狀結構提供一致的檢視。
想要解決長時間建構的構件問題 如同前文所述，使用支援遠端快取的建構系統。如此 建構系統會將每次建構作業產生的構件儲存至位置 因此，如果開發人員依賴 模型會自動下載 不必實際建構這可提供直接依附成果物所帶來的所有效能優勢，同時確保建構作業與從相同來源建構的作業一樣一致。這是 而 Bazel 也可設為使用遠端指令 快取。
外部依附元件的安全性和可靠性
依賴第三方來源的構件本身就存在風險。如果第三方來源 (例如構件存放區) 發生異常，就會造成可用性風險，因為如果整個建構作業無法下載外部依附元件，可能會停滯不前。可能會有安全風險：若第三方系統
完全被攻擊者入侵，攻擊者就可以
可加入自行設計的構件
融入建構作業您可以將任何依附元件複製到您控管的伺服器，並阻止建構系統存取 Maven Central 等第三方構件存放區，藉此緩解這兩個問題。但這些鏡像需要花費心力和資源來維護，因此是否使用鏡像，通常取決於專案規模。您也可以要求在原始碼存放區中指定每個第三方構件的雜湊，藉此完全避免安全性問題，且不必付出太多成本，因為如果構件遭到竄改，這麼做就會導致建構作業失敗。另一種完全的替代方案
而問題是廠商專案的依附元件。當專案供應商提供其依附元件時，會將依附元件與專案的原始碼一起納入原始碼控制，以原始碼或二進位檔的形式。這實際上意味著
專案的所有外部依附元件都會轉換為內部依附元件
依附元件Google 內部會使用這種做法，檢查每個第三方
整個 Google 參照的程式庫，並編入根目錄的 third_party 目錄中
這個開放原始碼專案的主要工具不過，這種做法只適用於 Google，因為 Google 的來源控管系統是專門用於處理極大型單一存放區，因此供應商可能不是所有機構的選項。