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

讨论转录:

好的。早上好。我意识到我没有把我的名字写在幻灯片上，所以我把它放上去了但是你们可能真的很难看到。我叫迈克尔·杜西。我在Chef工作。今天我要讲的是，有人写了一个摘要。我可能不会完全遵循这个抽象，但是我会从运营的角度讲一下发布管道。我也许该把音乐关了。好了。我想后面那位好心的先生已经帮我搞定了。

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

在过去的几年里，我们经历了这个过程。Chef最初主要是作为一个配置管理工具。有趣的是，当我们开始做配置管理工具的时候，我们把它当作基础设施作为代码来实践，我们开始表现得更像开发人员。对吧?非常有趣的是，Chef是从网络运营开始的，大规模的网络运营，类似于电子商务网站之类的。从那个世界开始。发生的事情是，我们确实进化到管理企业，银行，和其他类似的事情。有趣的是，当我们开始进入网络操作领域时，它非常适合这个叫做DevOps的新事物。

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

所以从根本上说，如果你想说什么是Chef。如果你想在一个句子中定义它，你可以说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上的虚拟化还是在云上的私有。甚至在公共云环境中。Amazon 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.

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

我们先来谈谈测试。大家都见过这个吗?有些人可能听过。如果您有开发人员背景，您可能见过这个。我觉得这个非常有趣。我看到雅虎的一个人展示了这个，他们在谈论他们的持续交付之旅。如果你没听过这个演讲，这其实是一个非常非常好的演讲。我不知道玛丽莎·梅耶尔(Marissa Mayer)以及她为什么参与进来，但她基本上下达了一个指令，在我们能够持续交付变化和功能之前，任何其他东西都不会发布。所以他们基本上搁置了所有的功能，直到他们能够以持续交付的方式推出产品。有趣的是他们谈论了这张幻灯片因为当你谈论这张幻灯片的时候你谈论了你发布的所有东西。 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代码。对吧?所以更多的是单元测试的角度。但我们也想去，当我们想要检查，以确保如果我把这个基础设施作为代码放在一个实时运行的系统上，它是否创建了我期望或我想要的实时运行的系统。对吧?我们称之为-我们认为这是集成测试。有像服务器微尘和终端微尘之类的工具可以让你做到这一点。我们建立了很多工具围绕着你如何用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.

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

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

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

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

(观众)

特别是DevOps。

(观众)凤凰城项目。

凤凰城项目．对吧?所以吉恩·金重写了，还有其他几个人，基本上重写了目标。这涉及到系统层面的思考以及如何排除故障，或者不是如何排除故障而是如何优化整个系统。有趣的是，当你把东西放到一个发布管道中时，你会从这三种方式中得到同样的好处。或者你可以从这个角度来看待你的问题。对吧?

我们来看第一个，系统层面的思考。所以系统层面的思考从几个不同的角度帮助我们。所以我们避免了局部优化。所以如果你能看到，从摇篮到坟墓，或者从摇篮到部署，我想，我们并没有扔掉我们在发布管道中生成的东西。对吧?好吧，也许你是。最终。对吧?我想我们中的许多人都希望在我们必须支持的一些遗留应用程序中做一些小小的调整。对吧? 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.

这也是他们发布管道的另一个例子。这是同一家公司，他们将保持匿名。我把上面的大部分东西都关掉了，希望他们以后不会来起诉我们。但是从之前的图表的角度来看最优部署管道他们在持续交付．我们在原则上实际做的事情，和在理论上，理论是不一样的，因为理论规定了我们应该做什么。或者从最优的角度来看我们应该做什么。对吧?

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

我们在Chef的一个同事，他叫Chris Webber。你可以在那里关注他的推特。我想确保我给了他一次机会。因为他在Chef和坐在后面的Seth那里做了很多工作。谈论我们如何释放藏物。那么我们如何释放我们给你的代码，让你真正使用我们的产品。所以他有了一些想法。他为此写了一篇很长的文章。但这篇文章中有两个关键的想法触动了我。

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

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

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

您希望拥有验证工件所需的最少步骤数。并验证工件是否完好。另一件有趣的事情是，当您拥有一个更小的管道时，如果确实出现了错误，则更容易进行故障排除。如果您创建的工件有问题，如果您做了一个增量发布，如果您做了一个非常非常小的发布。小规模发行的话，可能只有几行。如果您这样做了，那么您实际上知道您在那个特定的构建中发布了什么，您知道如果有什么东西坏了，那么—您只发布了一个东西，因此您对什么东西实际上破坏了实际的工件有一个非常好的想法。对吧?我是说，如果我放了一个东西进去，藏物就坏了，罪魁祸首是什么?我刚加进去的东西。对吧? See how easy that is.

关于管道合理化的另一件事是我们通过咨询和与客户的合作发现一个通用的管道形状有很大的帮助。对吧?如果每个人的管道都是这样的，或者这样的，而这是同一组织中不同的管道，我如何进入这个新组?对吧?所以如果你换了团队，你就换了小组等等。你会从这个到这个或者从这个到这个。你是如何理解摆在你面前的这个系统的?你如何理解为什么这个发布管道会以这样的方式存在?对吧?所以如果你有一个共同的形状来释放你的工件，它会从不同的角度给你极大的帮助。

