香肠的制作方法:来自Kubernetes Podcast的Kubernetes 1.11发布访谈

作者:Craig Box(Google)

在KubeCon EU,我的同事Adam Glick和我很高兴地宣布了 Google的Kubernetes播客。在每周的谈话中,我们重点介绍Kubernetes和Cloud Native领域中发生的所有伟大事件。从一周的新闻,到社区内人士的采访,我们将帮助您了解Kubernetes的所有最新信息。

我们 最近很高兴发言 Red Hat的Kubernetes 1.11发行经理,Red Hat的Josh Berkus以及即将推出的1.12的发行经理VMware的Tim Pepper。

在这次对话中,我们了解了发布过程,季度发布对最终用户的影响以及Kubernetes的烘烤方式。

我鼓励你听 播客版本 如果您有通勤路线或要dog狗。如果您喜欢听到的声音, 我们鼓励您订阅!如果您时间紧缺,或者只是想快速浏览,我们很高兴与您分享成绩单。


保险盒:首先,恭喜您,谢谢。

JOSH BERKUS:好的,谢谢。祝贺我,因为我的工作已经完成。

[笑声]

对蒂姆表示祝贺和同情。

[笑]

蒂姆·佩珀:谢谢,我想谢谢你吗?

[笑]

ADAM GLICK:对于那些对流程不太了解的人,您为什么不帮助人们理解-成为发行经理是什么感觉?发行到所有人都看到的过程是什么,好,发行了,1.11可用了吗?要达到这个目标需要什么?

JOSH BERKUS:我们有一个季度发布周期。因此,我们每三个月发布一次。理想和幸运的是,这实际上是我们现在的工作方式。在上一版本发布之前的两三个星期左右,有人自愿担任发布负责人。该人被确认 SIG发行。到目前为止,我们从来没有一个以上的志愿者,因此并没有真正的战斗。

然后那个人开始与他人一起工作 一个团队 叫做发布团队。蒂姆(Tim)与史蒂芬·奥古斯都(Stephen Augustus)和 挑出一大堆人。然后在之后或之前(可能是之后),因为我们要等待上一个版本的回顾,因此发布负责人会设置 时间表 对于即将发布的版本,例如所有截止日期。

这是一回事,因为我们仍在修改相对的截止日期,代码冻结应该保留多长时间,以及我们应该如何跟踪功能?因为我们还不觉得自己已经完全掌握了这种节奏。我的意思是,就像我们做得很好一样,但是我们不想真正地扎根,这是每个发行版的时间表。

另外,由于假期,我们必须调整时间表,对吗?因为您无法确定代码冻结的截止日期是从7月4日开始,还是在设计中期或其他时候,否则我们将有大量的供款人在休假。

蒂姆·佩珀(TIM PEPPER):这是我不得不花一些时间思考的东西,思考1.12。回到6月初,当我们修改代码冻结日期时,开始考虑1.12的含义是什么?这些事情什么时候开始出现在日历上?然后对于1.11,我们只有一种复杂性。如果我们将发布的发布时间推迟到本周,我们将开始进入7月4日的美国假期,并且不太可能做很多事情。

如此之大的滑倒意味着要在我们真正知道我们成功地对事物进行分类之前,滑入7月中旬。也许最坏的情况是,我们要等到七月。

因此,也许不是偶然地每季度进行一次为期三个月的节奏,而是可能我们意外地从下一个发行版中删减了一个月,或者将其推迟到了年底。这使事情的审议变得相当复杂,但值得庆幸的是,本周一切进展顺利。

CRAIG BOX:到目前为止,所有发行版本都是四分之一-付出或付出都是12周的发行周期。您认为这将继续发展吗,还是发布团队正在考虑他们可以运行发布的不同方式?

蒂姆·佩珀:整个社区都在考虑这一点。有声音希望节奏更快,也有声音希望节奏更短。两者都有很好的论据。

ADAM GLICK:因为它很有趣。听起来这是一个日期驱动的发布周期,而不是功能驱动的发布周期。

