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 script which can be invoked by a single command. This script 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)。雪花服务器有两点显著的特征：
- 特别难以复现
- 几乎无法理解
***点是由于以往所做的更改并没有被记录下来，所以做过的操作都是七零八落的，没有办法复现同样的操作，也无法复制一个同样的系统。
第二点则是由于绝大部分情况下散乱的配置是没有文档描述的，哪部分重要、哪部分不重要已经无从知晓，改动的风险很大。
这些问题会在流水线的演化过程中恶化得越来越严重。
一般来讲，除非不再使用，否则流水线不会保持一成不变。具体实施过程中，考虑到项目，尤其是遗留项目当前的特点和团队成员的“产能”，我们会先将构建和部署自动化;部署节奏稳定后，开始将单元测试和代码分析自动化;接着可以指导测试人员将验收测试自动化;然后尝试将发布自动化。
在这之后，并未结束，团队还要持续优化流水线，包括CI的速度和稳定性等。换句话说，流水线的演化阶段其实是和项目的当前进展密切相关的，保证这样的对应关系有时是有必要的，比如：在多分支的版本控制下，发布分支所需流水线和主干分支会存在不同。发布分支是主干分支某个时刻分出去的，它需要在那时的流水线上才能正常工作。由于前面所说雪花服务器的特征，重建这样一条流水线并不是一件容易的事情。
如何解决
其实，流水线即代码本身已经回答了这个问题。当前实现这一概念的CI/CD工具大体遵循了两种模式：
- 版本控制
- DSL(领域特定语言)
对于特别难以复现、没有保证对应关系的痛点，我们就把流水线写成代码放到版本控制工具中管理起来。这样一来，每一次更改都能被记录下来，而且它会始终和此时的项目进展保持同步。
对于几乎无法理解、没有文档支持的痛点，我们就选用领域特定语言描述整条流水线。举个Jenkins2.0例子，它允许我们在项目的特定目录下放置一个Jenkinsfile的文件，内容如下：
- node('master') {
- stage('Checkout') {…}
- stage('Code Analysis') {…}
- stage('Unit Test') {…}
- stage('Packing') {…}
- stage('Archive') {…}
- stage('DEV') {…}
- }
- stage('SIT') {
- timeout(time:4, unit:'HOURS') {
- input "Deploy to SIT?"
- }
- node('master') {…}
- }
- stage('Acceptance Test') {
- node('slave') {…}
- }
Jenkins2.0使用Groovy实现了一套描述流水线的DSL，我们即便不了解Groovy语言，只要对流水线稍微熟悉，就能按照文档中的例子编写出符合要求的代码。
类似的工具还有Concourse.ci、λCD(LambdaCD)等。 Concourse.ci使用了基于yaml的DSL，独立抽象出Resource(外部依赖，如：git repo)、Job(函数，对Resource进行get或put操作)以及Task(纯函数，必须明确定义Input/Output)模型。效果图如下：
而λCD则使用Clojure语言实现了DSL，抽象出Pipeline和Step模型，使用了Lisp特有的宏(macro)扩展和自定义普通函数，编写起来简单明了。如下：
- (def pipeline-def
- `(
- (either
- manualtrigger/wait-for-manual-trigger
- wait-for-repo)
- (with-workspace
- clone
- (in-parallel
- run-some-tests
- run-smokeing-tests)
- run-package
- deploy)))
上述的pipeline-def就是这条流水线的定义，极为优雅得是，它的代码和UI事实上构成了——映射的关系，简单到***。
值得一提的是，λCD有别于其它同类型的工具，它本身就是一份用Clojure写就的微服务。换句话说，其它的工具可能需要借助基础设施即代码完成自身的安装，但λCD不用，它完全可以采用其它微服务的部署方式，比如用λCD部署它自己，类似于编译器的自举(bootstraping)。这个时候，我们就需要两套λCD服务，一套用于部署λCD自身，另一套部署开发中的工程。
小结
流水线即代码是个新概念，也就意味着我们还需要花时间去探索与之相关的实践，比如，调试和测试(既然是代码就需要测试)。一旦有了这些实践，我们就可以把流水线本身作为产品放到流水线上运作起来，那时将会看到一种很好玩的现象——旧的流水线会构建并部署新流水线，发生上文所说自举(bootstraping)现象，这也表明流水线是不断进化的。
此外，当流水线成为代码，它在最终的交付物中必然占据一席之地，其潜在的价值还等待我们挖掘，至少从精益的角度，流水线能做的事情还有很多。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
