用例-与厨师一起交付货物

讨论转录:

好吧。早上好。我意识到我的名字没有在幻灯片上，所以我把它放在那里，但这可能真的，真的很难让你们看到。我叫迈克尔·达西。我在Chef工作。今天我要讲的是，我写了一个摘要。我可能不会把抽象讲到t，但是我要从操作的角度讲一下释放管道。也许我该停止播放音乐了。好了。我想后面那位好心的先生已经帮我搞定了。

有趣的是，首先。有多少人使用Chef?或者，好吧，你们中的一些人。有多少人知道大厨是什么?更多的你。有多少人根本不知道大厨是什么。好吧，你们几个。这很重要。

所以我们在过去的几年里经历了这段旅程。Chef最初主要是作为一个配置管理工具。有趣的是，当我们开始作为一个配置管理工具，我们实践这个东西作为基础设施作为代码，我们开始表现得更像开发人员。对吧?非常有趣的是Chef是从网络运营开始的，大型网络运营，电子商务网站之类的。从那个世界开始。发生的事情是，我们肯定演变成管理企业，银行，其他类似的事情。有趣的是，当我们开始进入网络运营世界时，它非常适合这个叫做DevOps的新事物的出现。

所以我要谈谈这段旅程。基本上我们是如何进入构建发布管道这个行业的我们是如何采取一种不同的方法以及我们为什么采取不同的方法。

所以基本上，如果你想说什么是Chef。如果您想用一句话来定义它，您可以说Chef是作为代码的基础设施。对吧?大厨给你的是DSL。所以它给了你一种语言。它基于Ruby。你可以用这种语言做的是你可以编程地提供和配置组件。不管分量的值是多少，不管分量对你意味着什么。无论是文件，还是系统上运行的服务。但也可以是你想要操纵的其他东西。 Like API endpoints. Right? And a common one that we manipulate in our release pipelines is the Artifactory APIs. So we communicate out to the Artifactory API and we publish the rpms that you would then go and get from downloads dot Chef dot io. Right? Then, from an infrastructure as code perspective, the philosophy is, is that your infrastructure as code, or your Chef code should be treated like any other code base. Right? And I’ll talk about that a little bit more here in a second.

我们的想法是，将基础设施作为代码，你应该能够做三件事。您应该能够重构您的业务或运行业务的应用程序。从代码存储库(将应用程序代码和基础结构存储为代码)中进行数据备份。因为我们不处理数据所以你必须以某种方式存储数据。还有计算资源。2022世界杯阿根廷预选赛赛程计算资源的任意值。2022世界杯阿根廷预选赛赛程无论是在你自己的数据中心。无论是在VMware上进行虚拟化还是在云上进行私有虚拟化。甚至在公共云环境中。亚马逊Azure等等。 Right?

所以，把这三件事放在一起来讨论Chef是一个整体，所以它的基础设施是代码，以编程方式提供和配置组件，你把它当作任何其他代码库，然后你重构——你应该能够用这三件事重构你的应用程序。

我们把它当作代码来讨论。对吧?因为这是有内涵的。对吧?因此，作为代码的基础设施应该像对待任何其他代码库一样对待。那么你对其他代码库做了什么呢?对吧?您有一些围绕该代码库的软件工程实践。您有关于如何将更改合并到代码库中的软件工程实践。您有关于如何发布实际代码库和发布工件的工程实践。 Right? So it’s super interesting is that as operations people, we started down this path of going and configuring infrastructure and that when we — the initial time that we put Chef code into a Git repository, it completely changed the world of how, from our perspective, how operations should work. Right? Now all of a sudden we have operations people working in Git on a regular basis. Right? Other things like that, and using practices and principles that developers are very used to and very comfortable with. The operations people started behaving more and more like developers.

因为如果要像对待其他代码库一样对待它，就应该将它存储在源代码控制中。您应该有测试覆盖率。对吧?它应该是，至少应该是持续集成管道的一部分。对吧?

