本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
幕后制作：Kubernetes 1.11 版本发布访谈，来自 Kubernetes 播客
在欧洲 KubeCon 上，我的同事 Adam Glick 和我很高兴宣布推出 Google 的 Kubernetes 播客。在这个每周的对话中，我们将重点关注 Kubernetes 和云原生领域中正在发生的所有伟大的事情。从本周的新闻到社区人士的采访，我们帮助您及时了解有关 Kubernetes 的一切信息。
我们最近有幸采访了 Kubernetes 1.11 的发布经理，来自 Red Hat 的 Josh Berkus，以及即将发布的 1.12 的发布经理，来自 VMware 的 Tim Pepper。
在这次对话中，我们了解了发布过程、季度发布对最终用户的影响以及 Kubernetes 如何像烘焙一样。
如果您有通勤时间或需要遛狗，我鼓励您收听播客版本。如果您喜欢您听到的内容，我们鼓励您订阅！如果您时间不多，或者只是想快速浏览一下，我们很高兴与您分享文字记录。
CRAIG BOX：首先，祝贺两位，谢谢。
JOSH BERKUS：好吧，谢谢。祝贺我，因为我的工作完成了。
[笑声]
祝贺并同情 Tim。
[笑]
TIM PEPPER：谢谢，我想也谢谢你？
[笑]
ADAM GLICK：对于那些不太了解这个过程的人来说，为什么不帮助人们理解一下——作为发布经理是什么感觉？一个版本从开始到每个人都看到它发布时，也就是，好的，它发布了——1.11 可用了，这个版本经历了什么样的过程？需要做些什么才能达到那个程度？
JOSH BERKUS：我们有一个季度发布周期。所以每三个月，我们就会发布一个版本。理想情况下，幸运的是，这实际上是我们现在做事的方式。在上一个版本发布前大约两到三周，会有人自愿担任发布负责人。这个人由 SIG Release 确认。到目前为止，我们只有一个志愿者，所以没有发生过争吵。
然后这个人开始与其他人合作组建一个称为发布团队的团队。Tim 刚刚和 Stephen Augustus 一起完成了这项工作，并挑选了一大批人。然后在之后或稍早一些（可能是在之后，因为我们想等待上一个版本的总结）——发布负责人会为即将发布的版本设置一个时间表，即所有截止日期是什么时候。
这是一件重要的事情，因为我们仍然在调整相对截止日期，以及代码冻结应该持续多长时间，以及我们应该如何跟踪功能？因为我们感觉我们还没有完全掌握那种节奏。我的意思是，我们做得相当不错，但我们感觉我们不想真正地[一成不变地]制定，这就是每个版本的计划。
此外，我们必须根据假期调整计划，对吧？因为你不能在 7 月 4 日或在设计过程中或在其他时间开始代码冻结截止日期，届时我们将会有大量的贡献者在休假。
TIM PEPPER：这是我花了一些时间研究的事情，思考 1.12。回到 6 月初，当我们正在调整代码冻结日期时，开始考虑，1.12 会有什么影响？这些事情会在日历上的什么时候开始出现？然后对于 1.11，我们有一个复杂的问题。如果我们把发布推迟到这周之后，我们就会遇到美国的 7 月 4 日假期，我们不太可能完成很多工作。
所以如果延迟太多，就意味着我们要到 7 月中旬才能真正知道我们是否成功地对问题进行了分类。最坏的情况下，我们可能会迟到 7 月底。
所以，不是三个月的季度节奏，我们可能意外地从下一个版本中砍掉了一个月，或者把它推迟到年底。这使得围绕这些事情的讨论变得相当复杂，但谢天谢地，本周一切都顺利结束了。
CRAIG BOX：到目前为止，所有版本都是一个季度——它们是一个 12 周的发布周期，或多或少。您认为这是会继续下去的事情，还是发布团队正在考虑他们可以运行发布的不同方式？
TIM PEPPER：整个社区都在考虑这个问题。有人希望节奏更快，有人希望节奏更短。两者都有很好的论据。
ADAM GLICK：因为这很有趣。听起来这像是日期驱动的发布周期，而不是功能驱动的发布周期。
JOSH BERKUS：是的，当然。我真的真诚地认为，软件界的每个人都认识到，功能驱动的发布周期根本行不通。发布团队集体的主要职责之一——团队的几名成员会这样做——是从发布中删除那些尚未准备好的东西。而困难的部分是弄清楚哪些东西没有准备好，对吧？因为正在从事这项工作的人往往对他们能在截止日期前完成什么以及他们能修复什么抱有非常乐观的态度。
ADAM GLICK：当然。
TIM PEPPER：我认为，关于发布团队，我们拥有的流程有用的其中一点是，拥有在发布团队中花费一些时间、逐步晋升到更领导的职位并获得一些经验的 shadow，开始接触到看到乐观情绪，并了解审查的流程。
说这个流程其实都有些夸大其词。仅仅是看看我们如何建立审查、理解和管理风险的直觉，并真正积极主动地、尽早地去追查问题，以便及时解决，而不是继续保持乐观，让事情可能停滞不前，并使发布处于风险之中。
CRAIG BOX：我这周一直在阅读关于 Kubernetes 引入功能分支的文章。例如，新的服务器端应用功能是在一个分支中构建的，这样它就不必在 master 分支中构建一半，然后在发布临近时，如果该功能尚未准备就绪，则再次将其删除。在我看来，这似乎是软件开发中的正常部分？为什么将它引入核心 Kubernetes 需要这么长时间？
JOSH BERKUS：我实际上不知道为什么我们不使用功能分支的历史。我的意思是，我们现在没有普遍使用功能分支的原因是我们必须从不同的系统过渡。我不太清楚我们是如何采用线性开发系统的。但这当然是我们在发布团队中讨论过的问题，因为有些我们认为会准备好的功能出现了重大问题。我们觉得，如果我们必须将其撤回，那将会很痛苦。我们实际上确实必须撤回一个功能，这不仅涉及到撤回 Git 提交，而且还涉及到从字面上反转行更改，这真的不是你想要做的事情。
CRAIG BOX：不。
TIM PEPPER：我认为，如果发布分支与持续集成和测试的 CI 系统良好集成，那么它们带来的另一个巨大好处是，你可以真正获得反馈，并且可以证明，这套东西已经准备好了。然后你可以在 master 分支上进行延迟提交。用户在预期的及时节奏中发布的特定版本中的内容都是准备好的。你不会遇到潜在的不稳定因素，因为你可以获得更多关于准备情况的证据。
ADAM GLICK：你们在工具链方面是如何考虑的？你提到了一些，而且我知道它显然是通过 GitHub 运行的。但我认为你们还有许多其他工具用于管理发布，以确保了解哪些已准备好，哪些尚未准备好。你提到在对他们正在开发的特性非常乐观的人员和时间驱动的截止日期之间进行平衡，并平衡这两者。这只是一个手动过程，还是有一套工具可以帮助你做到这一点？
JOSH BERKUS：嗯，显然有代码审查。所以首先，流程是有人想要实际放入一个特性，提交，或者任何类型的合并，对吧？所以这必须分配给一个 SIG，即这些特殊兴趣小组中的一个。可能不止一个，这取决于它涉及到哪些领域。
然后，通常是两个重叠的团队需要批准它。一个是它被分配到的 SIG，第二个是代码树中被触及的目录的 OWNERS 文件中代表的任何人。
现在，有时这些是同一组人。实际上，我可以说经常如此。但有时他们不是完全相同的一组人，因为有时你正在对网络进行更改，但这也恰好涉及 GCP 支持和 OpenStack 支持，因此他们也需要对其进行审查。
所以第一部分是人为的部分，即需要其他人查看此内容。他们可能会评论说：“嘿。这样做的方式很奇怪。你有什么理由这样做吗？”
然后第二部分是自动测试，通过 Webhook 进行的自动验收测试。实际上，我们在这次发布周期中所做的一项重大进展（我说的“我们”实际上不是指我，而是指 SIG 可扩展性 的优秀人士）是增加了一个 额外的验收测试，它执行一个小的性能测试。
因为我们历史上遇到的一个问题是，我们的主要性能测试规模很大，运行时间很长，因此当我们发现我们未通过性能测试时，我们已经积累了 40、50 个提交。因此，我们现在必须进行 git bisect 来找出哪些提交实际上导致了性能下降，这会使处理速度非常慢。
因此，在提交前添加性能，性能验收测试确实有助于稳定新提交的性能。所以我们需要通过那个级别的测试。
然后，当我们完成该级别的测试后，我们会运行一大批更大的测试——端到端测试、性能测试、升级和降级测试。我们最近添加并在流程中集成的一件事是所谓的符合性测试。符合性测试是我们测试你是否破坏了向后兼容性，因为如果你在无意中这样做，这对 Kubernetes 用户来说显然是一个大问题。
发布团队中最繁忙的角色之一是名为 CI Signal 的角色。此人的工作就是观察所有测试中是否有新事物变成红色，然后尝试找出它们变成红色的原因并引起人们的注意。
ADAM GLICK：我经常听到你所说的被称为“破坏性变更”，因为它会破坏正在运行的现有系统。你如何向人们识别这些变更，以便当他们看到有新版本的 Kubernetes 发布时，我想要尝试一下，这只是在发行说明中吗？或者是否有特殊的方法来识别破坏性变更，而不是新功能？
JOSH BERKUS：这会写入发行说明。请记住，Kubernetes 功能发生的一件事是，我们经历了 alpha、beta 和通用可用性阶段，对吧？因此，一个功能在几个版本中处于 alpha 状态，然后在几个版本中变为 beta 状态，然后它变为通用可用。拥有此功能的想法的一部分可能是需要一个功能在一年或更长时间内经历该周期才能达到通用可用性，这是因为当它达到通用可用性时，我们确实希望它是，我们不会更改此 API。
但是，事情会发生，我们偶尔确实需要这样做。到目前为止，我们向人们识别它的主要方法实际上是在发行说明中。如果你查看当前发行说明，其中实际上有两件事是某种破坏性变更。
其中之一是 优先级和抢占 位，默认情况下启用抢占现在允许系统行为不良的用户以新的方式引起麻烦。我实际上必须查看发行说明才能了解第二个是什么...
TIM PEPPER：JSON 大小写敏感性。
JOSH BERKUS：对。是的。这是你必须打破向后兼容性的情况之一，因为由于库切换，我们意外地允许人们在某些 API 中以不区分大小写的方式使用 JSON，而这从来都不应该这样。但是因为我们没有针对此的特定测试，所以我们没有注意到我们已经这样做了。
因此，在三个版本中，人们实际上可以将格式错误的 JSON 推入，而 Kubernetes 会接受它。嗯，我们现在必须修复它。但这确实意味着该领域会有用户在其配置管理中具有格式错误的 JSON，而现在将要中断。
CRAIG BOX：但至少好消息是，我理解，在此期间，Kubernetes 一直在输出格式正确的 JSON。
JOSH BERKUS：嗯哼。
TIM PEPPER：我认为这也让我想起了其他领域之一——所以回到这个问题，好吧，你如何分享破坏性变更的消息？嗯，你这样做的一种方法是尽可能多地使用高质量的 CI 来捕捉这些重要的事情。向进行破坏性变更的开发人员提供反馈，以便他们不进行破坏性变更。然后你实际上不必将其传达给用户。
因此，其中一些不可避免地会发生，因为你总是有测试逃脱。但这也提醒人们需要确保你也在随着时间的推移真正构建和维护你的测试用例以及你的 CI 系统的质量和覆盖率。
ADAM GLICK：你说的测试逃脱是什么意思？
TIM PEPPER：所以我猜这是一个行业术语，但对于那些不熟悉的人来说，你有一些未被测试覆盖的预期行为，因此，会发生一些意外的更改。并且，你不是发布你的预期行为，而是发布其他东西。
JOSH BERKUS：JSON 更改是这方面的一个典型例子，即我们正在测试 API 是否会继续接受正确的 JSON。我们没有充分测试它是否不接受不正确的 JSON。
TIM PEPPER：测试逃脱，另一种理解方式是，你发布了一个错误，因为没有测试用例突出显示该错误的可能性。
ADAM GLICK：这是一个经典案例，我们进行了测试以确保功能正常运行。我们没有测试以确保破坏性的东西不起作用。
TIM PEPPER：我们通常会专注于“我创建了此功能并且我正在测试肯定用例”。这也涉及到考虑诸如默认情况下安全并拥有真正强大的系统之类的事情。更难的工程部分通常是考虑失败用例并真正积极地管理它们。
JOSH BERKUS：我最近与一位贡献者进行了对话，其中很明显，这位贡献者从未在支持团队中工作过，因为他们对行为不良的用户的概念就像一个黑客，对吧？一个来自外部的攻击者。
我说，不，不，不。你的行为不良的用户群是你自己的员工。你知道，他们会做坏事，不一定是故意做坏事，而是因为他们试图走捷径。而这实际上是你防止破坏系统的主要考虑因素。
CRAIG BOX：Josh，你为成为 1.11 的发布经理做了什么准备？
JOSH BERKUS：我在发布团队工作了两个周期，此外，我还在那之前对发布团队进行了半个周期的审计。所以在 1.9 中，我最初加入是为了成为错误分类的影子，但我最终没有成为影子，因为原本应该是错误分类负责人的那个人退出了。然后我最终成为了错误分类负责人，并且不得不临时做出调整，因为当时没有关于该角色涉及内容的文档。
然后在第二个周期，即 1.10 周期中，我担任了 错误分类负责人，然后接管了该周期的发布负责人。而我待办事项清单上的一件事是更新成为发布负责人的要求，因为我们实际上确实有书面的要求，并说明现在的期望是你至少在发布团队中花费两个周期，其中一个周期要么担任负责人，要么担任发布负责人的影子。
CRAIG BOX：错误分类负责人是否正如其名？
JOSH BERKUS：是的。差不多。比分类涉及更多的是跟踪。其中一部分是工具中的缺陷，我们正在努力解决。但是诸如 GitHub API 限制之类的因素使得构建可以帮助我们智能地跟踪问题的自动化工具具有挑战性。我们实际上正在与 GitHub 合作。例如，他们提供了帮助。只是，他们也有自己的扩展问题。
但除此之外，你知道，很多事情都和分诊的原则一致，对吧？即查看每一个问题，首先要判断，这是否是一个真正的问题？其次，这个问题是否严重？第三，谁需要解决这个问题？
这是很多工作的内容，因为对于任何 Kubernetes 的常规贡献者来说，他们每天收到的 GitHub 通知数量之多，意味着我们大多数人都关闭了 GitHub 通知。
CRAIG BOX：确实如此。
JOSH BERKUS：因为那就像一个消防水管喷出的水流。因此，当有人真的需要立即关注某个问题时，通常需要人工通过电子邮件或 Slack 或他们喜欢的任何方式（有时甚至包括 Twitter，我做过）来找到他们。然后说，嘿，我们真的需要你看看这个问题，因为它可能会阻碍 beta 版本的发布。
ADAM GLICK：当你回顾你现在正在做的流程时，未来会有哪些变化，可以使发布流程更好、更轻松？
JOSH BERKUS：嗯，我们刚刚经历了这个回顾过程，我提出了一些建议。显然，一些额外的自动化会有帮助，我打算在退出发布团队一个季度后，可以实际关注更长远的目标时，进行这些自动化工作，特别是现在我们已经解决了一些 GitHub 数据流问题之后。
除此之外，我在回顾中提出了一大堆建议，但最终要由 Tim 来决定他将尝试实施哪些建议。所以我让他来评论。
TIM PEPPER：我认为 1.11 版本周期中发生的最大变化之一是，我们强调要始终保持持续集成测试状态为绿色。这对软件开发和保持速度至关重要。如果你仍然持有那种比较过时的瀑布式开发观念，即你先进行一段时间的功能开发，并接受不稳定性，然后在稍后某个时候再花时间进行稳定和修复，那就会大大延长开发人员的反馈循环。
而且他们不会意识到哪里出现了问题，随着时间的推移，问题也会变得更加复杂，更难以解决。首先，开发人员不再考虑他们之前在做的事情。他们已经失去了能够高效解决问题的上下文环境。
然后你还会开始遇到相互影响的问题。可能引入了一个 bug，其他人开始绕过它或依赖它，然后你就会遇到难以修复的复杂依赖关系。当你试图在周期的后期进行这种复杂的解决时，随着时间的推移，它会变得无法维持。所以我认为继续保持并在此基础上发展，我看到更多人关注测试用例和有意义的测试覆盖率。我认为这是一个正在发生的很棒的文化变革。
也许是因为我从 bug 分诊的职位接替了 Josh 的角色，并且在他之前提到了与分诊相关的沟通和跟踪，我确实有点担心，有时电子邮件和 Slack 都相对安静。一些 SIG 会议纪要有点稀疏，或者 YouTube 视频上传速度很慢。因此，我认为围绕决策的通用人工制品是我们需要更加严谨的领域。所以我希望看到这方面的一些改进。
这可能就像在 issue 中评论说，嘿，这个提交没有说明它在做什么。因此，在发布团队中，我们无法评估其风险与价值。所以你能提供更多信息吗？诸如此类的事情可以为发布团队和开发社区提供更多信息，因为这是开源的。要进行协作，你确实需要深入沟通。
CRAIG BOX：说到文化变革，从专业面包师到 Kubernetes 发布主管，听起来像是一段相当长的旅程。
JOSH BERKUS：中间还有很多事情。
CRAIG BOX：你会说它们之间有很多相似之处吗？
JOSH BERKUS：你知道吗，信不信由你，它们之间确实有相似之处。相似之处就在于此，因为我之前就在思考这个问题。所以当我是专业面包师时，我必须做的一件事是准备早点糕点。我实际上负责为定制订单做其他几件事情，但由于我无论如何都必须在凌晨 3:00 上班——这与这个过程的某些方面也有令人不安的相似之处。由于我无论如何都必须在凌晨 3:00 上班，我的次要职责之一是装早点糕点。
其中的一部分是，你有一个巨大的燃气烤箱，里面有 10 个不断旋转的旋转架。就像，你通过在旋转架移动时将它们放入和取出，来将东西放入和取出烤箱。这需要一定的技巧。你工作的前几周手腕上会留下烧伤痕迹。然后不同的糕点需要不同的旋转次数才能完成。
这与发布节奏有很多相似之处，因为你正在做的是将某样东西放入烤箱，或者你看到某样东西被启动，然后你需要经过一段时间才能检查它或需要把它拿出来。并且你正在并行执行其他很多事情。你知道，有 40 个其他的烤盘。
CRAIG BOX：而且，想必会有很多同事同时在那里。
JOSH BERKUS：是的。另一件事是，这些截止日期是绝对的，对吧？你不能说，哦，好吧，我正在读杂志文章，我没有时间把那个烤盘拿出来。太迟了。糕点烤焦了，你必须把它扔掉，而且前台的展示柜里将没有足够的糕点来迎接早高峰。而且顾客对你的借口不感兴趣。
因此，从这个角度来看，从我们必须并行执行很多事情，它们有截止日期，并且这些截止日期是硬性截止日期的角度来看，它实际上是相当相似的。
CRAIG BOX：Tim，你还有其他帮助你走到今天的经历吗？
TIM PEPPER：我认为在某些方面，我的经历更传统。我拥有计算机工程学士学位。但我也许有点像个异类。在 90 年代后期，我对开源和 Linux 产生了热情。也许算是早期的采用者，早期的信徒。
在湾区工作了一段时间。参与了一些硅谷和湾区 Linux 用户组织，并成功找到了一份 Linux 系统管理员的工作，然后开始从事设备驱动程序和内核工作，并一直做到发行版。所以这在某种程度上都是很标准的。然后我还做了一些关于硬件启用、高性能计算、非均匀内存访问的工作。这些都是真正的系统工作。
大约三年前，我的老板一直在我耳边唠叨，试图让我从事这个与云相关的项目。这让我感觉很抽象，与我之前做的底层工作完全不同。
但有点勉强地，我最终意识到云很有趣，而且它比我之前做的本地机器系统工作要复杂得多。它是大规模分布式的，并且在分布式网络中的所有节点上都有高延迟、低可靠性的互连。因此，它需要解决极其复杂的工程问题。
这让我产生了兴趣。然后我开始从事这个用于虚拟机和容器的开源编排器。它用 Go 编写，而且非常有趣。但它不是 Kubernetes，而且越来越明显 Kubernetes 正在兴起。所以大约一年前，我做出了一个明确的选择，转向 Kubernetes 工作。
ADAM GLICK：之前，Josh，你谈到了一些你为成为发布经理所做的准备。对于其他有兴趣参与社区，并且可能参与发布管理的人来说，他们应该遵循你走过的道路吗？或者他们可以通过哪些好的方式参与？对于你，Tim，你又是如何为承担下一次发布做准备的呢？
JOSH BERKUS：发布团队的好处是，我们有这种正式的导师指导路径。而且速度很快，对吧？这就是每季度发布的优势，对吧？在六个月内，如果你有时间，你可以从以影子身份加入团队，成为发布主管。并且你知道，当你在发布时间临近时，你最好能得到你老板的支持，因为在发布结束时，你最终会将大部分工作时间花在发布管理上。
所以答案是，当我们要进入发布周期的后半段时，报名成为一名影子成员。或者在发布周期的开始阶段，报名成为一名影子成员。实际上，某些职位可以合理地使用多个影子成员。有些职位需要大量的跑腿工作，比如发布说明。因此，实际上可以有意义地使用多个影子成员。所以可能仍然有地方可以让人们报名参加 1.12 版本。是这样吗，Tim？
TIM PEPPER：当然。我想——天啊，我们现在在发布团队中有 34 名志愿者，这真是——
ADAM GLICK：哇。
JOSH BERKUS：好吧。好吧。也许不是这样。
[笑]
TIM PEPPER：这可能变成了一群难以管理的人。但我认为，即使没有正式的志愿者成为指定的影子成员，任何人都可以参加发布团队会议，在 Slack 上关注发布团队的活动，开始了解流程如何运作。实际上，这在整个开源领域都是如此。它甚至不一定是发布团队。如果你对网络感兴趣，那就开始关注 SIG Network 在做什么。我认为进入项目的任何领域都是同样的道路。
每个 SIG 都有一个频道。所以它将是 #SIG- 任何名称。在我们的例子中，是 #SIG-Release。
我可能还会为今年春天在哥本哈根的 KubeCon 上做的一个 演讲做个宣传，其中谈到了发布团队如何成为新贡献者加入的途径。并且为新来者提出了一些想法和建议。
克雷格·博克斯：在 Google SRE 的事后分析模板中，有三个我非常喜欢的问题。我相信你们在发布 1.11 版本时，在回顾过程中肯定已经讨论过这些问题，所以我想现在一个接一个地问一下。
首先，哪些方面做得很好？
乔什·伯克斯：我认为有两件事确实改进了情况，无论是对于贡献者还是发布团队。第一件事是强调在代码冻结之前让测试网格变绿。
蒂姆·佩珀：绝对是。
乔什·伯克斯：现在，部分原因是我们的 CI 负责人非常出色，Aish Sundar，他现在正在接受培训成为发布负责人。
蒂姆·佩珀：我也会把这部分归为“你哪里幸运？”的范畴。我们碰巧遇到了一位很棒的人，他自愿站了出来。
乔什·伯克斯：是的。但还有一部分原因是我们说，嘿。你知道，我们不会像以前那样，在代码冻结之前根本不关心这些测试。我们现在就要关心这些测试。
而且更重要的是——这对 Kubernetes 社区来说非常重要——当我们去找各个 SIG，SIG 集群生命周期、SIG 可扩展性和 SIG 节点以及其他有测试失败的 SIG 时，我们向他们说了这些。他们没有说，滚开。我很忙。他们说，哪里失败了？
克雷格·博克斯：太棒了。
乔什·伯克斯：所以这产生了很大的影响。第二件事，很大程度上是第一件事允许的，就是缩短了代码冻结期。因为代码冻结期对开发人员来说很令人沮丧，因为如果他们碰巧没有在做 1.11 版本的功能，即使他们之前做过，并且在周期早期就交付了，而且已经完全完成，他们也会处于瘫痪状态，在代码冻结期间什么也做不了。所以这对他们来说非常令人沮丧，我们希望尽可能缩短这段时间。这次我们做到了，我认为这对每个人都有帮助。
克雷格·博克斯：哪些方面做得不好？
乔什·伯克斯：我们在不稳定的测试方面遇到了很多问题。我们有很多维护不善的旧测试，它们测试的是非常复杂的东西，比如升级一个有 40 个节点的集群。因此，这些测试的失败率很高，但与代码中的任何更改几乎无关。
因此，发生的一件事，也是我们发布延迟一天的原因是，你知道，我们距离发布还有一周的时间，只是因为随机的运气不好，这些测试中的一堆同时出现了一连串的失败。结果发现，这一连串的失败实际上没有任何意义，与 Kubernetes 无关。但是，如果没有大量研究，我们无法得知这一点，而且我们没有足够的时间进行研究而不延迟发布。
因此，我们希望在 1.12 版本周期中解决的问题之一是，实际上将其中一些不稳定的测试移出去。要么修复它们，要么将它们移出发布阻塞类别。
蒂姆·佩珀：在某种程度上，我认为这也突出了乔什提到的做得好的一件事，即早期强调让测试结果变绿，它让我们看到这些不稳定的测试问题有多么严重。然后，它们不幸地全部重叠失败，再次突显了这些不稳定的测试在社区中已经被呼吁了很长时间。至少一年了。我认识一位非常关心它们的贡献者。
但它们成为了次要问题，而不是在短期内完成任务、获得功能并证明功能有效，并在发布团队中以风险管理的方式接受，是的，这些是不稳定的测试。我们没有时间处理它们，这没关系。但是，由于强调现在始终保持测试为绿色，我们现在可能可以专注于改进这些不稳定的测试，真正达到我们拥有真正高质量的 CI 信号，并且可以真正相信我们持续获得的结果。
乔什·伯克斯：在解决了一些更基本的问题后，我们现在看到了一些其他问题，比如相关功能之间的协调。例如，我们现在有一个功能——这也是一个向后兼容的发布说明——该功能进入了测试阶段，并且默认开启。
而第二个本应为第一个功能提供访问控制的功能没有进入测试阶段，并且默认未开启。第一个功能的团队直到发布前两天都没有意识到第二个功能被搁置了。所以这将导致我们实际上在 11.1 版本中修补一些东西。
所以，我们把它归入做得不好的事情。但是，另一方面，正如蒂姆指出的那样，在几个发布周期之前，我们甚至不会认为这是一个问题，因为我们仍然在努力让各个功能在发布之前清楚地知道哪些功能会进入，哪些功能不会进入。
蒂姆·佩珀：我认为类似的事情也可能支持使用功能分支。如果这些事情是相关的，我们可能会看到它并在该分支中进行更多的预测试和预集成，并决定将最初不相关的几个功能合并到一个功能分支中，并真正说服我们自己它们在一起是好的。并在它们上完成所有细节，而不是让一些东西依赖于可能正在消失的 alpha 功能。
克雷格·博克斯：然后是最后一个问题，我认为你们都稍微谈到了一点。你们在哪里幸运，或者也许不幸？
乔什·伯克斯：我想说，我幸运的第一件事是拥有一个出色的团队。我的意思是，我们有很多很棒的人，他们非常优秀、充满活力，并且对承担他们的发布责任充满热情，包括 Aish 和 Tim 以及 Ben 和 Nick，还有 Misty，她在发布后的第四周接管了文档。然后就疯狂地投入进去，并说，好吧，我是新来的，所以我要改变一些我们一开始就没做好的事情。所以这是第一件事。我的意思是，这真的让一切都变得不一样了。
然后第二件事，就像我说的那样，我们没有遇到任何重大、意想不到的意外。所以在 1.10 版本周期中，我们实际上遇到了两个这样的情况，这就是为什么我仍然认为 Jace 能够完成一个只晚了一周的发布是英雄行为。
你知道，第一件事是可扩展性测试由于无关的原因开始长时间失败，这掩盖了当它们再次正常工作时，它们实际上由于真正的原因而失败的事实。结果是在原定发布日期前的几天内调试一个重大且超级复杂的可扩展性问题。所以那是 1.10 版本周期的第一个意外。
1.10 版本周期的第二个意外是我们遇到了一个需要修补的安全漏洞。因此，在距离原定发布日期还有一周的时间时，我们发布了一个安全更新，而该安全更新需要修补发布分支。结果发现，针对发布分支的补丁破坏了一堆传入的功能。我们在 1.11 版本中没有遇到任何这种规模的事情，我对此感到欣慰。
蒂姆·佩珀：此外，我也许会认为，在某种程度上，这不仅仅是运气。这个社区拥有一个优秀的团队的程度，不仅仅是发布团队，而是超越它，这部分归功于整个项目的人们，尤其是贡献者体验 SIG 正在积极努力在这里培养积极和包容的文化。你真的看到了这一点。当问题出现时，你会看到人们跳出来并真正尝试建设性地解决这些问题。而且参与其中真的很有趣。
感谢乔什·伯克斯和蒂姆·佩珀接受来自 Google 的 Kubernetes 播客的采访。
乔什·伯克斯在 Kubernetes Slack 上的 #sig-release 频道活动。他与 Noah Kantrowitz 一起维护一个名为“上周 Kubernetes 开发”的通讯。您可以在 Twitter 上关注他 @fuzzychef，但他警告说那里也有很多政治。
蒂姆·佩珀也在 Slack 上——他总是欢迎大家提出问题、寻求帮助或建议。在 Twitter 上，您可以在 @pythomit 找到他，它是“Timothy P”的倒写。蒂姆是一位狂热的足球迷，并且是 波特兰木材队 和 波特兰刺队的季票持有者，因此除了技术之外，您还会获得各种关于足球的观点！
您可以在 Twitter 上的 @kubernetespod 找到来自 Google 的 Kubernetes 播客，并且您可以订阅，这样您就不会错过任何一集。