JOSH BERKUS:是的,当然。老实说,我真的认为软件世界中的每个人都认识到功能驱动的发布周期根本行不通。发行团队的大部分职责(团队中的几个成员都在这样做)正在将尚未准备好的事情从发布中撤出。而困难的部分是弄清楚哪些事情还没有准备好,对吗?因为从事这项工作的人往往对在截止日期之前可以完成的工作和可以解决的问题非常乐观。

ADAM GLICK:当然可以。

蒂姆·佩珀(TIM PEPPER):这是我认为对发布团队所采用的流程有用的一件事,即让影子人员花一些时间在发布团队上,逐步提高自己的领导地位并获得一些经验,开始有所了解,以了解这种乐观情绪,并了解审核过程。

说这个过程甚至是夸大其词。只需看看我们如何建立直觉的方式就可以审查,理解和管理风险,并且真正地积极主动地及早地追逐并尽早采取措施以及时解决问题,而不是继续保持乐观并让事情陷入困境并有释放的风险。

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信号。这就是那个人的工作,只是观察所有测试是否变红,然后设法弄清为什么变红并引起人们的注意。

ADAM GLICK:我经常听到您所说的“重大变更”,因为它破坏了正在运行的现有系统。您如何识别这些人,以便当他们看到时,嘿,这里有一个新版本的Kubernetes,我想尝试一下,这仅仅是要发行说明吗?还是有一种特殊的方式来识别重大变化而不是新功能?

JOSH BERKUS:涉及发行说明。我的意思是,请记住,Kubernetes功能发生的一件事是我们经历了此Alpha,Beta,通用可用性阶段,对吗?因此,某个功能的Alpha可以发布几个版本,然后变成一个或两个版本的Beta版本,然后就可以普遍使用了。拥有此功能的想法的一部分可能需要某个功能在该周期中可用一年或更长时间,然后才能将其正式发布,直到我们正式发布时为止,我们确实希望做到这一点,我们不会更改API为了这。

但是,事情有时会发生,我们有时不得不这样做。到目前为止,我们在人群中真正识别出这一点的主要方法是在发行说明中。如果你看 当前发行说明,实际上现在有两件事是一些重大更改。

其中之一就是 优先与抢占 现在,默认情况下启用该抢占功能可以使行为不佳的系统用户以新方式引起麻烦。我实际上必须查看发行说明,以了解第二个版本是什么...

蒂姆·佩珀: 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中,我最初加入是bug分类的影子,但最终我不是阴影,因为原本应该是bug分类的负责人后来退出了。然后,我最终成为了漏洞分类专家,并且不得不即兴发挥作用,因为当时没有关于该角色所涉内容的文档。

然后我是 错误分类 在第二个周期(1.10周期)中,然后接管该周期的释放线索。我待办事项清单上的一件事是更新要成为发布负责人的要求,因为我们实际上确实有书面要求,并且要说现在的期望是您至少要在发布团队上花费两个周期,一个它们要么作为发布线索的线索,要么作为发布线索的阴影。

CRAIG BOX:漏洞分类是听上去的吗?

JOSH BERKUS:是的。差不多了涉及的跟踪比分类要多。其中一部分只是工具方面的缺陷,这是我们希望解决的问题。但是GitHub API的局限性使构建自动化工具以帮助我们智能地跟踪问题变得颇具挑战性。我们实际上正在与GitHub合作。就像,他们很有帮助。只是,他们有自己的扩展问题。

但是除此之外,您知道很多事情,就分流而言,这就是您所期望的,对吗?哪个正在查看每一个问题,并且首先说这是一个真正的问题?第二,这是一个严重的问题吗?第三,谁需要解决这个问题?

这是很多工作,因为对于Kubernetes的定期贡献者来说,他们每天收到的GitHub通知数量意味着我们大多数人都关闭了GitHub通知。

惊险者:的确如此。

