本文要点

软件开发流程中有两种类型的决策：战略和战术。
为了让组织更好地实现流水线驱动，我们可以将有关编程工作的日常战术决策更多地转移到流水线中制定，不再让人为因素影响这些决策过程。
流水线中人为因素带来的瓶颈越少，组织用流水线驱动的效果就越好，从而实现真正的持续交付。
在流水线驱动的组织中，我们的角色还包括教会流水线自动制定决策。
为了适应流水线驱动的工作方式，我们中的许多人将需要学习新的技能。

引言

组织怎样才能实现像Netflix、亚马逊和谷歌等公司的研发速度和敏捷性，从而每天都对生产代码部署多次更改呢？

为什么这么多大中型企业都没能做到这一点呢？

如何实现真正的持续交付？

正像所有软件问题的根源一样，这个目标能否实现还是取决于人力因素的；更具体地说是人们在流水线中的工作方式。流水线能在多大程度上实现持续交付，取决于我们对它制定的期望。

流水线驱动的文化对流水线和文化都提出了要求，所以我们先来谈谈流水线。

流水线

一条流水线是一个或多个自动化任务或“作业”的组合，它们以特定顺序运行以生成某个结果。这个结果通常由两件事组成：

判断结果：流水线通过、失败或给出不确定的结果（这里永远都应该使用“失败”/“通过”，不能用“不确定”。我将在后文具体说明原因）。
所有相关工件：已部署的应用程序、二进制文件、日志文件等我们关心的所有内容。

任务

本质上来说，任务是一个命令行（shell）脚本或程序，在某台机器（本地或云端）上自动运行，执行一些任务（有时候很多任务彼此相关，比如编译、运行、测试等），并返回一段特殊的命令行“退出代码”。

通常来说命令行中的零退出代码表示成功。任何非零退出代码都表示失败。由程序或脚本决定退出代码是哪一种。

CI/CD服务器

像Jenkins这样的工具（一般称“持续集成服务器”或用于“持续交付”的“CI/CD服务器”）充当这些任务之上的抽象层。CI服务器让我们可以轻松地运行这些任务（基于特殊的代码提交触发器或规划方案），并监听任务的退出代码及其输出（日志）。

然后服务器会解析日志，并为我们提供一个友好的UI来显示结果、错误日志和各种工件。

CI/CD服务器使我们能在一处集中管理任务并监视其运行进度，还能同时在许多机器上运行很多任务（有时称为“构建代理”）。

流水线驱动

所谓“流水线驱动”，是说我们希望更多地依靠流水线制定与代码及其工件相关的技术决策（判断），然后让流水线立即根据这些决策尽可能自主地行动。

在软件开发行业，人们通常要做出两种不同类型的“决定”：

战略判断，例如：
- “我们应该制造这种产品吗？”
- “我们应该关注这个功能吗？”
战术判断，例如：
- “我们应该合并这个分支吗？”
- “我们应该部署到这个环境吗？”
- “我们应该发起/销毁一个环境吗？”
- “这个功能正常吗？
- “应用程序安全吗？”
- “我们搞出了新的错误吗？”

流水线是战术层面的

我认为流水线很适合作出战术性的日常判断和行动，而人类更适合战略层面的工作。如果有人找到一种方法让流水线来决定他们的下一个产品应该是什么，不需要人类来签字许可，那肯定皆大欢喜。但我认为这种事情是不可能用决策算法来处理的。

战术层面的事务通常更适合用机器来检查：这类事务往往会重复执行某些操作，不会跳过其中的步骤；还会验证一系列清单；收集和分析数据以获取特定数值等。

这些决定与以下内容有关：

我们代码的健康度和功能
环境
质量
安全
合规
运营
部署

…… 以及与软件开发生命周期相关的其他事项。

如果让流水线取代人类做出这些判断（我们在传统的敏捷和瀑布组织中都是让人来做决定），我们可以获得以下好处：

做出更快的决策/判断
更可靠的重复决策
减轻压力
实现真正的持续交付

更快的判断

流水线之所以能比人类更快做出决定，有两大原因：

在具体的事实层面，计算机的计算速度比人类快
当计算机要决定是否合并分支或启用环境或部署应用时，它不会感到压力或焦虑或惴惴不安的感觉

更可靠的重复判断

流水线在重复事务上作出的决策更加可靠，也有两大原因：

计算机非常适合浏览一长串事物并验证每一件事情，而不会忘记某个项目，或每次作出不一样的检查
计算机不会感到无聊、烦恼或者因为某项检查连续十次失败而感到沮丧，或者抱怨为什么没有人为此负责，抑或是冒出来一些念头：“快拉倒吧，我要回家看孩子去，再也不想管这个了。“

减轻压力和焦虑

在一家有着漫长而艰苦的人工测试流程的公司工作压力是很大的，尤其是新版本发布之前开特别会议的时候，管理团队盯着测试团队的头头，问他们：“这个版本准备好发布了吗？”——压力山大！

测试团队的领导是很好的心理学研究对象。想象一下必须你来签字决定新版本是否投入生产——这时候你就是大家的代码与全世界之间的最后一道防线，你会是什么感受？

实现真正的持续交付

最后我们来看它的核心优势。

持续交付是一种软件工程方法，团队要在较短的周期内生产软件，确保软件可以随时可靠地发布。

我认为，成功实现持续交付的关键是消除战术决策链中的人为瓶颈，使流水线几乎能够自主地决策并推动代码前进，直到生产发布环节；没有人类的恐惧和怀疑这些绊脚石后，我们就能更快获得关于我们代码表现的反馈。

教会流水线自行驱动工作

