本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Architecture：程式碼組織
這是 SIG Architecture Spotlight 系列的第三次訪談，將涵蓋不同的子專案。我們將介紹 SIG Architecture: 程式碼組織。
在這次 SIG Architecture 聚焦中，我與程式碼組織子專案的成員 Madhav Jivrajani (VMware) 進行了交談。
程式碼組織子專案簡介
Frederico (FSM)：你好，Madhav，感謝你抽出時間。你能先簡單介紹一下你自己、你的角色以及你是如何參與到 Kubernetes 中的嗎？
Madhav Jivrajani (MJ)：你好！我叫 Madhav Jivrajani，我是 SIG Contributor Experience 的技術負責人，也是 Kubernetes 專案的 GitHub 管理員。除此之外，我還為 SIG API Machinery 和 SIG Etcd 做貢獻，但最近，我一直在幫助 Kubernetes 保持在受支援的 Go 版本上所需的工作，也正是透過這項工作，我參與了 SIG Architecture 的程式碼組織子專案。
FSM：像 Kubernetes 這麼大規模的專案，在程式碼組織方面肯定面臨獨特的挑戰——這個假設合理嗎？如果合理，你認為 Kubernetes 特有的主要挑戰有哪些？
MJ：這個假設很合理！第一個有趣的挑戰來自 Kubernetes 程式碼庫的龐大規模。我們有大約 220 萬行 Go 程式碼（感謝 dims 和這個子專案的其他同仁，這個數字正在穩步減少！），以及我們直接或間接依賴的 240 多個依賴項。這就是為什麼需要一個專門的子專案來幫助進行依賴管理：我們需要知道我們引入了哪些依賴項，這些依賴項的版本是什麼，以及需要工具來幫助確保我們在程式碼庫的不同部分以一致的方式管理這些依賴項。
Kubernetes 的另一個有趣挑戰是，我們作為 Kubernetes 釋出週期的一部分發布了許多 Go 模組，其中一個例子是 client-go。然而，我們作為一個專案也希望享受到將所有東西都放在一個倉庫中的好處，以獲得使用單一倉庫（monorepo）的優勢，比如原子提交……所以，因此，程式碼組織與其他 SIG（如 SIG Release）合作，自動化將程式碼從單一倉庫釋出到下游各個倉庫的過程，這些倉庫更容易被消費，這樣你就不必匯入整個 Kubernetes 程式碼庫了！
程式碼組織與 Kubernetes
FSM：對於剛開始為 Kubernetes 貢獻程式碼的人來說，在程式碼組織方面，他們應該考慮的主要事項是什麼？你會如何總結關鍵概念？
MJ：我認為，至少在你剛開始時，要記住的一個關鍵概念是 staging 目錄。在 kubernetes/kubernetes 倉庫中，你會遇到一個名為 staging/ 的目錄。這個目錄中的子資料夾充當了一系列偽倉庫。例如，釋出 client-go 版本的 kubernetes/client-go 倉庫實際上是一個 staging 倉庫。
FSM：所以 staging 目錄的概念從根本上影響了貢獻？
MJ：沒錯，因為如果你想為任何 staging 倉庫做貢獻，你需要向 kubernetes/kubernetes 中相應的 staging 目錄提交一個 PR。一旦程式碼合併到那裡，我們有一個名為 publishing-bot 的機器人，它會將合併的提交同步到所需的 staging 倉庫（如 kubernetes/client-go）。這樣我們既能獲得單一倉庫的好處，又能模組化地釋出程式碼供下游消費。附註：publishing-bot 需要更多人來幫忙！
有關 staging 倉庫的更多資訊，請參閱貢獻者文件。
FSM：說到貢獻，大量的貢獻者，包括個人和公司，肯定也是一個挑戰：子專案如何運作以確保標準得到遵守？
MJ：當涉及到專案中的依賴管理時，有一個專門的團隊來幫助審查和批准依賴項變更。這些人為 Kubernetes 今天用於依賴管理的許多工具奠定了基礎。這些工具有助於確保貢獻者能夠以一致的方式對依賴項進行更改。該專案還開發了額外的工具來顯示正在新增或刪除的依賴項的統計資訊：depstat。
除了依賴管理，該專案做的另一項關鍵任務是管理 staging 倉庫。實現這一點的工具（publishing-bot）對貢獻者是完全透明的，並有助於確保 staging 倉庫獲得提交到 kubernetes/kubernetes 的貢獻的一致檢視。
程式碼組織還致力於確保 Kubernetes 保持在受支援的 Go 版本上。連結的 KEP 提供了更多關於我們為什麼需要這樣做的背景資訊。我們與 SIG Release 合作，以確保我們儘可能早、儘可能嚴格地在 Go 版本上測試 Kubernetes，並處理作為這項工作一部分破壞我們 CI 的變更。我們如何跟蹤這個過程的一個例子可以在這裡找到。
釋出週期和當前優先順序
FSM：在釋出週期中有什麼變化嗎？
MJ：在釋出週期中，特別是在程式碼凍結之前，通常會有一些變更，這些變更會新增/更新/刪除依賴項，修復作為我們保持在受支援的 Go 版本上工作的一部分需要修復的程式碼。
此外，其中一些變更也是我們支援的釋出分支的向後移植的候選者。
FSM：子專案目前是否有正在進行的主要專案或主題，你想要特別強調的？
MJ：我認為最近新增的一個非常有趣且非常有用的變更是（我藉此機會特別強調 Tim Hockin 在這方面的工作）在 Kubernetes 倉庫中引入 Go 工作區。我們目前用於依賴管理和程式碼釋出的許多工具，以及在 Kubernetes 倉庫中編輯程式碼的體驗，都可以透過這一變更得到顯著改善。
總結
FSM：對這個主題感興趣的人如何開始幫助這個子專案？
MJ：第一步，就像在 Kubernetes 中的任何專案一樣，是加入我們的 Slack：slack.k8s.io，然後加入 #k8s-code-organization 頻道。還有一個程式碼組織辦公時間，你可以選擇參加。時區是個難題，所以你也可以隨時檢視錄音或會議記錄，並在 Slack 上跟進！
FSM：太好了，謝謝你！你還有什麼最後的評論想分享嗎？
MJ：程式碼組織子專案總是需要幫助！特別是在像 publishing bot 這樣的領域，所以不要猶豫，在 #k8s-code-organization Slack 頻道中參與進來。