聚焦 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 的运作方式。

• ←上一篇
• 下一篇→