聚焦 SIG Release（釋出團隊子專案）

釋出特別興趣小組（SIG Release），Kubernetes 在這裡每 4 個月就會推出尖端功能和錯誤修復。你有沒有想過，像 Kubernetes 這樣的大型專案是如何如此高效地管理其時間線來發布新版本的，或者釋出團隊的內部運作是怎樣的？如果你對這些問題感到好奇，或者想了解更多並參與 SIG Release 的工作，請繼續閱讀！

SIG Release 在 Kubernetes 的發展和演進中扮演著至關重要的角色。其主要職責是管理 Kubernetes 新版本的釋出過程。它以固定的釋出週期運作，通常是每三到四個月一次。在此週期中，Kubernetes 釋出團隊與其他 SIG 和貢獻者密切合作，以確保釋出過程順利且協調一致。這包括規劃釋出時間表、設定程式碼凍結和測試階段的截止日期，以及建立釋出產物，如二進位制檔案、文件和釋出說明。

在您進一步閱讀之前，需要注意的是，SIG Release 下有兩個子專案——**釋出工程（Release Engineering）**和**釋出團隊（Release Team）**。

在這篇博文中，Nitish Kumar 採訪了 SIG Release 的技術負責人 Verónica López (PlanetScale)，重點介紹了釋出團隊子專案、釋出流程是怎樣的，以及參與方式。

1. 一個新版 Kubernetes 的典型釋出流程是怎樣的，從最初的規劃到最終的釋出？你們是否使用任何特定的方法和工具來確保釋出順利進行？

   新 Kubernetes 版本的釋出過程是一個結構良好且由社群驅動的努力。我們沒有遵循特定的方法或工具，只有一個包含一系列步驟的日曆來保持一切井然有序。完整的釋出過程如下：

• 釋出團隊組建： 我們首先組建一個釋出團隊，其中包括來自 Kubernetes 社群的志願者，他們將負責管理新版本的不同部分。這通常在上一個版本即將結束時完成。團隊組建後，新成員將進行入職培訓，而釋出團隊負責人和分支管理員會為通常的交付物提出一個日曆。例如，你可以看看在 SIG Release 倉庫中建立的 v1.29 團隊組建 issue。貢獻者要成為釋出團隊的一員，通常需要透過“釋出見習（Release Shadow）”計劃，但這並不是參與 SIG Release 的唯一途徑。

• 起始階段： 在每個釋出週期的最初幾周，SIG Release 會認真跟蹤 Kubernetes 增強提案（KEP）中概述的新特性和增強功能的進展。雖然並非所有這些特性都是全新的，但它們通常從 alpha 階段開始，隨後進入 beta 階段，最終達到穩定狀態。

• 特性成熟階段： 我們通常會發布幾個 Alpha 版本，其中包含處於實驗狀態的新特性，以收集社群的反饋，隨後是幾個 Beta 版本，此時特性更加穩定，重點是修復錯誤。使用者的反饋在這個階段至關重要，有時我們甚至需要釋出一個額外的 Beta 版本來解決在此階段可能出現的錯誤或其他問題。一旦這些問題解決，我們會在正式釋出前釋出一個**釋出候選版（release candidate, RC）**。在整個週期中，我們都會努力更新和改進文件，包括髮布說明和使用者指南，我認為這個過程值得單獨寫一篇文章來介紹。

• 穩定階段： 在新版本釋出前幾周，我們會實施**程式碼凍結（code freeze）**，此後不允許再新增新功能：這使得重點可以轉移到測試和穩定上。與主版本釋出並行，我們還會繼續為舊的、官方支援的 Kubernetes 版本釋出月度補丁，所以你可以說一個 Kubernetes 版本的生命週期會在此後延長好幾個月。在整個釋出週期中，我們會努力更新和改進文件，包括髮布說明和使用者指南，我們認為這個過程值得單獨寫一篇文章來介紹。

  

2. 你們如何在每個版本中平衡穩定性和引入新功能？用什麼標準來決定哪些功能可以進入一個版本？

   這是一個永無止境的任務，但我們認為關鍵在於遵守我們的流程和準則。我們的準則是社群數十名成員經過數小時討論和反饋的結果，他們為專案帶來了豐富的知識和經驗。如果我們沒有嚴格的準則，我們就會一遍又一遍地進行同樣的討論，而不是把時間用在需要我們關注的更有成效的話題上。所有關鍵的例外情況都需要大多數團隊成員的共識，這樣我們才能保證質量。

   決定哪些內容可以進入一個版本的流程，早在釋出團隊接手工作流程之前就開始了。每個獨立的 SIG 以及最有經驗的貢獻者可以決定他們是否要包含某個功能或變更，所以規劃和最終批准通常屬於他們。然後，釋出團隊會確保這些貢獻在文件、測試、向後相容性等方面滿足要求，之後才正式允許它們進入。每月補丁釋出的 cherry-pick 過程也類似，我們有嚴格的政策，不接受需要完整 KEP 的 PR，或者不包含所有受影響分支的修復。