我们来讨论一下测试。大家以前见过这个吗?有些人可能听过。如果您有开发人员背景，您可能已经看到了这一点。我发现这非常有趣。我看到雅虎的一个人做了这个演讲，他们在谈论他们的持续交付之旅。如果你还没听过这个演讲，那其实是一个非常非常棒的演讲。我不知道玛丽莎·梅耶尔以及她为什么参与进来，但她基本上下达了一个指令，在我们能够不断地交付变化和功能之前，什么都不能发布。所以他们基本上把每个功能都搁置起来，直到他们能够以持续交付的方式推出产品。有趣的是他们谈到了这张幻灯片因为当你谈到这张幻灯片时你谈到了所有进入你释放的东西。 Right? You really have to look at that entire release pipeline, or that release chain and see how much manual testing do you have in that process of getting an artifact out. Right?

我们在Chef发现，当我们沿着基础设施作为代码的这条路走下去时，从几个不同的角度来看，测试覆盖率真的非常非常重要。首先，我们想要确保我们编写的Chef代码是一致的。对吧?所以更像是单元测试的角度。但是我们也想去当我们想要检查确保如果我把这个基础设施作为代码放在一个运行中的系统上，它是否创建了我期望的或我想要的运行中的系统。对吧?我们称之为集成测试。有一些工具，比如server speck, end speck和其他类似的东西可以让你做到这一点。我们围绕着如何使用Chef烹饪书进行测试构建了很多工具。我们建立了很多这样的工具，我们的社区建立了很多这样的工具。 And basically we tried to flip the picture to where this state. Right? So this is what you want from an optimal perspective of software testing. Right? And when you think of software testing, you shouldn’t just think of the software that you’re releasing that runs your actual application, but also the infrastructure as code that’s required to actually go and build that application stack that you need. Right?

作为一个操作人员，或者有操作背景的人，我发现非常有趣的是，当我们写一个脚本的时候，我一直在做。对吧?就像您编写shell脚本一样，您如何验证shell脚本是否正常工作?你把它放到一个实时运行的系统上然后进行手动测试。你会说，啊，它成功了。好吧。在shell脚本中，破折号n和破折号x总是你的朋友这是你的测试。对吧?但是从一个进入Chef世界的运营人员开始考虑发布以及如何正确地发布，这是非常非常重要的事情，要意识到它必须自动化。如果它不是自动化的，如果测试不是自动化的，你应该找到一种方法，或者你需要那个测试，另一件事是你能否找到一种方法，以某种方式自动化那个测试。 Cause if you can’t automate the test, then you’re going to be in that previous picture.

所以我们发现，随着基础设施和代码发展到今天，我们开始做测试驱动的开发。对吧?如果你不知道什么是测试驱动开发，本质上是你先写测试，测试会失败。所以它也被称为红绿。测试将会失败，然后你去编写使测试通过的实际代码。对吧?基本上你写的是你想要看到的结果。作为运维人员，我们开始编写测试驱动开发。我们开始使用一系列工具来实践测试驱动的开发，这些工具围绕基础设施作为代码。

另一件非常有趣的事情是，我们也开始为Chef烹饪书建立发布管道。对吧?或者将此基础设施作为代码。当我们开始编写这些发布管道时，我们发现了一些常见的模式和实践，我们看到我们的客户一遍又一遍地使用它们。我们也看到我们的客户做了很多不好的事情。我一会儿会讲到这个。

所以有趣的是，当我们开始讨论发布管道这个概念时，我们开始谈论发布管道，每个人——就像有趣的是，这个行业的每个人都开始被持续交付这个概念所吸引。超级有趣的是，我认为我们很多人都没有真正思考过为什么它有价值。对吧?为什么这会给我们的组织思维方式带来根本性的改变?对吧?

这就是所谓的三种方法。对吧?这是三种方法。有人知道这三种方法是怎么来的吗?

(观众)