JOSH BERKUS:因为这只是消防水带。结果,当某人现在真的需要注意某件事时,通常需要一个人通过电子邮件或Slack或他们喜欢的任何方式来追踪它们。 Twitter在某些情况下。我已经做到了。并说,嘿。我们确实需要您研究此问题,因为它将阻止beta版本。

ADAM GLICK:当您查看当前正在执行的过程时,将来会发生哪些变化,这些变化将使发布过程变得更好,更容易?

JOSH BERKUS:嗯,我们刚刚经历了整个回顾,我提出了一些建议。显然,一些额外的自动化将有所帮助,特别是在我们已经解决了这些问题的同时,我将在发布团队的四分之一周期内进行实际操作,并且可以查看更长期的目标。实际上是我们的GitHub数据流问题。

除此之外,我在回溯中提出了很多建议,但实际上取决于Tim将尝试实施哪些建议。所以我让他[评论]。

TIM PEPPER:我认为1.11周期中发生的最大变化之一就是这种对试图保持持续集成测试状态始终保持绿色状态的强调。这对于软件开发和保持速度来说是巨大的。如果您还拥有更多功能,那么我想现在瀑布开发过时了,您会进行一段时间的功能开发并接受不稳定的问题,稍后您将回过头来花一些时间进行稳定和修复,确实延长了开发人员的反馈循环。

他们不知道发生了什么,随着时间的流逝,问题变得更加复杂。第一,开发人员不再考虑正在从事的工作。他们失去了能够有效解决问题的环境。

但是随后您也开始进行交互。也许是引入了一个错误,然后其他人开始解决它或依赖它,并且您获得了复杂的依赖项,因此难以修复。而且,当您在周期的后期尝试执行这种复杂的分辨率时,随着时间的流逝,它将变得站不住脚。因此,我认为继续并在此基础上继续发展,我发现更多地关注测试用例和有意义的测试范围。我认为这是一个巨大的文化变革。

也许是因为我是从错误分类的职位开始跟随乔什的角色的,并且在他前面提到的与分类和分类有关的通信和跟踪中,我确实有些担心,有时电子邮件和Slack相对而言安静。 SIG会议记录有些稀疏,或者YouTube视频上传缓慢。因此,我认为围绕选择的一般工件是我们需要更加严格的领域。所以我希望看到其中的一些。

这就像评论问题一样微妙,嘿,此提交未说明正在做什么。因此,对于发布团队而言,我们无法评估其风险与价值。因此,您可以在此处提供更多信息吗?这样的事情可以为发布团队和开发社区提供更多信息,因为这是开源的。要进行协作,您确实确实需要深入沟通。

CRAIG BOX:说到文化的变化,Kubernetes发行主音的专业面包师听起来就像是一段旅程。

JOSH BERKUS:之间有很多东西。

惊险者:您能说有很多相似之处吗?

JOSH BERKUS:信不信由你,实际上有相似之处。这就是相似之处,因为我实际上是在早先考虑过这一点。因此,当我是一名专业面包师时,我要做的一件事就是早上做糕点。就像,我实际上负责为自定义订单执行其他几项工作,但是由于我还是必须在凌晨3:00上班,这也令人痛苦地与某些流程相似。因为无论如何我还是必须在凌晨3:00上班,所以我的次要职责之一是托盘早上的糕点。

其中的一部分就是您拥有一个巨大的燃气烤箱,其中带有10个不断旋转的旋转架。就像,您可以在机架移动时将它们弹出进出烤箱,从而将它们放入烤箱。这需要一定的技巧。在头几周的工作中,手腕上会出现烧伤痕迹。然后,不同的糕点需要进行一定数量的旋转。

与发布节奏有很多相似之处,因为您正在做的是将东西弹出烤箱,或者看到有东西开始播放,然后您需要一定的时间才能检查在上面,或者您需要将其拉出。而且您正在与其他许多事情同时进行。您知道,还有40个其他托盘。

惊险者:大概有一群同事同时在场。