3. 在開發和釋出 Kubernetes 的過程中，你們遇到的最重大的挑戰有哪些？你們是如何克服這些挑戰的？

   每個釋出週期都會帶來各自的挑戰。這可能包括處理最後一刻的問題，如新發現的常見漏洞和暴露（CVE）、解決我們內部工具中的錯誤，或處理由先前版本的功能引起的意外迴歸。我們經常面臨的另一個障礙是，儘管我們的團隊規模龐大，但我們中的大多數人都是以志願者身份貢獻的。有時會感覺我們有點人手不足，但我們總能設法組織起來並使其運轉。

4. 作為一名新的貢獻者，我參與 SIG Release 的理想路徑應該是什麼？在一個每個人都忙於自己任務的社群裡，我如何找到合適的任務來有效地做出貢獻？

   每個人參與開源社群的方式都不同。SIG Release 是一個自給自足的團隊，這意味著我們編寫自己的工具來發布版本。我們與其他 SIG（例如 SIG K8s Infra）有很多合作，但我們使用的所有工具都需要為我們龐大的技術需求量身定做，同時降低成本。這意味著我們一直在尋找願意幫助各種型別專案的志願者，而不僅僅是“釋出一個版本”。

   我們當前的專案需要多種技能的組合，例如 Go 程式設計、理解 Kubernetes 內部原理、Linux 打包、供應鏈安全、技術寫作和常規的開源專案維護。隨著我們專案的發展，這個技能集也在不斷演變。

   對於一條理想的路徑，我們建議如下：

   • 熟悉程式碼，包括功能如何管理、釋出日曆以及釋出團隊的整體結構。
   • 加入 Kubernetes 社群的溝通渠道，例如 Slack 上的 #sig-release 頻道，我們在這裡特別活躍。
   • 參加SIG Release 的每週會議，這些會議對社群中的所有人開放。參加這些會議是瞭解正在進行和未來專案的好方法，你可能會發現這些專案與你的技能和興趣相關。

   請記住，每一位有經驗的貢獻者都曾和你一樣是新手，社群通常非常願意指導和支援新人。不要猶豫，大膽提問、參與討論，並從小處著手貢獻。

5. 什麼是“釋出見習計劃”（Release Shadow Program），它與其他各種 SIG 中的見習計劃有何不同？

   釋出見習計劃為感興趣的個人提供了一個機會，讓他們在整個 Kubernetes 釋出週期中跟隨經驗豐富的釋出團隊成員學習。這是一個獨特的機會，可以看到一個 Kubernetes 版本在各個子團隊中需要付出的所有辛勤工作。很多人認為我們所做的只是每三個月釋出一個版本，但這只是冰山一角。

   我們的計劃通常與特定的 Kubernetes 釋出週期保持一致，該週期有大約三個月的可預測時間線。雖然這個計劃不涉及編寫新的 Kubernetes 功能，但它仍然需要高度的責任感，因為釋出團隊是新版本與數千名貢獻者之間的最後一道關卡，所以這是一個以加速的步伐學習現代軟體開發週期的絕佳機會。

6. 對於下一個 Kubernetes 版本的釋出見習生/釋出負責人，你們通常會看重申請者的哪些資質？

   雖然所有角色都需要一定程度的技術能力，但有些角色需要更多的 Go 語言實踐經驗和對 Kubernetes API 的熟悉度，而另一些角色則需要能夠以清晰簡潔的方式傳達技術內容的人。需要強調的是，我們更看重熱情和承諾，而不是從第一天就具備的技術專長。如果你有正確的態度，並向我們展示你喜歡與 Kubernetes 和/或釋出工程打交道，即使只是透過你在業餘時間完成的個人專案，團隊也會確保指導你。在我們團隊中，成為一個自我驅動者並且不害怕提問，可以讓你走得很遠。

7. 對於多次申請釋出見習計劃被拒的人，你有什麼建議？

   繼續申請。

   隨著每個釋出週期的到來，申請人數呈指數級增長，所以被選中的難度越來越大，這可能會令人沮喪，但請知道，被拒絕並不意味著你沒有才華。實際上不可能接受每一位申請者，但我們建議一個替代方案：

   開始參加我們每週的 Kubernetes SIG Release 會議，介紹自己，並熟悉團隊和我們正在進行的專案。

   釋出團隊是加入 SIG Release 的途徑之一，但我們一直在尋找更多的幫手。再次強調，除了某些技術能力外，我們最看重的特質是我們可以信任的人，而這需要時間。

8. 你能否談談釋出團隊對 Kubernetes v1.28 特別興奮的任何正在進行的舉措或即將推出的功能？這些進展如何與 Kubernetes 的長期願景保持一致？

   我們很高興終於可以在社群基礎設施上釋出 Kubernetes 軟體包了。這是我們幾年來一直想做的事情，但這個專案有很多技術上的影響，必須在過渡之前就位。一旦完成，我們將能夠提高我們的生產力並控制整個工作流程。

結語

好了，這次對話到此結束，但學習永無止境。我希望這次採訪能讓你對 SIG Release 的工作以及如何開始提供幫助有了一些瞭解。需要再次強調的是，本文涵蓋了 SIG Release 下的第一個子專案——釋出團隊。在下一篇關於 SIG Release 的 Spotlight 部落格中，我們將聚焦於釋出工程子專案，介紹它的工作內容以及如何參與。最後，你可以通讀 SIG Release 章程，以更深入地瞭解 SIG Release 的運作方式。

• ←上一篇
• 下一篇→