所以它给了你团队间一致的过程。它也给出了一个通用的命名法。塞斯和我在路上谈到了这个，命名法的重要性真的很有趣。但如果我找到赛斯，如果我说，有些东西在供应阶段失败了，他很清楚哪里会失败。对吧?如果我告诉他我的发布管道在这个特定的阶段被打破了，因为我们有这个共同的命名法。对吧?在Chef中，我们所有的发布管道看起来都是一样的，这是因为我们使用了Chef交付，这赋予了你这种能力。对吧?

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

因此，如果你有一个通用的管道形状，你就有了通用的命名法，通用的流程，这样你就可以有一个通用的方法来优化整个组织。对吧?您可以以同样的方式看待事情，因此当您试图想要思考如何更快地发布时，您可以跨管道使用相同的工具来优化那些管道。我马上就会讲到这个。

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

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

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

所以没有人了解核反应堆，所以他们可能会花大约五分钟，每个人都会橡皮图章，然后说，好吧，让我们建造一个核反应堆。中间的项目，人们对它有更多的理解，但它不需要花那么多钱，所以可能他们会争论大约一个小时。但是这个车棚，每个人都能联想到它。对吧?每个人可能都骑过自行车。人们有时会把自行车放在车棚里。它不需要花那么多钱，所以油漆自行车棚大概需要100美元。但是每个人都会把辩论的焦点放在它应该是什么颜色上因为他们都有最喜欢的颜色。这是一种让人产生共鸣的东西，是他们可以在脑海中领会的东西。所以他们会争论好几个小时。 Right?

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

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

我们来谈谈管道的优化。这叫做值字符串映射。这是，我想这是一辆自行车，和自行车棚没有关系，但我想这是，你怎么生产一辆自行车。对吧?

原料从供应商那里运来，在码头上停了5天，最后进入碾磨过程。有两个人从事研磨工作，他们生产的每件工件都需要两分钟。它们实际上增加了两分钟的价值。对吧?所以基本上他们把它磨成正确的形状。然后放置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测试非常重要的原因。你发布它，你打开它，你马上得到反馈，你看客户是否真的想要它，如果他们不想要，你可以关闭它，然后专注于其他事情。对吧?如果他们确实想要，那么你就可以开始把这个功能做得更好，因为你可以更快地发布，你就可以更快地在主要功能上添加他们可能真正想要的功能。但我们的想法是尽可能快地获得反馈。对吧?

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

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

不必要的员工移动或会议。不必要的货物运输和处理。你可以认为你在这个过程中投入了太多的批准。

然后等待上游工序交付，或等待机器完成加工，或等待辅助功能完成，或等待中断的工人返回工作岗位。您可以将此作为编译时。对吧?

这就是瘦，这就是Muda。对吧?所以我们可以使用这些工具来帮助我们优化发行渠道的构建方式。

所以根据我的时钟，我要提前五分钟结束。我有四分钟时间，现在是毫无歉意的产品推销。

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

这是批准，这是交付。但基本上我们所做的，这实际上是我们使用的发布管道形状。这是唯一的管道形状，你得到的交付。有趣的是，我们把它用于所有我们正在开发的软件，交付给你们，客户的软件。如果你们有任何问题，我可以回答或者赛斯也在场。我很乐意多谈谈我们是如何做到的。

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

一旦获得批准，就会进行构建。当审批发生时，我们会合并到master。对吧?所以小的，增量的变化，合并掌握尽可能快。分支的寿命也应该尽可能短。构建完成后，我们将其部署到验收环境中。在验收环境中，我们实际上将它部署到正在运行的硬件上。你可以动态地创建实时运行的硬件，然后[…][声音消失]你可以使用像Chef之类的工具来配置它。然后，您可以将该工件部署到它上，并运行冒烟和功能测试，以实际验证工件是否按您所期望的方式运行。然后，一个产品经理，一个产品所有者实际上可以介入并说，我想交付并运送这个工件。

这样一来，就进入了联合阶段。所以基本上如果你从这个角度看，好像他们把我的音频关掉了。我太吵了吗?

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

另一件有趣的事情是，因为我们有一个共同的管道形状，当你加入联盟，你知道如果有人宣布你是一个依赖，你可以去运行他们的烟雾和功能测试，看看你是否会打破他们当你真正发布你的时候。但非常有趣的是，如果你没有那个常见的管道形状，你就不知道这些其他的参与者或这些其他的工件依赖于你甚至有烟雾和功能测试。对吧?因为你不知道人们在他们的管道里投入了什么。对吧?所以它给了你一个通用的形状来确保你快速移动并且安全快速移动。

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

另一件事是一致的质量门槛。对吧?所以你知道每条管道都将遵循相同的质量闸门。你也知道-你还可以做什么如果你不想一次做所有的事情，如果你不想做所有这些阶段，你可以关闭它们。你能做的另一件事是我们发现管道需要是可访问的。管道需要易于创建和使用。有了两个命令，你就有了一个新的管道，你就有了这个形状。默认情况下你会得到它，你会一直拥有它基本上只要在它上运行交付，你就会得到一个用这个形状为你创建的新管道。

回到Chris说的，有趣的是，如果你没有-你需要做的第一件事是制定出让你的工件发布的过程。一旦您发布了工件，那么您实际上就构建了您稍后需要的所有测试。对吧?您首先发布工件，然后确定如何在构建阶段和部署阶段的过程中实际测试它。

好了，我们还有四分钟的提问时间。有什么问题需要我回答吗?