为了让它更加明确，让我们看看当一个具体的变更传到系统时，将会发生什么事。举个例子：

开发团队接到任务，要给企业的系统做一个变更。这个变更的主要内容是给鉴权系统增加一个新角色。这个看似简单的任务其实没那么容易，因为这个变更将会影响许多其他不同的系统。

为了更加顺利地开发，大家决定将这个变更拆分成几个小变更，这样它们就可以被以回归测试为主的自动化测试分开验证。

开发人员在自己的电脑上开发并且在本地尽力测试了第一个变更——新增角色。

为了真正地了解它是否可用，开发人员需要他／女也本地环境以外的系统权限。在这里指的是一个里面有用户和角色等信息的LDAP服务器。

如果使用测试驱动开发，在写实际代码之前会先编写一个通不过的测试。在这个测试写完之后，才编写能让这个测试通过的新代码。

开发人员将代码提交到企业内部的Git版本控制系统上。

构建服务器获取到了这个变更并初始化构建流程。单元测试之后，这个变更被认为可以被发布到Nexus的二进制库里。

配置管理系统Puppet发现鉴权组件有了一个新的版本。由于集成测试服务器被配置为总是使用最新的版本，于是Puppet勇往直前安装了最新的组件。

新组件的安装触发了自动化回归测试。在这些测试成功结束之后，质量保证团队就开始做人工测试。

质量保证团队给这个变更盖上“已通过”的章。变更转向预发布服务器，在这里开始了最后的验收测试。

当验收测试完成后，预发布服务器被切换成了生产环境，而生产环境转变成了新的预发布环境。企业的负载均衡服务器管理着最后的这一步。

这个流程按需一遍遍地重复着。就像你看到的那样，有一大堆的事情呢。