SIG Release（发布团队子项目）聚焦

SIG Release (发布特别兴趣小组) 是 Kubernetes 每 4 个月磨砺其刀锋，增加前沿功能和修复 Bug 的地方。你是否曾想过，像 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 团队组建议题。贡献者要成为发布团队的一员，通常需要通过发布影子项目（Release Shadow program），但这并非参与 SIG Release 的唯一途径。

• 起始阶段：在每个发布周期的最初几周，SIG Release 会勤勉地追踪 Kubernetes 增强提案 (KEP) 中概述的新功能和增强功能的进展。虽然并非所有这些功能都是全新的，但它们通常从 Alpha 阶段开始，随后进展到 Beta 阶段，最终达到稳定状态。

• 功能成熟阶段：我们通常会发布几个 Alpha 版本，其中包含处于实验状态的新功能，以便收集社区的反馈；随后是几个 Beta 版本，其中的功能更加稳定，重点在于修复 Bug。在这个阶段，用户的反馈至关重要，有时我们甚至需要额外发布一个 Beta 版本来解决在此阶段可能出现的 Bug 或其他问题。清理完毕后，我们在正式发布前会发布一个发布候选版本（release candidate, RC）。在整个周期内，会努力更新和改进文档，包括发布说明和用户指南，我们认为这个过程本身值得单独撰写一篇文章来介绍。

• 稳定阶段：在新版本发布前几周，我们会实行代码冻结，此后不允许再添加新功能：这使得工作的重点转移到测试和稳定性上。与主版本并行，我们会持续发布每月更新的旧的、官方支持的 Kubernetes 版本补丁，所以可以说一个 Kubernetes 版本的生命周期会持续好几个月。在整个发布周期内，会努力更新和改进文档，包括发布说明和用户指南，我们认为这个过程本身值得单独撰写一篇文章来介绍。

  

2. 你们如何平衡每个版本的稳定性和引入新功能？使用什么标准来决定哪些功能可以进入一个版本？

   这是一项永无止境的任务，但我们认为关键在于遵循我们的流程和准则。我们的准则汇集了社区数十名成员数小时的讨论和反馈，他们为项目带来了丰富的知识和经验。如果我们没有严格的准则，就会一遍又一遍地重复相同的讨论，而不是将时间用于更需要我们关注的更有成效的话题。所有关键的例外情况都需要大多数团队成员达成共识，以确保质量。

   决定哪些功能可以进入一个版本的流程早在发布团队接管工作流程之前就开始了。每个 SIG 以及最有经验的贡献者都会决定是否要包含某个功能或变更，因此规划和最终批准通常由他们负责。然后，发布团队会确保这些贡献符合文档、测试、向后兼容性等要求，然后才会正式允许它们进入。月度补丁发布的合并修改 (cherry-picks) 也有类似的流程，我们有严格的策略，不接受需要完整 KEP 的 PR，或者不包含所有受影响分支的修复。

3. 在开发和发布 Kubernetes 的过程中，你们遇到过哪些最重大的挑战？你们是如何克服这些挑战的？

   每个发布周期都会带来一系列独特的挑战。这可能包括应对最后一刻的问题，例如新发现的常见漏洞和披露 (CVEs)、修复我们内部工具中的 Bug，或者解决由之前版本功能引起的意外回归问题。我们经常面临的另一个障碍是，虽然我们的团队规模庞大，但大多数成员都是基于志愿性质进行贡献。有时可能会感觉人员有些不足，但我们总是能组织起来并使其正常运作。

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. 对于多次申请发布影子项目（Release Shadow Program）但被拒绝的人，您有什么建议？

   继续申请。

   每个发布周期，申请人数都呈指数级增长，因此被选中变得越来越难，这可能会令人沮丧，但请知道，被拒绝并不意味着你没有才能。接受所有申请者几乎是不可能的，但这里有一个我们建议的替代方案：

   开始参加我们每周的 Kubernetes SIG Release 会议，进行自我介绍，并熟悉团队和我们正在进行的项目。

   发布团队是加入 SIG Release 的一种方式，但我们一直在寻找更多人手帮助。同样，除了某些技术能力外，我们最看重的特质是值得信赖的人，这需要时间。

8. 您能否讨论一下发布团队对 Kubernetes v1.28 特别感到兴奋的正在进行的计划或即将推出的特性？这些进展如何与 Kubernetes 的长期愿景保持一致？

   我们很高兴终于能够在社区基础设施上发布 Kubernetes 软件包。这是我们几年来一直想做的事情，但这是一个涉及许多技术影响的项目，需要在过渡之前就位。一旦完成，我们将能够提高生产力并控制整个工作流程。

总结

好了，这次对话到此结束，但学习还在继续。希望这次访谈能让您了解 SIG Release 的作用以及如何开始提供帮助。再次强调，本文涵盖了 SIG Release 下的第一个子项目——发布团队（Release Team）。在下一篇 SIG Release 聚焦博客中，我们将重点介绍发布工程（Release Engineering）子项目，包括它的作用和如何参与。最后，您可以阅读 SIG Release 章程，以更深入地了解 SIG Release 的运作方式。

• ←上一篇
• 下一篇→