JOSH BERKUS:是的。另一件事是这些截止日期是绝对的,对吧?你不能说,哦,好吧,我在读杂志上的文章,而且我没有时间把那个托盘拉出来。太晚了。糕点被烧掉了,您将不得不把它扔掉,并且他们的前箱里没有足够的糕点来应付早上的高峰。客户对您的借口不感兴趣。

因此,从这个角度来看,从说的角度来看,嘿,我们有许多事情需要并行进行,它们有截止日期,而这些截止日期是硬性截止日期,实际上这非常相似。

CRAIG BOX:蒂姆,您还有其他历史可以帮助您到达今天的位置吗?

蒂姆·佩珀(TIM PEPPER):我认为从某种意义上讲,我更像是传统旅程。我拥有计算机工程学士学位。但是我也可能有点离群值。在90年代后期,我发现了对开源和Linux的热情。也许是那种早期采用者,早期信徒。

并在海湾地区从事该行业一段时间。参与了硅谷和湾区Linux用户小组,并设法以Linux sysadmin的身份找到工作,然后进行设备驱动程序和内核的工作,直到发行为止。因此,从某种程度上来说,这是所有标准。然后,我还围绕硬件支持,高性能计算,非统一内存访问做了其他工作。真正,真正的系统起作用。

然后大约三年前,我的老板真的在弯曲我的耳朵,试图让我从事与云相关的项目。这简直太抽象了,与我一直在做的低级位类型有所不同。

但是有点勉强地使我最终意识到,云很有趣,它比本地机器专用系统(我以前做过的事情)复杂得多。它是大规模分布的,并且在分布式网络中的所有节点上都具有高延迟,低可靠性的互连。因此,需要解决的是极其复杂的工程问题。

因此,这引起了我的兴趣。然后开始在这个用于虚拟机和容器的开源协调器上工作。它是用Go语言编写的,非常有趣。但这不是Kubernetes,而且很明显Kubernetes正在起飞。因此,大约一年前,我做出了明智的选择,转而从事Kubernetes的工作。

ADAM GLICK:以前,Josh,您曾谈过一些准备成为发行经理的准备。对于其他有兴趣加入社区并可能参与发行管理的人,他们应该遵循与您相同的方式吗?或哪些方式对他们有利?蒂姆(Tim)对您而言,您是如何进行下一版本的准备工作的。

JOSH BERKUS:发布团队的好处是我们拥有正式的指导路径。而且速度很快,对吗?那是按季度发布的优势,对吗?是在六个月内,如果有时间,您可以从阴影中加入团队,成为发布主管。而且您知道,等到发布时间到来时,您最好得到上司的支持,因为您最终将花费大部分工作时间在发布管理的最后阶段。

因此,答案是报名查看我们何时进入发布周期的后半部分,以进行签名。或在发布周期开始时注册为阴影。实际上,某些位置可以合理地使用多个阴影。有些职位只需要大量的工作,例如发行说明。结果,实际上可以有意义地使用多个阴影。因此,仍然可能会有人们可以注册1.12的地方。是真的吗,蒂姆?

蒂姆·佩珀:好的。我想-天哪,目前我们的发布小组中有34名志愿者,这是-

ADAM GLICK:哇。

JOSH BERKUS:好的。好。也许不是。

[笑]

蒂姆·佩珀(TIM PEPPER):潜在的成群的猫。但是我认为,即使在正式的志愿服务之外,也没有人欢迎他参加发布团队会议,关注发布团队的活动。 松弛,开始了解该流程的工作原理。实际上,所有开放源代码都属于这种情况。甚至不必是发布团队。如果您对网络充满热情,请开始关注SIG Network的工作。我认为,这是进入项目任何区域的相同途径。

每个SIG都有一个通道。因此,无论名称如何,它都是#SIG。 [在我们的情况下]#SIG-发布。

