持续交付概述

AlexQin

4 持续集成

持续集成作为敏捷方法的一项核心实践，由来已久7。在持续 交付中，持续集成服务器将从开发到部署过程中各个环节衔接起来，组成一个自 动化的构建流水线(build pipeline)，作为整个交付过程的中枢，发挥着至关重 要的作用。
前面说过，我们希望我们对软件的修改能够快速、自动化地经过测试和验证，然 后部署到生产环境中去。在自动化测试和环境都具备情况下，开发人员除了在本 地运行自动化构建进行验证外，剩下的工作就主要由持续集成服务器来帮忙完成。
目前市面上有很多持续集成服务器软件，例如jenkins，go，bamboo， cruisecontrol，travis-ci等，这些软件有的支持构建流水线的概念，有的有构 建流水线插件，持续集成服务器主要通过调用产品的自动化构建脚本8来执行你 所配置的各阶段任务。
我们先以A产品的构建流水线为例，看看其中主要有什么样的内容。

AlexQin

4.1 单个产品的构建流水线

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阶段 的触发，因为涉及到生产环境的安全性，还往往可能需要触发的时候进行身份验 证。

AlexQin

4.1.1 提交门限的概念

从构建流水线图中我们可以看到，持续集成服务器是在不断监视着源代码库的变 化，一旦有人提交就会触发构建过程，如果其中发生问题，则会将结果反馈给团 队。整个构建过程通常会需要一段时间，我们希望整个构建过程的成功率尽可能 高，或者更准确点讲，尽量反映开发人员在本地开发环境中无法验证或者发现不 了的问题。
因此我们希望开发人员在将修改提交到代码库之前，能够在自己的开发环境中进 行充分的验证，至于不同开发人员之间的修改的集成、更复杂环境下产品的验证 这些在本地环境中较难低成本验证的东西，构建流水线会帮助我们提供反馈。但 是如果本地验证不够充分，甚至不作本地验证就随意将代码提交，构建流水线就 可能会被大量低级错误所充斥，大部分时间处于失败状态，最后就像被DDoS了攻 击一样，失去了给团队提供更有价值反馈的能力。
所以，团队内的开发人员应该首先在本地进行充分验证，然后再提交。多充分算 充分呢？这基于所验证内容的成本和团队的共识。如果所有构建内容能够在本地 10分钟之内执行完成，我们就可以约定提交之前必须在本地执行所有构建内容； 反之如果整个构建过程耗时超过30分钟，每次提交前都执行全部构建就会严重拖 慢开发进程，打乱开发节奏，这种情况下团队可以约定将一部分内容作为提交前 必须执行的内容。
这种整个团队为了提高构建流水线的成功率，约定的在提交前必须执行并保证通 过的构建内容，就成为构建门限，或者成为本地构建。很明显，本地构建占整个 构建过程的比重越大，团队就能越早在本地就得到尽可能多的反馈，整个持续交 付过程就更加流畅。
然而本地构建的一个重要要求就是要耗时短。有时候可以通过构建的优化来减少 构建时间，不同产品的特点不同，构建复杂度以及时间也会有区别。

AlexQin

4.1.2 构建流水线的优化和变化

我么以A产品为例讨论了它的构建流水线(见图)，然而我们给出了构建流水线设 计并非是唯一的方案。构建流水线的目标，那就是能够给团队以持续部署的信心。 在满足这个目标的前提下，流水线的具体实现形式可能会有不同程度的变化。
整个构建流水线各阶段的执行时间是影响其设计的一个重要因素。如果package 和staging两个阶段可以在5分钟内完成，也许我们不需要把它们分成两阶段来获 得反馈。如果A没有和其他任何产品的集成，那么e2e测试阶段也可以去掉。对于 更加简单的应用，也许只要一个阶段就可以包含所有的构建内容。
另一个因素是整个过程的组织形式和视觉呈现要求。将不同的构建内容显式分成 不同的阶段可以对各阶段的反馈有更明确的了解。特别是在某些阶段需要手动触 发时，这种阶段的分隔就更加有价值了。
不管怎么优化，都必需遵循构建流水线的基本目标原则，如果优化的结果过度偏 离了它的目标，就不再是优化的问题，而是能否起作用的问题。

AlexQin

good job