背景

在一次DevOps线上活动的提问环节中，有这样一个问题：“我们公司刚刚完成了DevOps转型，搭建了一条流水线，流水线确实让我们部署上线的效率提升了，但是也更快的让客户当上小白鼠，因为我们让问题更快的暴露出来了……”

可以想象，一个开发人员开心的点了一下流水线的启动按钮，然后就开心的下班了，然后用户看着屏幕的404，然后就没有了然后（坏笑）……

其实这真不是开玩笑，如果将项目中的流水线发布权限下放给了开发，那么404真的就是很现实和普遍的问题，因为很多开发认为自己的工作就是开发。

像这样的坑你是否也掉进去过，我们一起基于此，来看看什么样的流水线是不坑人的吧。

问题分析

这些年来，DevOps已经逐渐的深入到软件企业中，尤其是一些互联网的项目中，需要更快的适应市场的变化迎合用户的需求，传统低效的方式来部署生产环境已无法存活， DevOps的流水线（部署流水线）也应运而生。然而在企业追求高效的同时，往往又引入了新的问题——高效的将bug展现给了用户。

项目开发的前期，代码都是比较简单的，开发团队的人员也比较少。但慢慢随着时间的推移，代码越来越复杂，团队成员越来越越多，经手变更的也越来越频繁。一旦出现了问题，作为一个开发人员往往首先会想到的是——快速修复上线。DevOps在速度这点上确实帮了大忙，经历过传统部署发布的同学肯定深有体会。但是这样往往却又伴随了新的问题——“打地鼠现象”。

何为打地鼠现象? 简单的说，就是一个问题你修复了，可能又会蹦出来几个新的问题。长期下去，不仅开发团队压力大，客户更是成了“小白鼠”。

其实，这并不能把问题归结到部署流水线身上（无辜躺枪），借助流水线的快速发布，只是将问题更早的暴露出来，其归根结底上，问题还是出在质量上。

那么，我们就不得不谈到——质量内建。

戴明（William Edwards Deming）曾提出“问题发现得越早，修复的成本越低”，有数据指出

85%的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在之后的测试阶段发现的，甚至是已经上线后。而且随着越往后发现缺陷，修复的成本也越高。

按照STICKYMINDS网站上上的一篇名为The Shift-Left Approach to Software Testing的文章中所给出的（如上图），假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这可以说是很难让人接受的，所以质量内建是至关重要的。在质量问题上，当然离不了我们老生常谈的开发阶段的编码规范、重构、检视等活动，这里不做叙述。

随着DevOps的引入，我们需要将质量内建，加入到DevOps的各个环节中，而部署流水线就是贯穿这些环节的重要工具。某种程度上说，部署流水线的质量基本上决定了软件质量——是带伤上阵还是安稳的睡大觉，部署流水线是关键。

那么如何算是一条不坑的部署流水线呢？

解决方案

测试左移（Shift-Left testing）

如上面所提到了，在开发完成后，越到生命周期的后面修复的成本越高。那么基于这样的情况，测试应该尽早的开始。在传统的开发周期中，问题都在什么时候发现的呢？如下图所示：

可以看到传统模式下，问题很少会在开发阶段发现，而现在提出的测试左移，就是在要在开发阶段尽可能的发现更多的问题，而避免问题被发现在之后的阶段。

这也就是我们搭建一条不坑的流水线最基本的理念之一。

一般来说，在流水线的构建阶段我们会加入静态代码检查，比如使用Findbugs、Sonar等。可按需自行设置是否随代码提交而触发检查（推荐），或伴随持续集成的工程实践开展，可一天一次或多次，这就保障了不会掉进最基本静态代码层面的坑。

此外在流水线的设计上一定要有API、UI等自动化测试。一般来说，可按部署到不同的环境，对应创建不同的流水线阶段，如集成环境有对应的流水线的集成阶段，测试环境有其测试阶段。当部署时，就可以在对应的阶段中加入所需要的测试活动。如当开发人员修复某一个bug后，想要保证其他功能的成长，可以通过在流水线的自测阶段通过加入API的测试等。

总结来说，就是在流水线的构建阶段加入静态代码的检查，在部署阶段加入自动化的测试活动，以保证代码的质量和功能的可用。

质量要求

在质量建设中，不能仅停留在质量管控的基本要求——有，还要注重质量的高低。因为某种意义上来说，较松的管控等于没有，这也是最坑的地方——有等于没有，试想如果流水线中只有某个API测试的情况，那么验证的基本就是这个服务有没有成功启动而已。

那么，这就需要加入一个质量阀值的要求。质量阀值的高低是一个衡量质量高低的重要标准。这个阀值可以是接口覆盖率达到多少，也可以是静态代码检查出来问题的数量等。一个严格的质量门禁可以说流水线完成后发布上线的定心丸，这也就可以用来解决了上文提到的“打地鼠”现象。

一般来说，接口测试的覆盖率建议达到百分之百，而考虑单元测试和接口测试某些程度上的重复以及UI测试的ROI等因素可按需进行配置，因情况不同这里不做叙述。

对于代码检查来说，也可设置某一个数值作为阀值，这个数值可以按照某种规则设定。如一般问题记1分，严重问题记5分，安全问题记8分等，当检查后所累积的数值超过10则不能发布或进入下个一个阶段，当然数值越低越好，具体设置（代码检查的维度不再此叙述）也需按实际情况而定。

此外，还可以考虑如开源第三方jar包的扫描、安全漏洞扫描等活动。如果考虑划分的更有层级和模块化，相对于接口测试或静态代码检查的质量建设，扫描的可以单独作为一个阶段按需设置。

总结来说，质量建设按照项目的实际情况来设置，而且对于团队来说，质量永远不仅仅是某一个人或团队的事情，而是所有人的事情。相对于质量的坑来说，意识上更是我们应该避免掉进的坑。

如了解更多请访问华为DevCloud流水线的内容，详见附录。

这里提到了意识，意识是关乎人的主观性层面的了，那么应用在流水线上，其实也是需要考虑的。诚然有些时候我们依赖于机器和自动化，如上面说提到的接口测试、安全扫描等。但是也不能完全依赖于自动化，比如我们也需要人工的代码检视活动。这在搭建流水线的时候也可以考虑到把人工环节加入到其中，比如在发布到生产环境的阶段增加一个发布看板，其中包含了是否有人工代码的检视以及检视出来的代码的质量的阀值或要求等。

综上，一条流水线除了必须的、按需的自动化+人工以外，还需要在实践的过程中不断的总结结合自身特点加以定制，然后才能放心大胆的点击“启动”而不被坑。最后引用姚东老师文章中的一句话“流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。”这也是笔者非常认同的，也相信搭建实现这一目标，提供这能力的流水线才能更好的实现持续交付，配合好我们的DevOps转型。

参考附录

测试左移

以终为始，再谈持续交付流水线

DevCloud的HE2E DevOps的流水线构建