尤其是DevOps。

[观众]凤凰计划。

凤凰计划．对吧?所以Gene Kim重写了，还有其他几个人，基本上重写了这个目标。这涉及到系统层面的思考以及如何排除故障不是如何排除故障而是如何优化整个系统。有趣的是，当你将内容放入发布管道时，你会从这三种方式中获得相同的好处。或者你可以从那个角度来看待你的问题。对吧?

我们来看第一个，系统级思维。所以系统层面的思考从几个不同的角度帮助我们。所以我们避免了局部优化。所以如果你能看到，从摇篮到坟墓，或者从摇篮到部署，我猜，我们并没有扔掉我们在发布管道中生成的东西。对吧?好吧，也许你是。最终。对吧?我想我们中的很多人都想在我们必须支持的一些遗留应用程序中做一些小小的调整。对吧? So it give you the holistic picture of how that […] object gets built from the instance that somebody checks in code to where it’s actually running on a live system. Right? So that’s an interesting aspect of continuous delivery.

另一件事是，你也可以开始了解对上游或下游参与者的影响。所以你可以看到你的释放训练实际上是如何影响其他人的，这些人可能会在不同的点上消耗你。

所以从放大反馈的角度来看，发布管道也能帮助我们。对吧?所以当你的发行管道中断时，会发生什么?你会得到一个消息，说构建不好，或者部署不能工作，或者其他类似的事情。你得到的信息说这个测试失败了或者这个对象没有正确部署等等。你得到的信息是关于你将要部署的东西是否会像你期望的那样工作。对吧?你认为这是显而易见的，但有趣的是，当你开始以不同的方式使用这些信息时，它真的可以帮助你，我马上就会讲到。

另一件事是它给了你持续学习和改进的能力。对吧?所以如果你在做持续交付或持续部署，你也在做，希望，持续学习。因此，改进永远不会完成。您的实践和过程得到改进。你所使用的技术会得到改进。当然，每个人的网站都不是在Docker中运行的。对吧?别笑了，真的。是不是太早了? Tried to play some music to get your guys going.

那么，当你从整体上考虑问题，从系统的角度考虑问题时，你该如何开始思考呢?你可以真正开始建立这个持续改进和持续学习的过程，因为你可以看到整个画面，你有这些反馈循环在进行。

另一件非常重要的事情是，一个领域的进步，往往需要其他领域的进步。所以如果你局部优化了一些东西，你可能会影响到其他的东西。要么往下，要么往上游。然后你就得去优化发布过程或发布周期中的其他东西。对吧?

所以基本上。这是2010年出版的一本书的模型，持续交付．这本质上是最优的部署管道模型。或者，至少是他们在那本书里提出的。有趣的是，你可以看到反馈循环。对吧?我们刚刚谈过。你也能看到整个系统。这样你就对发生的事情有了一个完整的了解。这对我们来说很熟悉。每个人可能都见过持续交付管道。

他们在书中谈到了一件事。或者是Jez之后也谈到的，关于低风险发布的四项原则。所以低风险的发布是增量的。您想要分离部署和发布。所以构建工件和释放工件是不一样的。不好意思，是在部署藏物。因此，构建工件就是释放它，然后部署实际上是将它放到正在运行的系统上。然后你还需要专注于减少批量大小。

抱歉，我老婆在给我发短信。我以为我把它关了。让我来处理一下。好了。谢谢你！

然后你想优化弹性。但有趣的是我们通常得到的是这样的东西。对吧?这张图看起来和这张图有很大的不同。对吧?那么你如何开始你如何从系统层面来看待这个问题?第一，它太大了。太多了。这张图有很多很多错误。这实际上是某人的释放管道。 Right? At some point they branch out and they deploy to multiple environments all at the same time. Then they merge back in and all this other really, really odd stuff.

