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 服务器俨然腐化成了老马所说的雪花服务器 (snowflake server)。雪花服务器有两点显著的特征：
- 特别难以复现
- 几乎无法理解
第一点是由于以往所做的更改并没有被记录下来，所以做过的操作都是七零八落的，没有办法复现同样的操作，也无法复制一个同样的系统。
第二点则是由于绝大部分情况下散乱的配置是没有文档描述的，哪部分是重要的已经无从知晓，改动的风险很大。
这些问题会在流水线的演化过程中恶化得越来越严重。一般来讲，除非不再使用，否则流水线不会保持一成不变。具体实施过程中，考虑到项目，尤其是遗留项目当前的特点和团队成员的“产能”，我们会先将构建和部署自动化；部署节奏稳定后，开始将单元测试和代码分析自动化；接着可以指导测试人员将验收测试自动化；然后尝试将发布自动化。在这之后，就要开始持续优化流水线，包括 CI 的速度和稳定性等。换句话说，流水线的演化其实是和项目的当前进展密切相关的，保证这样的对应关系有时是有必要的，比如：在版本控制下，多发布分支所需流水线和主干分支会存在不同。发布分支是主干分支某个时刻分出去的，它需要在那时的流水线上才能正常工作。由于前面所说雪花服务器的特征，重建这样一条流水线并不是一件容易的事情。
如何解决
其实，流水线即代码本身已经回答这个问题了。当前实现了这一概念的工具大体遵循了两种模式：
- 版本控制
- DSL（领域特定语言）
对于特别难以复现、没有保证对应关系的痛点，我们就把流水线写成代码放到版本控制工具中管理起来。这样一来，每一次更改都能被记录下来，而且它会始终和此时的项目进展保持同步。
对于几乎无法理解、没有文档支持的痛点，我们就选用领域特定语言描述整条流水线。举个 Jenkins 2.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') {…}
}
Jenkins 2.0 使用Groovy实现了一套描述流水线的DSL，即便不了解Groovy语言，只要对流水线稍微熟悉，就能按照例子和文档编写出符合要求的代码。
类似的工具还有Concourse.ci、λCD (LambdaCD) 等。
Concourse.ci 使用了 yaml 实现了DSL，独立抽象出Resource（外部依赖，如：git repo）、Job（函数， get 和 put Resource ）和 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 服务，一套用于部署自身，另一套部署开发中的工程。
小结
流水线即代码是个新概念，也就意味着我们还需要花时间去探索与之相关的实践，比如，调试和测试（既然是代码就需要测试）。一旦有了这些实践，我们就可以把流水线本身作为产品放到流水线上运作起来，那时将会看到一种很好玩的现象——旧的流水线会构建并部署新流水线，完成流水线的自举 (pipeline bootstrap) 。此外，当流水线成为代码，它在最终的交付物中必然占据一席之地，其潜在的价值还等待我们挖掘，至少从精益的角度，流水线能做的事情还有很多。
