用例-与厨师一起送货

讨论转录:

好的。早上好。我意识到我没有把我的名字写在幻灯片上，所以我把它放在那里，但是你们可能很难看到。我叫迈克尔·杜西。我在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上的虚拟化还是云上的私有。甚至在公共云环境中。亚马逊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代码是合理的。对吧?更多的是单元测试的观点。但是当我们想要检查确保如果我把这个基础设施作为代码放在一个正在运行的系统上，它是否创建了我期望的或我想要的正在运行的系统。对吧?所以我们称之为-我们认为这是集成测试。有像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.

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

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

有趣的是，当我们开始谈论发布管道的想法时，我们开始谈论发布管道，每个人都-有趣的是，行业中的每个人都开始倾向于持续交付的想法。非常有趣的是，我不认为我们很多人真的在思考为什么这是有价值的。对吧?比如为什么这会给我们组织的思维方式带来根本性的改变?对吧?

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

(观众)

尤其是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里面也做了很多工作Seth在房间后面。谈论我们如何释放藏物。那么我们如何释放我们实际提供给你的代码，让你实际使用我们的产品。他有几个想法。他还为此写了一篇很长的文章。但那篇文章中有两个关键的思想打动了我。

第一个是，你在管道中所做的一切都是为你创建的可推广工件服务的。对吧?有趣的是，当你开始考虑如何构建管道时，你必须考虑你试图创建的对象和你最终想要的结果。从外部行动者的角度来看，其他的都不重要。真正重要的是工件以及您需要做什么来测试单个工件。不一定是所有其他演员。其他演员会在更晚的时候进入。

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

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

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

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

因此，它为您提供了跨团队的一致流程。它还提供了一个通用的命名法。塞斯和我在路上讨论过这个问题，命名法的重要性真的很有趣。但如果我去找赛斯，如果我说，在准备阶段有什么地方出了问题，他很清楚哪里出了问题。对吧?如果我告诉他我的发布管道在这个特定的阶段被打破了，因为我们有这个共同的命名法。对吧?我们所有的发布管道在Chef中看起来都是一样的，这是因为我们使用Chef交付，这给了你这种能力。对吧?

但是对话的变化非常有趣。对吧?而不是在你寻求帮助的时候不得不去解释如果你不得不试着向别人解释那个更大的图表，这对他们来说就更难了而且分享也会变得更难。

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

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

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

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

所以没有人了解核反应堆，所以他们可能会花上五分钟的时间，每个人都是橡皮图章，然后说，好吧，让我们去建造一个核反应堆。中间的问题，人们对它有更多的了解，但它不需要花费那么多钱，所以他们可能会争论一个小时。但是这个车棚，每个人都和它有关。对吧?可能每个人都曾经骑过自行车。人们在某个时间点把自行车放在车棚里。它不需要花那么多钱，所以大概要花100美元来粉刷自行车棚。但是每个人都会争论它应该是什么颜色因为他们都有最喜欢的颜色。这是一些与他们相关的东西，他们可以在头脑中掌握的东西。所以他们会为此争论几个小时。 Right?

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

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

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

所以你有来自供应商的材料，它们在码头上停留五天，然后最终进入铣削。有两个人在碾磨，他们生产的每一件神器都要花两分钟。它们实际上增加了两分钟的价值。对吧?所以基本上他们把它磨成正确的形状。10天之后，焊接的两个人终于有足够的时间来捡起那个藏物。然后他们会把它焊接到自行车车架上。他们花了四分钟把它焊接成自行车车架。然后它会放置15天，然后有人会把它捡起来，三个人会把它捡起来涂漆。它会凝固，要花7分钟来涂漆。 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分钟的浪费。对吧?我们只是坐在那里什么都不做。这就是你可以开始优化的地方我在这里会多讲一点。

但如果你想想我们是如何发布的。对吧?谢谢你对这个图表的思考。但这两张图看起来非常非常相似。对吧?如果你回到另一张图我们展示了所有的绿色方框和所有的时间这和你在这里看到的完全一样。所以我们可以开始使用这些行业中已经存在的工具，就像Sully船长昨晚说的，我们行业中的很多人都在做同样的事情，在不同的行业中都在试图解决完全相同的问题。这张图来自精益实践。还有精益生产。还有丰田的生产系统。 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周期用于一些甚至不再相关的事情。

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

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

这是瘦，这是慕达。对吧?所以我们可以使用这些工具来帮助我们-帮助我们优化应该如何构建发布管道。

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

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

这是批准，这是交付。但基本上我们所做的，这实际上是我们使用的发布管道形状。这是唯一的管道形状，你得到的交付。有趣的是，我们在所有的软件中都使用了这个方法，我们正在开发和交付给你，客户。如果你们有任何问题，我可以回答，或者Seth也在房间里。我很乐意多谈谈我们是怎么做的。

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

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

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

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

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

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

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

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

那么，我们还有大约四分钟的提问时间。我能回答你什么问题吗?