聚焦 SIG Release（发布团队子项目）
发布特别兴趣小组 (SIG Release)，Kubernetes 每 4 个月都会通过尖端功能和错误修复来磨练其利刃。您是否考虑过像 Kubernetes 这样的大型项目如何如此高效地管理其时间表以发布新版本，或者发布团队的内部运作方式是怎样的？如果您对这些问题感到好奇，或者想了解更多并参与 SIG Release 的工作，请继续阅读！
SIG Release 在 Kubernetes 的开发和演变中起着至关重要的作用。它的主要职责是管理 Kubernetes 新版本的发布过程。它以定期的发布周期运行，通常每三到四个月一次。在此周期中，Kubernetes 发布团队与其他 SIG 和贡献者密切合作，以确保顺利且协调的发布。这包括规划发布时间表、设置代码冻结和测试阶段的截止日期，以及创建二进制文件、文档和发行说明等发布工件。
在您继续阅读之前，重要的是要注意 SIG Release 下有两个子项目 - 发布工程和发布团队。
在这篇博文中，Nitish Kumar 采访了 SIG Release 的技术负责人 Verónica López (PlanetScale)，重点介绍了发布团队子项目、发布过程以及参与方式。
从最初的规划到最终的发布，Kubernetes 新版本的典型发布过程是什么？您是否使用任何特定的方法和工具来确保顺利发布？
Kubernetes 新版本的发布过程是一项结构良好且由社区驱动的工作。我们没有遵循任何特定的方法或工具，除了一个带有一系列步骤的日历来保持组织性。完整的发布过程如下所示
发布团队入职： 我们首先组建一个发布团队，其中包括来自 Kubernetes 社区的志愿者，他们将负责管理新版本的不同组件。这通常在上次发布即将结束之前完成。一旦团队组建完成，新成员就会入职，同时发布团队负责人和分支经理会提出一个常用可交付成果的日历。例如，您可以查看在 SIG Release 存储库中创建的 v1.29 团队组建问题。要成为发布团队的一员，贡献者通常会经历发布影子计划，但这并不是参与 SIG Release 的唯一途径。
开始阶段： 在每个发布周期的最初几周，SIG Release 会认真跟踪 Kubernetes 增强提案 (KEP) 中概述的新功能和增强功能的进展情况。虽然并非所有这些功能都是全新的，但它们通常从 alpha 阶段开始，随后进入 beta 阶段，并最终达到稳定状态。
功能成熟阶段： 我们通常会发布几个 Alpha 版本，其中包含处于实验状态的新功能，以收集社区的反馈，然后发布几个 Beta 版本，这些版本的功能更加稳定，重点是修复错误。用户的反馈在这个阶段至关重要，以至于有时我们需要发布额外的 Beta 版本来解决在此阶段可能出现的错误或其他问题。一旦清除这些问题，我们会在实际发布之前发布一个候选版本 (RC)。在整个周期中，我们会努力更新和改进文档，包括发行说明和用户指南，在我看来，这个过程值得单独写一篇文章。
稳定阶段： 在新版本发布前几周，我们实施代码冻结，此后不允许添加任何新功能：这使得重点转向测试和稳定。在主版本发布的同时，我们会继续每月发布旧版 Kubernetes 的官方支持版本的补丁，因此可以说 Kubernetes 版本的生命周期会延长几个月。在整个发布周期中，我们会努力更新和改进文档，包括发行说明和用户指南，在我们看来，这个过程值得单独写一篇文章。
您如何在每个版本中平衡稳定性和引入新功能？使用什么标准来确定哪些功能可以进入版本？
这是一项永无止境的任务，但是，我们认为关键在于尊重我们的流程和指南。我们的指南是社区数十名成员经过数小时的讨论和反馈的结果，他们为该项目带来了丰富的知识和经验。如果我们没有严格的指南，我们将不断地重复相同的讨论，而不是将时间用于需要我们关注的更具成效的主题。所有关键的例外情况都需要大多数团队成员的共识，因此我们可以确保质量。
决定哪些功能可以进入版本的流程在发布团队接管工作流程之前就开始了。每个单独的 SIG 以及最有经验的贡献者都可以决定是否要包含一个功能或更改，因此规划和最终批准通常属于他们。然后，发布团队会确保这些贡献满足文档、测试、向后兼容性等方面的要求，然后才正式允许它们加入。每月补丁版本的 cherry-pick 也是类似的过程，我们有严格的政策，不接受需要完整 KEP 的 PR 或不包括所有受影响分支的修复。
在开发和发布 Kubernetes 时，您遇到的一些最重大的挑战是什么？您是如何克服这些挑战的？
每个发布周期都会带来一系列挑战。它可能涉及处理最后一刻的问题，例如新发现的常见漏洞和暴露 (CVE)、解决内部工具中的错误，或解决以前版本的功能导致的意外回归。我们经常面临的另一个障碍是，尽管我们的团队规模庞大，但我们大多数人都是以志愿者的身份贡献的。有时会感觉我们人手不足，但我们总能设法组织起来并使其正常工作。
作为一名新的贡献者，我参与 SIG Release 的理想途径是什么？在一个每个人都忙于自己任务的社区中，我如何找到合适的任务来有效地做出贡献？
每个人参与开源社区的方式都不同。SIG Release 是一个自给自足的团队，这意味着我们编写自己的工具来发布版本。我们与 SIG K8s Infra 等其他 SIG 进行了大量协作，但我们使用的所有工具都需要为我们庞大的技术需求量身定制，同时降低成本。这意味着我们一直在寻找愿意帮助不同类型项目的志愿者，而不仅仅是“仅仅”发布一个版本。
我们当前的项目需要 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 的运作方式。