这也是他们发布管道的另一个例子。这是同一家公司，他们将保持匿名。我把上面的大部分东西都涂黑了，所以希望他们以后不会来起诉我们。但是从之前图表的角度来看他们讨论的最佳部署管道持续交付．我们实际上在原则上所做的，与理论上所做的有很大的不同，理论，正如理论所提出的那样我们应该做什么。或者从最优的角度来看我们应该做什么。对吧?

所以我们应该做的是。我建议你，你的发布管道可能看起来像这样或这样。你应该做的是把发布管道扔掉。因为你可能在发布过程中做错了很多事情。这就是为什么你在两三年前开始走这条路的时候创造了这个特殊的过程。你当时所做的决定是有原因的。但这并不一定意味着它们现在也适用。对吧?所以你要做的就是试着让管道合理化。

我们在大厨的一个同事，叫克里斯·韦伯。你可以在推特上关注他。我想确认一下，我跟他说了一声。因为他在大厨和赛斯身上做了很多工作赛斯就坐在教室后面。谈论我们如何释放藏物。那么我们如何发布我们给你的代码，让你真正使用我们的产品。于是他有了一些想法。他为此写了一篇很长的文章。但那篇文章中有两个关键的想法让我印象深刻。

第一个是，你在管道中所做的一切都是为你所创建的可推广工件服务的。对吧?有趣的是，当你开始考虑如何建立一个管道时，你必须考虑你想要创建的对象和你想要的最终结果。从外部演员的角度来看，其他的都不重要了。真正重要的是工件和您需要做什么来测试单个工件。不一定是所有其他演员。其他参与者稍后进入，并在管道中进一步发展。

然后他的另一个想法是，在另一端有提升的工件存在之前，管道不会创造任何价值。所以从本质上说，管道不会给组织增加很多价值。对吧?如果它们没有增加价值，直到你真正拥有了客户真正可以使用和消费的产品，那么你就不想要这样的东西了。需要花费大量的时间来实际得到工件，并实际证明工件是否为客户增加了价值。对吧?所以你要尽可能地优化它。有趣的是，如果我放大这张图如果我没有把它模糊化，所有这些方框里都有时间。对吧?有些时间是14分钟，7分钟，8分钟，所有的工作都完成了，从测试的角度来看，它增加了价值，给了我们反馈，从拥有一个人可以实际使用和消费的工件的角度来看，它没有增加任何价值。

那么你如何开始思考如何使管道合理化呢?所以第一件事是，关注增量变化。所以通常情况下，这些管道之所以这么大，是因为我们一次向管道输送了太多的东西。对吧?小的改变真的很重要。不仅是从易于开发的角度来看，而且从你如何知道你将要发布的东西不会破坏其他人的角度来看。对吧?渐进式变化是一种被反复宣扬的东西，但我认为它并没有在现实中得到充分的实践。

您希望使用最少的步骤来验证工件。确认藏物是好的。另一件有趣的事情是当你有一个更小的管道，它更容易排除故障，如果有什么真的出错了。如果你创建的工件有问题，如果你做了一个增量发布，如果你做了一个非常非常小的发布。通过小释放，它可能只有几行。如果你这样做，那么你就知道你在那个特定的构建中释放了什么，你知道如果有什么东西坏了，那么你只释放了一个东西，因此你就很清楚是什么东西坏了实际的工件。对吧?我是说，如果我释放一个，如果我加入一个东西，藏物就坏了，罪魁祸首是什么?我刚刚加进去的东西。对吧? See how easy that is.

关于管道合理化的另一件事是我们发现，通过我们的咨询活动和我们与客户所做的工作，一个共同的管道形状非常有帮助。对吧?如果每个人的管道看起来像这样，或者像这样，这是同一组织中两个不同的管道，我如何进入这个新组?对吧?所以如果你换了团队，换了小组等等。你可以从这个到这个或者从这个到这个。你如何理解你面前的这个系统?您如何理解为什么这个发布管道会以这样的方式存在?对吧?因此，如果你有一个共同的形状来释放你的工件，它会从不同的角度帮助你。

