如果你让三个人来描述DevOps，你会得到四个不同的答案。有时从事运维工作的开发人员被称为DevOps。其他人说这与基础设施和部署的自动化有关。有时您可以将DevOps视为系统管理员的现代标签。我们可以看到这个词很流行。这他妈到底是什么？什么是DevOps？DevOps的第一种方式是通过组织中的各个功能区域创建一个平衡且稳定的工作流，从收集需求到在生产中运行软件。重点是整个系统的全局目标，而不是单个部门的局部目标。为了使概念更清楚，让我们看几个关键点。1.1批量缩减在制品(WIP)是已经开始但尚未完成的工作量。大量WIP是多任务处理的标志，可能会阻碍工作流程。要限制WIP，我们应该减少批量大小。这个想法诞生于精益生产。批量生产零件在制造业中很常见。设置新机器和在作业之间切换既费钱又费时。所以，在架设好机械之后，尽可能多的制造零件，被认为是可行的。例如，汽车生产厂将生产大量车身面板以减少转换次数。但是，这会产生大量WIP。整个制造工厂的工作流程可变性级联，导致更长的交货时间。想象一下，如果在组装汽车时发现车身面板存在缺陷，会发生什么情况？最有可能的是，整批产品都必须丢弃并重新生产。量产延迟反馈，如果出了问题，就得重做更多的工作。同样的想法也适用于软件开发。但是，我们正在处理代码，而不是机械和车身面板。对版本控制的每次提交都会增加软件开发价值流中的批量大小。一个典型的例子就是年度生产部署计划。如果每年部署一次，那么批量就很大。一步部署一年。类似于汽车工厂，如果出现任何问题，必须将整个批次送回。然后必须付出更多的努力来重做被认为已经完成的工作。找到并解决导致部署失败的问题（比如6个月前）是一项挑战。对生命周期较长的特性进行分支时可能会遇到类似的问题。一个分支保持隔离的时间越长，它看到的变化就越多，batchsize就越大。随着时间的推移，将其集成回后备箱变得越来越困难。合并冲突的可能性很高。由于反馈延迟，返工的可能性很高。这些因素扰乱了工作流程并增加了部署提前期。为了缩短部署的提前期，我们不得不减少批量大小。不推荐长期存在的特性分支。如果我们及早集成并以较小的增量部署软件，我们可以获得更快的反馈。如果我们继续减小批大小，我们最终将达到单件流，其中每个提交都流经整个软件开发价值流。一旦所有自动检查通过，更改最终将投入生产。能够实现这一目标的团队将利用基于主干的开发、持续集成、持续交付和持续部署等实践。他们投资于测试自动化，并为低风险发布设计软件。他们还自行组织，以便最大限度地减少所需的交接次数。交接需要沟通协调。不幸的是，即使在最好的情况下，一些知识也会丢失。这是一个潜在的错误点，错误可能会悄悄进入，工作可能会堆积起来，从而扰乱流程并增加部署提前期。1.2消除约束在我们的工作中不断发现和消除约束是提高吞吐量和缩短交付周期的关键。Goldratt博士在《超越目标：约束理论》中指出，在任何价值流中，总是只有一个流动方向，并且总是只有一个约束。任何不在此限制范围内进行的改进都是错觉。技术价值流的一个例子是环境创造。如果需要花费数小时来设置测试环境，那么价值流中的任何改进工作都是一种幻想。例如，如果我们将构建时间从10分钟减少到3分钟，构建就会更快。但总的来说，没有什么能做得更快。创造环境仍然是一个障碍。更糟糕的是，WIP增加了。新版本现在堆积得更快，等待部署到测试环境。由于创建上下文会阻止新工作顺利进行，因此我们应该在价值流中找到约束，将其删除，然后找到下一个约束。
