文／鄢倩

　　2016年11月份的技术雷达中给出了一个简明的定义：流水线即代码(Pipeline as Code)通过编码而非配置持续集成/持续交付(CI/CD)运行工具的方式定义部署流水线。其实早在2015年11月份的技术雷达当中就已经有了类似的概念：

　　The way to avoid programming in your CI/CD tool is to extract the complexities of the build process from the guts of the tool and into a simple which can be invoked by a single command. This can then be executed on any developer workstation and therefore eliminates the privileged/singular status of the build environment.

　　大意是将复杂的构建流程纳入一个简单的脚本文件，然后用一条命令调用。这样，任意的开发者都能在自己的工作区中执行脚本重建一套一模一样的构建环境，从而消除CI/CD环境由于散乱配置腐化而成的特异性。

　　这么做的原因很好理解，使用CI/CD工具是为了暴露产品代码中的问题，如果它们自身已经复杂到不稳定的地步，我们还使用它就是自找麻烦。

　　从某种程度上看，实施流水线即代码是不证自明的。在CI/CD的实践过程中，凡是可以被编码的东西都已经被代码化了，比如：构建、测试、数据库迁移、部署和基础设施/环境配置(Infrastruture as Code)等。说得烂俗点，流水线已经是CI/CD实践过程中的“最后一公里”，让流水线变成软件开发中的“一等公民”（即代码）是大势所趋、民心所向。

　　不过，这种论断毕竟欠缺说服力，我们接着从实践的痛点出发总结当前流水线遇到的问题。

　　实践中的痛点

　　我给客户搭建和配置过不少CI/CD流水线（被同事戏谑地称为“CI/CD搭建兽”），最大的痛苦莫过于每次都得从头来过，即便大部分情况下所用的工具和配置都大同小异。

　　其次是手工操作产生的(configuration drift)。以Jenkins为例，暂且不谈1.0版本无法直接支持流水线这一问题，为了支持构建、测试和部署等，我们一般会先手工安装所需插件，在多个文本框中粘贴大量shell/batch脚本，下载依赖包、设置环境变量等等。

　　久而久之（实际上用不了多久），这台Jenkins服务器就变成无法替代（特异化）的“怪兽”了，因为没人清楚到底对它做了哪些更改，也不知道这些更改对系统产生了哪些影响，这时的Jenkins服务器就腐化成了Martin Fowler口中的(snowflake server)。雪花服务器有两点显著的特征：

特别难以复现

几乎无法理解

　　第一点是由于以往所做的更改并没有被记录下来，atv直播，所以做过的操作都是七零八落的，没有办法复现同样的操作，也无法复制一个同样的系统。

　　第二点则是由于绝大部分情况下散乱的配置是没有文档描述的，哪部分重要、哪部分不重要已经无从知晓，改动的风险很大。

　　这些问题会在流水线的演化过程中恶化得越来越严重。

　　一般来讲，除非不再使用，否则流水线不会保持一成不变。具体实施过程中，考虑到项目，尤其是遗留项目当前的特点和团队成员的“产能”，我们会先将构建和部署自动化；部署节奏稳定后，开始将单元测试和代码分析自动化；接着可以指导测试人员将验收测试自动化；然后尝试将发布自动化。

　　在这之后，并未结束，团队还要持续优化流水线，包括CI的速度和稳定性等。换句话说，流水线的演化阶段其实是和项目的当前进展密切相关的，保证这样的对应关系有时是有必要的，比如：在多分支的版本控制下，发布分支所需流水线和主干分支会存在不同。发布分支是主干分支某个时刻分出去的，j2直播，它需要在那时的流水线上才能正常工作。由于前面所说雪花服务器的特征，重建这样一条流水线并不是一件容易的事情。

　　如何解决

　　其实，流水线即代码本身已经回答了这个问题。当前实现这一概念的CI/CD工具大体遵循了两种模式：

版本控制

DSL（领域特定语言）

　　对于特别难以复现、没有保证对应关系的痛点，我们就把流水线写成代码放到版本控制工具中管理起来。这样一来，每一次更改都能被记录下来，而且它会始终和此时的项目进展保持同步。

　　对于几乎无法理解、没有文档支持的痛点，我们就选用领域特定语言描述整条流水线。举个Jenkins2.0例子，它允许我们在项目的特定目录下放置一个Jenkinsfile的文件，内容如下：