因此，它为您提供了跨团队的一致流程。它也给了你一个通用的命名法。Seth和我在路上讨论过这个问题，命名法的重要性真的很有趣。但是如果我去找赛斯，如果我说，在准备阶段有些东西失败了，他确切地知道哪里会失败。对吧?如果我告诉他我的释放管道在这个特定的阶段中断了，因为我们有这个通用的命名法。对吧?我们所有的发布管道在Chef中看起来都是一样的，这是因为我们使用了Chef交付，这给了你这种能力。对吧?

但是对话的变化非常有趣。对吧?相比之下，当你寻求帮助的时候，你必须去解释这个如果你必须试着向别人解释那个更大的图表，对他们来说会困难得多分享也会更困难。

因此，如果你有一个共同的管道形状，你有共同的命名法，共同的过程，因此你可以有一个共同的方法来优化整个组织。对吧?你可以用同样的方式看问题，因此当你想要考虑如何更快地发布产品时，你可以跨管道使用相同的工具来优化这些管道。我马上就会讲到。

它可以防止工具晃动。我们看到的另一个问题是，当你从一个团队转移到另一个团队时，你会有一个全新的发布过程，当然，一个团队可能会使用Jenkins，一个团队可能会使用Chef delivery或Bamboo之类的东西。对吧?所以现在您有了一套全新的工具，您必须从发布管道的角度来学习这些工具。对吧?

另一件事是，我们是工程师，我们喜欢争论什么是最优的做事方式，我们会永远争论下去。这就是所谓的自行车脱落。对吧?所以如果你不知道——每个人——谁不知道自行车脱落是什么?我会告诉你自行车脱落背后的故事。好吧，几个人。

有一个人，他是英国人，我想他已经过时了。我叫帕金森。他提出了帕金森定律。他实际上有两条定律。一个是帕金森定律，另一个是帕金森琐碎性定律。所以自行车脱落是帕金森的琐碎定律。你也应该看看他的另一个定律，帕金森定律，因为它实际上也很有趣。其实我觉得这比自行车脱落的那个有趣多了。但基本上他说的是，如果你有一个委员会，如果你把三件事摆在委员会面前:你应该把员工的自行车棚涂成什么颜色，他们是否应该花2000万美元建造一个核反应堆，然后介于这两者之间的一些东西。对吧?

所以没有人了解核反应堆，所以他们可能会花五分钟，每个人都会盖章，然后说，好吧，让我们去建造一个核反应堆。中间的问题，人们对它有更多的了解，但是它不需要花太多钱，所以他们可能会讨论一个小时左右。但是每个人都能联想到自行车棚。对吧?每个人可能都曾经骑过自行车。人们在某个时间点把他们的自行车放在车棚里。花不了那么多钱，所以粉刷一下自行车棚只需要100美元。但是每个人都会争论它应该是什么颜色，因为他们有自己喜欢的颜色。这是一些相关的东西，他们可以在他们的头脑中掌握的东西。所以他们会持续争论几个小时。 Right?

从工程的角度来看，当你认为你知道一些事情，你认为你对它有很好的想法时，作为工程师，我们只是坐在那里，我们会永远争论下去我们永远不会取得进展和前进。对吧?如果你有一个共同的管道形状，你在整个组织中说，这就是管道的样子，每个人都将使用相同的管道，你马上就结束了争论。对吧?这可能是好的，也可能是坏的，你可以在一些组织中这样做，但你可能不能在其他组织中这样做。

但另一件事是，你可以确保这个过程被遵循。对吧?确保流程被遵循的有趣之处在于，如果你有共同的形状，你还可以添加每个人都必须在他们的管道中拥有的共同步骤。对吧?比如合规测试，或者安全测试，或者其他类似的事情。其他人可以定义那些测试是什么样子的，比如安全团队，或者法规遵从团队，审核员等等，然后您可以使用这些测试并将它们拉入您的管道并使用它们，然后您知道当您发布工件时，或者在进行过程时，您知道您正在考虑那些其他团队的关注点。因为当您将其投入生产时，担心安全性或遵从性或诸如此类的问题已经太晚了。你需要试着把它移到我们所说的尽可能地移到左边，在部署或交付周期的早期。

