聚焦 SIG Release（發布團隊子專案）
發布特別興趣小組 (SIG Release)，Kubernetes 在此透過尖端功能和錯誤修正，每 4 個月磨礪其鋒芒。您是否曾想過像 Kubernetes 這樣的大型專案，如何如此有效率地管理其時間表以發布新版本，或發布團隊的內部運作看起來如何？如果您對這些問題感到好奇，或想了解更多資訊並參與 SIG Release 的工作，請繼續閱讀！
SIG Release 在 Kubernetes 的開發和演進中扮演關鍵角色。其主要職責是管理 Kubernetes 新版本的發布流程。它以規律的發布週期運作，通常每三到四個月。在此週期中，Kubernetes 發布團隊與其他 SIG 和貢獻者密切合作，以確保順暢且協調良好的發布。這包括規劃發布時程表、設定程式碼凍結和測試階段的截止日期，以及建立發布工件，例如二進位檔、文件和發布注意事項。
在您繼續閱讀之前，務必注意 SIG Release 下有兩個子專案 - 發布工程 和 發布團隊。
在這篇網誌文章中，Nitish Kumar 採訪了 Verónica López (PlanetScale)，SIG Release 的技術主管，重點介紹發布團隊子專案、發布流程的外觀，以及參與方式。
從初步規劃到最終發布，Kubernetes 新版本的典型發布流程為何？您是否使用任何特定的方法和工具來確保順利發布？
Kubernetes 新版本的發布流程是一項結構完善且社群驅動的工作。我們沒有遵循任何特定的方法或工具，只有包含一系列步驟的日曆來維持井然有序。完整的發布流程如下所示
發布團隊成員加入： 我們從組建發布團隊開始，其中包括來自 Kubernetes 社群的志工，他們將負責管理新版本的不同組件。這通常在先前的版本即將結束之前完成。一旦團隊組建完成，新成員就會加入，而發布團隊負責人和分支管理員會針對通常的可交付成果提出日曆。例如，您可以查看在 SIG Release 儲存庫中建立的 v1.29 團隊組建問題。若要成為發布團隊的一員，貢獻者通常會經歷發布見習計畫，但這並非參與 SIG Release 的唯一途徑。
開始階段： 在每個發布週期的最初幾週，SIG Release 會勤奮追蹤 Kubernetes 增強提案 (KEP) 中概述的新功能和增強功能的進度。雖然並非所有這些功能都是全新的，但它們通常從 alpha 階段開始其旅程，隨後推進到 beta 階段，並最終達到穩定的狀態。
功能成熟階段： 我們通常會發布幾個 Alpha 版本，其中包含處於實驗狀態的新功能，以收集社群的回饋，然後發布幾個 Beta 版本，這些版本中的功能更穩定，重點是修正錯誤。來自使用者的回饋在這個階段至關重要，以至於有時我們需要發布額外的 Beta 版本，以解決在此階段可能出現的錯誤或其他疑慮。一旦清除這些問題，我們會在實際發布之前發布候選發布版本 (RC)。在整個週期中，我們會努力更新和改進文件，包括發布注意事項和使用者指南，我認為這個過程值得另寫一篇網誌文章。
穩定階段： 在新版本發布前幾週，我們實施程式碼凍結，在此時之後不允許新增功能：這讓重點轉向測試和穩定。與主要版本並行，我們會持續發布舊版 Kubernetes 的每月修補程式，這些舊版 Kubernetes 是官方支援的版本，因此您可以說 Kubernetes 版本的生命週期會向後延伸數個月。在整個發布週期中，我們會努力更新和改進文件，包括發布注意事項和使用者指南，我們認為這個過程值得另寫一篇網誌文章。
您如何在每個版本中處理穩定性和引入新功能之間的平衡？使用哪些標準來判斷哪些功能可以納入版本中？
這是一項永無止境的任務，但是，我們認為關鍵在於尊重我們的流程和指南。我們的指南是社群中數十名成員經過數小時討論和回饋的成果，他們為專案帶來了豐富的知識和經驗。如果我們沒有嚴格的指南，我們將不斷重複相同的討論，而不是將時間用於更有效率且需要我們注意的主題。所有關鍵例外都需要大多數團隊成員的共識，因此我們可以確保品質。
決定哪些內容可以納入版本的流程，早在發布團隊接管工作流程之前就已開始。每個個別的 SIG 以及最有經驗的貢獻者，都可以決定他們是否要加入某項功能或變更，因此規劃和最終核准通常屬於他們。然後，發布團隊會確保這些貢獻符合文件、測試、向後相容性等方面的要求，然後才正式允許它們納入。每月修補程式版本的選取也發生類似的流程，我們有嚴格的政策，不接受需要完整 KEP 的 PR，或不包含所有受影響分支的修正。
在開發和發布 Kubernetes 時，您遇到過哪些最重大的挑戰？您如何克服這些挑戰？
每個發布週期都帶來自己的一系列挑戰。它可能涉及處理最後一刻的疑慮，例如新發現的常見漏洞與暴露 (CVE)、解決我們內部工具中的錯誤，或解決先前版本的功能造成的意外回歸。我們經常面臨的另一個障礙是，雖然我們的團隊規模龐大，但我們大多數人都是以志工身分貢獻。有時可能會覺得我們有點人手不足，但是我們總是設法組織起來並使其運作。
作為新的貢獻者，我參與 SIG Release 的理想途徑應該是什麼？在每個人都忙於自己任務的社群中，我如何找到合適的任務集，以便有效地做出貢獻？
每個人參與開放原始碼社群的方式都不同。SIG Release 是一個自給自足的團隊，這表示我們編寫自己的工具，以便能夠發布版本。我們與其他 SIG (例如 SIG K8s Infra) 進行大量協作，但我們使用的所有工具都需要針對我們龐大的技術需求量身訂製，同時降低成本。這表示我們不斷尋找志工，他們願意協助處理不同類型的專案，而不僅僅是「只是」發布版本。
我們目前的專案需要混合技能，例如 Go 程式設計、了解 Kubernetes 內部機制、Linux 封裝、供應鏈安全、技術寫作和一般開放原始碼專案維護。隨著專案的成長，這種技能組合不斷演進。
對於理想的途徑，這是我們的建議
- 讓自己熟悉程式碼，包括功能的管理方式、發布日曆和發布團隊的整體結構。
- 加入 Kubernetes 社群溝通管道，例如 Slack (#sig-release)，我們在其中特別活躍。
- 加入 SIG Release 每週會議，社群中的所有人都可以參加。參與這些會議是了解您可能認為與您的技能組合和興趣相關的正在進行和未來專案的好方法。
請記住，每位經驗豐富的貢獻者都曾經和您一樣，而且社群通常非常願意指導和支援新手。不要猶豫提問、參與討論並採取小步驟來貢獻。
什麼是發布見習計畫？它與各種其他 SIG 中包含的其他見習計畫有何不同？
發布見習計畫為有興趣的人提供機會，在整個 Kubernetes 發布週期中，見習發布團隊的資深成員。這是一個獨特的機會，可以了解 Kubernetes 發布在各個子團隊中需要的所有辛勤工作。許多人認為我們所做的只是每三個月發布一個版本，但那只是冰山一角。
我們的計畫通常與特定的 Kubernetes 發布週期一致，該週期具有大約三個月的可預測時程表。雖然此計畫不涉及編寫新的 Kubernetes 功能，但它仍然需要高度的責任感，因為發布團隊是新版本和數千名貢獻者之間的最後一步，因此這是一個以加速的方式學習現代軟體開發週期的絕佳機會。
您通常會尋找哪些資格的人員，以擔任下一個 Kubernetes 版本的發布見習生/發布主管志工？
雖然所有角色都需要一定程度的技術能力，但有些角色需要更多 Go 實務經驗和 Kubernetes API 的熟悉度，而其他角色則需要擅長以清晰簡潔的方式傳達技術內容的人員。重要的是要提到，我們重視熱情和承諾，勝過第一天的技術專業知識。如果您態度正確，並向我們表明您喜歡使用 Kubernetes 和/或發布工程，即使只是透過您在閒暇時組建的個人專案，團隊也會確保指導您。成為自我啟發者且不害怕提問，可以在我們的團隊中走得很遠。
對於多次被發布見習計畫拒絕的人，您有什麼建議？
繼續申請。
在每個發布週期中，我們的申請人數都呈指數成長，因此越來越難以入選，這可能會令人沮喪，但請了解，被拒絕並不表示您沒有才華。只是實際上不可能接受每位申請者，但以下是我們建議的替代方案
開始參加我們的每週 Kubernetes SIG Release 會議，以自我介紹並熟悉團隊和我們正在進行的專案。
發布團隊是加入 SIG Release 的方式之一，但我們一直在尋找更多人手來幫忙。再次強調，除了某些技術能力外，我們最渴望的特質是我們可以信任的人，而這需要時間。
您可以討論發布團隊對 Kubernetes v1.28 特別感到興奮的任何正在進行的計畫或即將推出的功能嗎？這些進展如何與 Kubernetes 的長期願景保持一致？
我們很高興終於在社群基礎架構上發布 Kubernetes 套件。這是我們多年來一直想做的事情，但這是一個具有許多技術意涵的專案，必須先到位才能進行轉換。一旦完成，我們將能夠提高生產力並掌控整個工作流程。
最後的想法
好的，這次對話在此結束，但學習並未結束。我希望這次採訪讓您對 SIG Release 的工作以及如何開始提供協助有一些概念。務必再次提及，本文涵蓋 SIG Release 下的第一個子專案，發布團隊。在下一篇關於 SIG Release 的焦點網誌中，我們將重點介紹發布工程子專案、其工作內容以及如何參與。最後，您可以瀏覽 SIG Release 章程，以更深入了解 SIG Release 的運作方式。