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