那么我们来谈谈管道的优化。这叫做值字符串映射。我认为这是一辆自行车，和自行车棚没有关系，不过我认为这是如何制造一辆自行车。对吧?

所以你有来自供应商的材料，他们在码头上呆了五天，然后最后进入研磨。有两个人在铣削，他们生产的每件工艺品都需要两分钟。他们实际上增加了两分钟的价值。对吧?基本上他们把它磨成合适的形状。然后放置10天，然后两个焊接的人终于有足够的时间把那个藏物捡起来。然后他们会把它焊接到自行车车架上。他们花了四分钟把它焊接到自行车车架上。然后它会放置15天，然后有人会把它捡起来，三个人会把它捡起来，然后给它上漆。它会凝固，需要七分钟才能上色。 And then it’s gonna set for eight days and then it’ll get assembled into an actual bike that somebody wants. And then — that takes two minutes — and then it will set for 30 days before it’s actually shipped out for a customer. Right?

这看起来眼熟吗?我的意思是，如果你想一下，这是一条管道，对吧?有趣的是这是一个系统的观点。当你有了这种系统的观点，你就可以开始思考不同的事情，你可以这样想，从原材料进入工厂到真正生产出一件产品，顾客可以从中获得价值，需要68天。对吧?只需要15分钟就能生产出有价值的东西。但其他的时间基本上都是浪费。对吧?有趣的是，当你开始从系统的角度来思考问题时，你可以开始思考你可以开始优化的领域。

那么我们从哪里开始优化呢?首先，我们有这些等待状态。对吧?我们基本上有68天减去15分钟的浪费。对吧?所以我们只是坐在那里什么都不做。这就是你可以开始优化的地方，我会在这里多讲一点。

但是如果你想想我们是怎么做发布的。对吧?谢谢你的思想作品的图表。但这两个图看起来非常非常相似。对吧?如果你回到另一个图表，我们展示了所有的绿色盒子，所有这些时间，这和你在这里看到的是完全一样的。所以我们可以开始使用行业中已经存在的工具，就像萨利机长昨晚说的，我们行业中的很多人都在做同样的事情，不同行业的人都在试图解决完全相同的问题。这个图表来自于精益的实践。精益生产。还有丰田的生产系统。 Right? And that was all stuff that came out of the sixties and seventies that came out of work and Toyota. Right?

所以让我们来谈谈一些精益原则和工具，我们可以用来优化管道。价值流映射是其中之一。我刚刚展示过了。有趣的是我们在这张图中所做的是将我们所做的工作可视化。对吧?所以我们实际上可以看到当你把作品形象化的时候，它可以从几个不同的方面帮助你。你可以看到系统中所有的浪费。你还可以知道人们在做什么，所以你可能会用到的另一个精益原则是……。这可以帮助你把工作形象化，让你知道正在进行的工作是什么，别人现在在做什么，我手头的工作是什么，我要完成的工作是什么。对吧? And then the last one is Muda as well which I’ll talk about in specifics here in a second.

我们来谈谈废物的清除。这是一个很好的例子。Muda的意思是，我不知道逐字翻译成日语是什么意思，大致意思是浪费。对吧?如果你听到有人用Muda这个词基本上就是你如何清除废物。所以基本上你要做的就是找出所有浪费时间的部分留下那些不浪费时间的部分。很多时候这看起来像我们的日历。对吧?

