企业持续集成成熟度模型简介之二——部署

 出差在外，没有及时更新Blog。继“构建”之后，今天再说一下企业持续集成成熟度模型的另一个维度“部署”。在正文之前，还想再强调一点，即“这个模型本身是是工具箱里的一件工具，并不一称个斤两的量器。”

 

 

---

部署

 

部署是指将软件移动到它被测试的地方，或用户指定的某个位置，准备送给客户。对于web应用来说，这可能意味着将软件安装到某个web服务器上，并更新数据库或静态内容服务器。而对于一个视频游戏来说，这个测试部署可能是指安装这个软件版本到某些测试机器上，而产品部署则可能是指烧录一个光盘并给发行商。

部署最开始一般都是手工过程。部署工程师从某处拿到部署文件，再把它放到目标机器上，然后开始正式的安装过程。然而，这种手工过程会比较慢，而且部署失败率也可能要高一些。工程师常常被迫在晚上或周末加班，进行测试环境或生产环境的部署，因为这些环境平时需要正常运行，不能轻易地停止。更糟糕的是：每个环境很可能使用了不同的步骤进行手工操作（比如步骤前后顺序颠倒，这尤其容易发生在不同的操作人员之间），几乎无法保证：在某个环境上的成功部署表明在下一个环境中部署成功的可能性也同样高。

对于团队来说，抛弃完全的手工过程，使用一些辅助脚本或全过程脚本化是一个非常巨大的进步。纵观整个行业，大多数团队都会有一些辅助性脚本，但有完全脚本化部署方式的团队较少，特别是在受控环境中（如试运行环境或生产环境）。因此，业内在这方面的平均水平应该是在入门级。

 

而中级团队善于进行测试环境上的自动化部署。他们完全通过脚本以一键部署的方式在部分或全部的测试环境中进行部署。这大大解放了部署工程师，而且减少了测试人员因等待部署而浪费的时间。就像持续构建是中级构建团队的的特征一样，自动地部署到第一个测试环境是在部署这一维度上中级成熟度的标志。根据团队的动态性，在不打断测试人员工作的情况下，这种测试环境的自动部署应该发生在任何一次成功的持续构建之后或一天内的周期性部署。中级团队的最后一个特征是：建立标准化的各种环境部署顺序。虽然可能还会有一些环境变数，或两种部署方式，但在某个版本的全生命周期中（即从生产到部署上线），越早地成功部署，就意味着后续部署成功的可能性更大。达到这个级别是很多团队的目标。而进阶团队则把视线转到受控环境或生产环境上。部署到生产环境（或发布）只要按一下鼠标就行，生产环境发布就被自动触发，并有相应的发布版本可以进行灾难恢复。那些已经部署到内部测试环境的团队应该将目标定位到“进阶”：如果在所有环境中进行完全一致的部署过程，那么在生产环境部署时，会极大地减少最后一刻失败的可能性。进阶级团队的另一个特征是：将通过前面通过质量测试检验的版本全部自动地部署到部分或全部测试环境中。例如，得到测试经理的批准后，让某个构建版本自动地安装到压力测试环境中。

而疯狂级的团队的目标是“持续部署”，即自动部署到生产环境中而无需手工干预：得到一个版本后，自动部署到一系列的测试环境中。经过整个构建管道中的所有阶段，并且能通过所有的测试后，自动部署该版本到生产环境中。某些.com应用可以在一个小时之内就完成从源文件控制到发布的整个过程。显然，此时的自动化测试必须非常成熟，而且具有自动回滚和相应的监控手段。但是，在快节奏的竞争环境下，极其迅速地部署新功能也是一个核心竞争力，可以减轻大规模功能变更的风险。