第一种方式背后的理念是,通过识别、衡量和改进价值流中的工作流程,我们可以优化和完善为客户提供价值的能力。

实现这一目标的第一步是拆分价值流中的每一项工作并使其自动化。这通常称为管道。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--exSaKoFz--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://digitize01.com/image /image_lib/images/CI-CD-Pipeline.png)

我们管道的基础

您可能已经在使用构建系统来自动化我们价值流的某些部分,但我们可以做得更好。引用 Devops 手册:

为了创建从 Dev 到 Ops 的快速可靠的流程,我们必须确保在价值流的每个阶段始终使用类生产环境。此外,这些环境必须以自动化的方式创建,最好是根据脚本和配置信息存储在版本控制中的需求,并且完全自助服务,无需任何手动操作操作所需的工作。我们的目标是确保我们可以根据版本控制中的内容重新创建整个生产环境。

作者继续说,我们应该支持按需创建开发、测试和生产环境,以便开发人员可以在任何地方运行类似生产的环境,甚至在他们自己的计算机上,按需创建和自助服务。

这样,开发人员可以在类似生产的环境中运行和测试他们的代码,作为他们日常工作的一部分,

提供有关代码质量的早期和持续反馈。

我们以前都去过那里:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--1fJ71Prx--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://4 .bp.blogspot.com/_CywCAU4HORs/S-HYtX4vOkI/AAAAAAAAAHw/Hzi5PYZOkrg/s1600/ItWorksOnMyMachine.jpg)

“它适用于我的机器!”问题来自这样一个事实,即在任何复杂的系统中都有太多的变量需要管理。如果你 google The Matrix of Hell,你可能会看到如下内容:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--v5e0Enh6--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://files.speakerdeck .com/presentations/c5ce6ce091ee01319fc1623dfa5ee5e7/slide_6.jpg)

不同类型的应用程序将在此表中具有不同的行和列,但您明白了: - 具有多个第三方依赖项的多个环境,创建了一个理智的人无法管理的组合爆炸。

大多数公司都会有一个测试和生产环境,也许您甚至有一个开发环境,您可以在其中安全地运行您的应用程序并使用最热门的新功能。但随着项目的发展,非生产环境往往会退化。由于缺乏自动化或不断更新它的纪律,他们很难跟上产品的步伐。一段时间后,开发环境中会有很多小东西以不同的方式工作,以至于很难信任它。几个月后,人们将不再相信开发环境中发生的任何事情,只有仍然没有意识到这些问题的新手才会使用它。

如何解决?

问题是,如果这些环境是手动创建的,您就不能指望人们平等地维护它们。

通过自动化他们的创建,我们使任何人都可以根据需要快速启动新环境,使每个开发人员都能在需要时拥有自己的本地环境。

自动化脚本将确保在每个环境中加载正确的配置,避免由于人为错误导致的错误配置而导致数百或数千小时的不必要的麻烦。

通过这种方式,我们通过将您的基础架构和配置视为代码、制作不可变的基础架构、确保我们在何处操作、开发和测试的位置具有可比性,并为客户提供可靠的系统操作指标,从而有效地让开发团队访问类似生产的环境 —这样开发人员贡献的新价值就可以轻松且可预测地部署给客户。

这很难,但从长远来看是有回报的!

[](https://res.cloudinary.com/practicaldev/image/fetch/s--XQdkRfjv--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgs.xkcd.com /comics/the_general_problem.png)

这不是一个简单的问题要解决。你应该注意何时何地开始这个过程。

根据我的经验,小型初创公司或软件工作室往往会忽略这一点,因为在他们的产品阶段担心这些东西太多了。

如果您的项目不必扩展,那很好。您可以在较小的项目中避免遵循这些想法,但工程团队必须对何时应该停止并实施解决方案保持警惕。

如果您获得足够大的成本,那么没有按需提供的成本,开发/生产环境平价也将扩展,甚至比您的产品更快。而雇佣更多的人只会使成本增加。

由于这个问题,成百上千的开发时间付诸东流。无法重现的错误使调试变得更加困难,担心更改应用程序的“错误”部分会导致代码质量受损,每个人都会受到影响。

每个团队和组织都是不同的,决定何时开始使用这种方法必须视具体情况而定,但我认为在项目的早期阶段逐步实施这种想法肯定是具有成本效益的。

为整个系统创建我们的单一真相存储库

为了确保即使发生灾难性事件,我们也可以重复且可预测地(理想情况下是快速)恢复生产服务,我们必须检查重新创建系统状态所需的所有资产。

那包含着:

• 所有应用程序代码和依赖项(例如,库、静态内容等)

• 用于创建数据库模式、应用程序参考数据等的任何脚本。

• 所有环境创建工具和工件

• 用于创建容器的任何文件(例如,Docker 或组合文件)

• 所有支持自动化测试和任何手动测试脚本

理想情况下,这应该使用不发生手动更改的不可变基础架构进行 - 使其更容易销毁

并重建而不是配置。

编码知识并通过存储库分享是传播知识的强大机制之一。

特别是当它包含每个库(内部或外部)时,并且每个库都有一个负责确保它成功通过所有测试的所有者。

结束

我们已经看到了开发/产品平价如何引发自动化。如果你还没有接受这些概念,那么坦率地说,你应该或者至少意识到你遇到的问题。

但不要担心!我们都去过那里,那些活着出来的人对如何解决它有一些非常有趣的想法。我们只需要听他们的。

下一个:测试自动化!敬请关注。