但是回到艾德里安。他在我做的播客上提出了一个问题:如果你每天都发布，你会花多少时间在这个过程上?对吧?你要开几次会?对吧?每天都这样做。然后问你自己，如果你一天释放10次，你有足够的时间来执行所有的过程吗，你实际上要释放10次。因为如果你打算一天发行10次游戏，你就需要更换顾问委员会，你就需要一遍又一遍地做这些工作。你不能把所有的东西都放在一起，因为你在做小的，增量的发布，记住。所以基本上你需要每天更换10次顾问委员会。 Right? You’re going to have all these processes that are going to have to be followed. And what you’ll find is most of that process is going to look like this. Right? There’s going to be a lot of waste in the system that you can begin to remove.

我们来谈谈系统中的浪费。所以要注意。所以当你看到这个图表时，当你看到整个发布过程时，你可以从哪里开始优化整个发布过程?

第一，关注缺陷。所以要避免建造一开始就不好的东西。对吧?您可以通过使您的开发人员能够更容易地访问诸如开发环境之类的东西，或为开发人员提供他们所需的工具，从而避免构建一开始就不好的东西。对吧?这样模仿的效果会好一点。现在你可以用Vagrant这样的工具来实现这些功能。很多人使用它，因为开发人员可以快速启动一个实例，并开始针对该实时运行的实例进行开发。你知道有一致性，因为你在管理形象，他们实际上是在旋转东西。

生产实际顾客不需要的产品。所以这是为了防止一些东西进入到整个发布管道中，当你最终真正去制作它时，没有人会想要这些东西。非常有趣的是，有一个统计数据，我不知道它有多准确，Jez Humble喜欢抛弃它，但基本上你发布的功能中有三分之二，没有人真正使用过。所以你要解决这个问题，首先要控制进入发布管道的内容。

有趣的是，当你可以更快地发布时，你已经优化了发布管道，也许你制作了它，然后有人打开它，这就是为什么AB测试非常重要。你发布它，你打开它，你马上得到反馈，你看看客户是否真的想要它，如果他们不想要它，你可以关掉它，然后专注于其他事情。对吧?如果他们确实想要，那么你也许可以开始把那个功能做得更好，因为你可以更快地发布，你可以在他们可能想要的主要功能上分层，速度要快得多。但我们的想法是尽可能快地得到反馈。对吧?

等待进一步加工或消耗的存货。所以事情等着别人来接手。通常都是手动步骤或手动任务。当你不从系统的角度看问题时，你就不会想到所有其他的参与者实际上需要在其他不同的时间点创造出来。你要做的是等待团队为你构建服务器。对吧?这种情况仍然会发生，我知道我们在硅谷，但我住在中西部，我和很多公司合作，他们仍然需要六个月的时间才能得到一台服务器。对吧?他说的是10个月。哦，等等，那是10分钟。 Okay, thank you.

不必要的对加工。所以。所以当你不得不做的时候，很多时候发生的事情是，你要进行测试因为有人在某个时间点破坏了某些东西。对吧?但是这个测试永远不会——你可能已经解决了问题发生的根本原因，但是你总是要不断地运行这个测试。你甚至可能，考试甚至可能不-抱歉，我舌头打结了-考试可能不再是必要的，因为系统已经改变了。因此，你基本上是在旋转进程，并将CPU周期用于一些甚至不再相关的事情。

员工或会议不必要的变动。不必要的货物运输和搬运。你可以认为你在这个过程中进行了太多的审批。

然后等待上游流程交付，或者等待机器完成处理，或者等待支持功能完成，或者等待被中断的工人重新开始工作。您总是可以将此作为编译时。对吧?

这就是精益，这就是Muda。对吧?所以我们可以使用这些工具来帮助我们优化如何构建发布管道。

按照我的时间表，我要提前五分钟下班。我还有大约四分钟的时间来进行毫无歉意的产品宣传。

所以，不管你信不信，厨师外卖实际上能帮你解决很多问题。这很有趣。对吧?我们所做的是，我喜欢谷歌幻灯片它总是在我导入东西时弄乱我的字体。