我也可能会给一个插头 我在KubeCon上的演讲 在今年春天的哥本哈根会议上,讨论了发行团队是如何成为新的贡献者进入的途径的,并在那里对新移民有一些想法和建议。

CRAIG BOX:我非常喜欢Google SRE验尸模板中的三个问题。而且我敢肯定,在您发布1.11时,您将在回顾过程中完成这些操作,因此,我想一次向他们提出一个问题。

首先,进展顺利吗?

JOSH BERKUS:我认为对于贡献者和发布团队来说,确实有两点改进。首要的事情是着重强调在代码冻结之前使测试网格变得绿色。

蒂姆·佩珀:好的。

JOSH BERKUS:现在部分进行得不错,因为我们有出色的CI主管, 艾什·桑达(Aish Sundar),目前正在接受培训,以成为发布负责人。

蒂姆·佩珀(TIM PEPPER):我将其中一部分算作“您在哪里幸运的地方”之一。地区。我们碰巧遇到了一个很棒的人,他突然出现并自愿参加。

JOSH BERKUS:是的。然后,其中一部分也是我们说的,嘿。您知道,我们不会做以前做过的事情,直到代码烂掉才真正关心这些测试。我们现在将关心这些测试。

重要的是,这对Kubernetes社区而言确实非常重要,当我们访问各种SIG,SIG群集生命周期,SIG可伸缩性和SIG节点以及其他发生测试失败的故障时,我们对他们说了这一点。他们没有说,迷路了。我很忙。他们说,出什么事了?

CRAIG BOX:太好了。

JOSH BERKUS:这就产生了很大的不同。第一件事几乎可以允许的第二件事是缩短代码冻结时间。因为代码冻结期对于开发人员来说是令人沮丧的,因为如果他们碰巧没有使用1.11功能,即使他们以前使用过一个功能,并且在周期的早期就交付了它,而且已经完全完成了,瘫痪了,在代码冻结期间他们什么也做不了。因此,这对于他们来说非常令人沮丧,我们希望使这段时间尽可能短。这次我们做到了,我认为这对所有人都有帮助。

CRAIG BOX:发生了什么不好的事情?

JOSH BERKUS:片状测试存在很多问题。我们有很多旧的测试并没有得到很好的维护,它们正在测试非常复杂的事情,例如升级具有40个节点的集群。结果,这些测试的失败率很高,与代码中的任何更改几乎没有关系。

因此,发生的事情之一以及我们发布推迟一天的原因是,我们离发布还有一周的时间,只是由于抽签的好运,所以进行了一系列此类测试一次都失败了。事实证明,失败实际上并没有任何意义,与Kubernetes无关。但是,如果没有大量研究,就没有办法告诉我们,并且在不延迟发布的情况下,我们将没有足够的时间进行这项研究。

因此,我们希望在1.12周期中解决的一件事是实际上将其中一些不稳定的测试排除在外。修复它们或将它们移出发布阻止类别。

TIM PEPPER:从某种意义上讲,我认为这也凸显了Josh提到的进展顺利的一件事,即着重于早期使测试结果绿色化,这使我们能够看到这些鳞片问题的严重程度。然后,不幸的是,它们全都因故障而重叠,这再次说明,这些薄片已在社区中被召唤了相当长的一段时间。我的意思是至少一年。我认识一个真正关心他们的贡献者。

但是,它们成为第二要务,而不仅仅是在短期内完成工作,获得功能并证明功能有效,以及以某种风险管理方式接受发布团队的认可,这是片状的。我们没有时间对它们进行处理,没关系。但是由于强调现在保持测试始终保持绿色,我们有可能奢侈地专注于改进这些薄片,并真正到达我们真正具有高质量CI信号的位置,并且可以真正相信我们在测试中获得的结果。处于持续进行状态。

JOSH BERKUS:解决了一些更基本的问题之后,我们现在看到了其他一些问题,例如相关功能之间的协调。就像我们现在所拥有的功能一样,这是向后兼容的发行说明之一,该功能进入beta版本,并且默认情况下处于启用状态。