为了能够完全信任流水线，使我们可以依赖它的决策，我们需要教会软件流水线在无人参与的前提下自行做出战术判断。每当我们的流水线学会了一项新的战术决策，我们就消除了一项人为瓶颈，在实现真正的持续交付的道路上更进一步。

所谓教育，是说我们要在流水线中添加自动化步骤、脚本和质量关卡，根据我们关心的各种结果或指标决定一系列步骤是失败还是通过。具体来说可以有下面几种形式：

基于自动测试的结果判定失败/通过
基于正在测量的特定度量标准判定失败/通过（例如代码覆盖率急剧下降）
基于子流水线或并行流水线的结果判定失败/通过
基于日志文件判定失败/通过
（如果你有更多想法，请发送电子邮件至[rooe at osherove.com]）

像Netflix、谷歌和亚马逊这样的组织就可以算是流水线驱动的；他们让团队中的流水线做出日常战术判断，并自动执行相关的操作，无需人力干预（参见“在Netflix和Waze使用Spinnaker实现大规模持续交付（Cloud Next '18））。

他们不再让某人每分每秒盯着战术工作并作出决策，而是让流水线推动工作进程。然后人们负责教导流水线作出自动判断和制定战术决策，从而打破了许多战术流程中的人为瓶颈。

流水线驱动流如何改变日常工作

传统上（非流水线驱动），流水线会“询问”或“通知”人们是否一切正常（测试通过、编译通过等）。然后，人们必须决定是否可以开始下一步，然后点击按钮来触发独立的流水线或作业。

如图：传统的敏捷流水线被知识岛和人工决策分隔开来，由人来决定是否在SDLC流程中触发下一条流水线。

在流水线驱动的流程中人们完全信任流水线，这样如果一切正常就会自动触发下一步。这里的假设是流水线知道如何正确判断某些事务是否正常，所以只需继续下一个动作，不用等待人类去触发。

在上图中，你可以看到组织中的各种知识岛负责在自动化流水线中嵌入决策逻辑。作为流水线执行的一部分，决策会自动执行，无需等待“外部”人们的批准或手动操作。

新世界需要新技能

我们在尝试采用敏捷流程时经常会遇到的四大知识岛，如下图所示；每个岛都有一项与他人相关的有价值的技能，需要其他岛上的人们学习。

开发技能：流水线是自动运行的代码片段，因此与流水线相关的一项主要技能就是学习基本的编码技术。如果你不会写任何代码，连简单的完全自动化基础架构的脚本都不会写，那么你就无法为流水线做出任何贡献，也无法了解它的工作机制及故障原因。。
测试技能：所有流水线都是一个巨大的测试项目。结果要么是红灯要么是绿灯。它是由一系列“步骤”组成的——每一步都是对其中的内容和步骤本身的一种测试。如果某一步失败了，那么流水线也会失败（或者应该失败）。向流水线作贡献就是在其中添加步骤或测试，而且这些测试/步骤是用代码编写的。因此你不仅需要知道怎样写代码，还需要知道如何编写可以在流水线中运行的测试。你需要有一种测试心态——要能帮助设计并创建自动测试，而不是手动检查某些内容。
运营技能：大中型公司的流水线传统上属于运营领域和开发人员。但是，如果我们希望人们能为流水线贡献测试，则他们需要知道流水线的基本工作机制，知道如何理解它们的输出、如何配置（添加和删除它们的步骤）、如何访问以及如何运行这些流水线。
安全技能：安全性是一组技能和思维方式，涉及代码、基础架构、配置和部署等方方面面。这意味着传统上生活在自己的孤岛中的安全人员必须开始分享他们的安全知识，因为在这个全新的世界中每个人都拥有更多的权力，需要承担更多责任。我们允许所有人触碰流水线并编写在其中运行的代码。所以要教他们在所有事务上都要考虑安全性。

我们还可以继续扩展这个列表，添加更多技能，但篇幅所限这里就不提了。我会在我的博客上深入探讨这些内容。

如图：在每个知识岛上我都指出了（用彩色圆点）来自其他岛的相关技能，也是各个岛上的人们需要学习改进的技能。

总结：这对你来说意味着什么？

无论你喜不喜欢，流水线都将越来越普及。组织为了增强自身的竞争力，对流水线驱动的需求也会增加。

这意味着知识共享、自动化能力、测试能力和编写代码的能力会在你的工作中发挥重要作用，而缺乏这些技能会影响你在业内的表现和潜力。

许多组织都在试图实现持续集成或持续交付，但他们都遇到了障碍：流水线之间存在太多人为瓶颈，让人决定软件流程能否继续到下一步（部署，测试等）会大大降低效率。

如果能教会流水线做出更好的决策，取代人类作出判断，我们就能让流水线在生产流程中自动工作，通过它们（如果它们连续运行）创建真正的连续交付机制。

如果流水线失败——取消新版部署。如果它通过——我们就部署新版本。完全不用人操心。

今天只有少数公司，诸如像亚马逊、Netflix、谷歌等组织完全实现了这一愿景。我认为他们之所以能实现现在这种规模和速度，部分原因正在于此；他们将人类移出战术决策过程，人类只负责教会流水线来完成他们的工作。

你可以在Roy的博客或Twitter上阅读有关流水线驱动组织的更多内容。

作者介绍

Roy Osherove是即将出版的新书《流水线驱动》的作者。他还是《弹性领导：发展自组织团队》和《单元测试艺术》的作者。Osherove曾在一些世界上最大的公司从事软件开发方面的许多工作。如今，他为全球各地的企业担任自由顾问、培训师和教练，工作内容包括测试驱动开发、敏捷技术领导、持续交付以及基于流水线的组织的有效指标等。在这里可以找到更多关于他的信息。

原文链接：

The Pipeline Driven Organization - Enabling True Continuous Delivery

创作场景

流水线驱动组织：实现真正的持续交付