A的构建流水线

产品A的构建流水线自动化了从编译、静态检查、打包、在不同环境下进行部署

并运行自动化测试、发布产品包以及完成最后部署整个过程。从开发人员提交修

改到源代码库中那一刻开始，剩下的所有步骤都由构建流水线自动完成。

开发人员在开发过程中，首先会在开发环境中完成开发验证，自动化测试的编写、

调试和修改，TDD，自动化构建脚本的编写，部署脚本的编写等，都在开发环境

中完成。这里是所有修改的入口，所有验证的初始发生地。我们应该尽量做到所

有的开发和验证都能够在开发环境中完成。

而当开发和验证完成，确认修改正确后，就可以将代码提交到源代码库中。持续

集成服务器持续监视着代码库的修改情况，自动将最新的修改更新到持续集成环

境中，开始从编译打包到部署的一系列自动化过程。

以A产品为例，这个自动化过程包含了若干个阶段，之所以分成若干个阶段，是

为了更加直观地展现这个过程。后面我们会谈到，因为优化的关系，不同产品的

构建流水线可能形态上会有些不同，但是它们都包含了如下几个重要阶段。

首先是打包阶段。打包是一个笼统的说法，其本质是将应用准备成能够在生产环

境中部署的形式。capistrano部署rails应用直接将源代码checkout到生产环境，

j2ee则规定了web应用必须以war包形式部署到容器中。这两种形式虽然都能够实

现部署的目的，但是更好地是将产品以产品包的形式发布出去，例如对linux平台

以rpm或者deb包的形式发布。

不论产品选择何种形式发布，有一个需求是共同的。所有产品都必需能够支持在

安装后、服务启动前对配置文件进行修改。war包是不符合这个要求的，因为配

置文件被包含在war包中，只有j2ee容器启动之后才能修改其中配置文件(现在

有一些办法能够将war包中的配置文件从war中提取出来)。

在打包之前，还有必要对包的可用性进行尽可能充分的验证。静态检查、单元测

试等任务可以在打包之前进行，如果功能测试成本不高，甚至也可以考虑放到打

包之前运行。这样，我们可以对打出来的包的功能有一定的信心。这种信心对提

升整个构建流水线的效率和正确率是很重要的，因为越往后的阶段成本相对来说

越高，反馈越慢，因此前面的阶段验证越充分，后面的阶段成功的可能性越大，

而失败之后的错误追踪也更加容易。

打包之后我们就可以将产品包部署到staging环境下进行功能测试。这个阶段的

任务首先是要准备一个干净的staging环境。为此我们必须首先准备好必须的服

务器以及网络环境，然后安装操作系统并作基本的系统配置(例如DNS等)，然

后利用我们的部署脚本和产品包将产品部署到环境中去。

这个过程中很重要的一条原则就是在staging环境中和生产环境中所采用的部署

方法必须一样，是同一种方法，同一套脚本，同一组产品包。只有这样我们才能

够有信心将经过验证的产品包放心地用这一套脚本部署到生产环境中去。这就类

似于前面提到的环境相似度原则，用于staging环境的任何部署脚本、产品包如

果有和生产环境不同的地方，都有可能在生产环境中导致问题，这些问题必然会

成为我们持续部署的阻碍因素。

在环境部署好之后，就可以对环境中的产品运行功能测试。如果这些测试全部通

过，那么我们就可以选择将部署脚本和产品包发布到仓库(repository)中去。

这些交付物(artifact)会在之后的测试、部署中被用到，同时其他产品团队也会

需要这些交付物去部署它们自己的环境，进行集成测试等。

接下来是在e2e环境中的测试。首先自然也是要准备好所需要的服务器等基础设

施，然后将集成测试所涉及的所有产品都部署到该环境中去，再运行测试。

部署集成测试环境需要各产品都提供完善的部署手段，换句话说所有的产品都必

须提供能够将自己部署到一个干净环境中去所需的包、脚本、工具等。

如果集成测试也通过，那么我们就可以选择将产品包部署到实际生产环境中去了。

这一过程所包含的具体内容，视不同产品的复杂程度、生产环境的特点、组织的

策略等，可能会有很大的不同。

构建流水线的各个阶段之间的触发方式，通常是自动的，上一个阶段成功之后，

下一个阶段就会被自动触发执行。但是在某些情况下，有些阶段的触发可能是手

动的。例如publish和deploy两个阶段，在很多情况下可能是手动的。deploy阶段

的触发，因为涉及到生产环境的安全性，还往往可能需要触发的时候进行身份验

证。