本应为第一个功能提供访问控制的第二个功能未作为Beta进入,并且默认情况下未启用。并且第一个功能的团队直到发布前两天才意识到第二个功能没有被保留。因此,这实际上将导致我们在11.1中修补某些内容。

就像这样,我们把它放到了不顺利的地方。但是另一方面,正如Tim所指出的,在几个发布周期之前,我们甚至没有发现这是一个问题,因为我们仍在为单个功能而苦苦挣扎,这些功能在发布之前就已经有了清晰的想法进去,什么都没进。

蒂姆·佩珀(TIM PEPPER):我认为类似的情况也可以提倡使用功能分支。如果这些事情相关,我们可能已经看过它,并在该分支和预集成中进行了更多的预测试,并决定也许将最初不相交的要素合并为一个要素分支,并真正说服自己他们在一起很好。并跨所有T,在其上点缀所有Is,并且不要在可能会消失的alpha功能上设置门。

CRAIG BOX:接下来是最后一个问题,我想你们两个都提到了一点。您在哪里幸运或不幸的?

JOSH BERKUS:我可以说我很幸运的第一名是真正的一支出色的球队。我的意思是,我们只有很多了不起的人,他们非常出色,非常有朝气并且非常热衷于承担发布职责,包括Aish和Tim,Ben和Nick和Misty,他们在发布四个星期后接管了Docs。然后疯狂地说道,嗯,我是这里的新手,所以我将实际更改我们一直在做的一堆最初没有用的事情。所以那是第一。我的意思是,这确实使一切都变得不同。

然后,就像我说的那样,第二件事是,我们没有受到任何重大的,意想不到的活动扳手的袭击。因此,在1.10周期中,我们实际上有两个,这就是为什么我仍然认为Jace能够将发布推迟了一周的发布视为英雄。

您知道,排名第一的原因是可伸缩性测试由于长期不相关的原因而开始长时间失败,然后掩盖了当我们让它们再次正常工作时它们实际上由于真正原因而失败的事实。结果,最终在原定发布日期的几天之内调试了一个主要且极为复杂的可伸缩性问题。因此,这是1.10周期的第一把活动扳手。

1.10周期的第二个活动扳手是我们有一个需要修补的安全孔。同样,在原定发布日期的一周之后,我们发布了安全更新,并且该安全更新需要修补发布分支。事实证明,针对发布分支的补丁破坏了许多传入功能。在1.11版本中,我们没有得到如此重要的东西,对此我感到非常感谢。

蒂姆·佩珀(TIM PEPPER):而且,我可能会以某种方式争论说,其中的一部分不仅仅是运气。这个社区拥有一支优秀团队的程度,不仅是发布团队,而且还有更多,这其中的一部分用于整个项目中人们的积极工作,尤其是在SIG所做的贡献者经验中,他们正在这里树立积极和包容的文化。你真的看到了。当问题浮出水面时,您会看到人们跳来跳去,并真正地尝试以建设性的方式解决他们。成为其中一部分真的很有趣。


感谢Josh Berkus和Tim Pepper与Google的Kubernetes播客进行了交谈。

乔什·伯库斯(Josh Berkus) 在#sig-release中闲逛 Kubernetes松弛。他维护着一份名为“Kubernetes开发的最后一周“,与Noah Kantrowitz在一起。您可以在Twitter上通过以下方式阅读他: @fuzzychef,但他确实警告您,那里也有很多政治。

蒂姆·佩珀(Tim Pepper) 还在Slack上-他总是向那些提出问题,寻求帮助或建议的人们开放。在Twitter上,您可以在以下位置找到他 @pythomit,即“ Timothy P”倒退。蒂姆(Tim)是狂热的足球迷和 波特兰木材波特兰荆棘,因此除了技术之外,您还将获得有关足球的各种意见!

你可以找到 Google的Kubernetes播客@kubernetespod 在Twitter上,您可以 订阅 这样您就不会错过任何一集。