这就是批准，这就是交付。但基本上我们所做的，这实际上是我们使用的释放管道形状。这是唯一的管道形状，你得到与交付。有趣的是，我们在所有的软件中都使用了这个，我们正在构建，运输和交付给你们，也就是客户。如果你们有任何问题，我可以回答或者Seth也在教室里。我很乐意多谈谈我们是怎么做的。

所以基本上你这里有一些CI类型的过程基本上所有这些都是CD类型的过程。对吧?这样我们就有了标准的Lint语法和单元检查。接下来会发生的是，有人可以进去。我们练习我们所谓的四眼规则，有人可以批准它，并说这实际上是我们想做的事情。这是我们想要发布的改变。

一旦批准发生，构建就开始了。发生的事情是，当批准发生时，我们合并为掌握。对吧?所以小的，增量的变化，合并到掌握尽可能快。分支也应该尽可能短。一旦构建完成，我们将其部署到验收环境中。在验收环境中我们把它部署到运行中的硬件上。你可以动态创建实时运行的硬件，然后[…][声音淡出]你可以使用Chef之类的工具来配置它。然后，您可以实际地将工件部署到它上，并运行烟雾和功能测试，以实际验证工件是否按照您期望的方式运行。然后一个产品经理，一个产品负责人可以进去说，我想要交付这个产品。

当这种情况发生时，它就进入了结合阶段。所以基本上如果你从这个角度看——好像他们把我的音频关掉了。我是不是太大声了?

所以当你从这个角度来考虑它时，如果你有烹饪书和应用程序，当你像这样看它时，它真的很有趣因为每个人都遵循同样的过程。每个人都遵循相同的流程将更改发布到生产环境中。对吧?所以每个人都在说共同的语言，使用共同的工具和共同的管道形状。然后在联合中发生的是，你可以把所有这些接受管道聚集在一起，实际上说，我能把这个作为一个集合部署到其他环境中吗。然后依赖性就会被拉进来。

然后另一个有趣的事情是，因为我们有一个常见的管道形状，当你进入union，你知道如果有人声明你作为一个依赖，你可以去运行他们的烟雾和功能测试，看看你是否要打破他们当你真正做你的发布。超级有趣的是如果你没有常见的管道形状，你就不会知道这些其他的参与者或这些其他的工件依赖于你甚至有烟雾和功能测试。对吧?因为你不知道人们在他们的管道里投入了什么。对吧?所以它给了你一个共同的形状，以确保你快速移动，并且安全地快速移动。

所以基本上，我们建立在交付中的原则。所以基本上跨团队和项目的一致的管道就像我们刚刚看到的那样。我们非常热衷于实施小批量和增量发布。如果您使用过Chef并下载了Chef客户端，那么您可能已经看到了变化。你将看到的是，发行数量实际上非常非常高。发布数量非常非常高的原因是因为我们做了很多这样的事情。对吧?所以现在版本号本质上变成了构建号。因为我们一直在制造这些藏物。我们一直在测试。 We’re constantly pushing things through the pipeline.

另一件事是始终如一的质量检验关。对吧?这样你就知道每个管道都要遵循相同的质量标准。你也知道，你也可以这样做如果你不想一次做所有的事情，如果你不想做我们所说的所有这些阶段，你可以关闭它们。你可以做的另一件事是我们发现管道需要是可接近的。管道需要易于创建和使用。用两个命令，你可以有一个新的管道，你可以有这个形状。你在默认情况下得到它，你总是会有它，基本上只要在它上运行交付，你会得到一个用这个形状为你创建的新管道。

回到Chris所说的有趣的一点是，如果你没有——你需要做的第一件事就是制定出发布你的作品的流程。一旦您发布了工件，那么您就可以开始构建您稍后需要的所有测试。对吧?首先发布工件，然后确定如何在构建阶段和部署阶段的过程中对其进行实际测试。

到此为止，我们还有四分钟的提问时间。我能回答你什么问题吗?