自动化持续部署是业界最佳实践，以此为目标，能优化IT模式。

在接触的很多企业中，持续部署实践依然还有很多不足，基本上部署靠人，更别谈自动化了。我一直强调 持续部署 是IT交付的核心能力，直接关联到研发/测试和运维多个团队，可以成为一个运维的核心平台。自动化部署能力的高与低，能映射出IT能力的诸多方面的问题，比如说流程上/环境管理上/服务耦合上/平台能力上等等。

个人已经做了三个持续部署系统，每做一个持续部署系统都给整个IT团队带来巨大的收益。当带着这些经历再回过头去看《持续交付》这本书的时候，书中的很多观点让我感触很多，基本上每个点都有自己的感受。

让我们来看看《持续交付》中总结的很多错误的模式，这些错误的模式的确是现实存在的，且必须要避免的，称之为 反模式 ，具体如下：

一、反模式1:手工部署软件

对于现在的大多数应用程序来说，无论规模大小，其部署过程都比较复杂，而且包含很多非常灵活的部分。许多组织都使用手工方式发布软件，也就是说部 署应用程序所需的步骤是独立的原子性操作，由某个人或某个小组来分别执行。每个步骤里都有一些需要人为判断的事情，因此很容易发生人为错误。即便不是这 样，这些步骤的执行顺序和时机的不同也会导致结果的差异性，而这种差异性很可能给我们带来不良后果。这种反模式的特征如下：

◆ 有一份非常详尽的文档，该文档描述了执行步骤及每个步骤中易出错的地方。

◆以手工测试来确认该应用程序是否运行正确。

◆在发布当天开发团队频繁地接到电话，客户要求解释部署为何会出错。

◆在发布时，常常会修正一些在发布过程中发现的问题。

◆ 如果是集群环境部署，常常发现在集群中各环境的配置都不相同 ，比如应用服务器的连接池设置不同或文件系统有不同的目录结构等。

◆ 发布过程需要较长的时间(超过几分钟)。

◆发布结果不可预测，常常不得不回滚或遇到不可预见的问题。

◆发布之后凌晨两点还睡眼惺忪地坐在显示器前，绞尽脑汁想着怎么让刚刚部署的应用程序能够正常工作。

相反，随着时间的推移，部署应该走向完全自动化，即对于那些负责将应用程序部署到开发环境、测试环境或生产环境的人来说，应该只需要做两件事：(1)挑选版本及需要部署的环境；(2)按一下“部署”按钮。对于套装软件的发布来说，还应该有一个创建安装程序的自动化过程。

当然，并不是所有的人都热衷于这个想法。那么，我们先来解释一下为什么把自动化部署看做是一个必不可少的目标。

◆如果部署过程没有完全自动化，每次部署时都会发生错误。唯一的问题就是“该问题严重与否”而已。即便使用良好的部署测试，有些错误也很难追查。

◆ 如果部署过程不是自动化的，那么它就既不可重复也不可靠，就会在调试部署错误的过程中浪费很多时间。

◆手动部署流程不得不被写在文档里。 可是文档维护是一项复杂而费时的任务，它涉及多人之间的协作，因此文档通常要么是不完整的，要么就是未及时更新的，而把一套自动化部署脚本作为文档，它就永远是最新且完整的，否则就无法进行部署工作了。

◆ 自动部署本质上也是鼓励协作的 ，因为所有内容都在一个脚本里，一览无遗。要读懂文档通常需要读者具备一定的知识水平。然而在现实中，文档通常只是为执行部署者写的备忘录，是难以被他人理解的。

◆以上几点引起的一个必然结果：手工部署过程依赖于部署专家。如果专家去度假或离职了，那你就有麻烦了。

◆尽管手工部署枯燥且极具重复性，但仍需要有相当程度的专业知识。若要求专家做这些无聊、重复，但有技术要求的任务则必定会出现各种我们可以预料到的人为失误，同时失眠，酗酒这种问题也会接踵而至。然而 自动化部署可以把那些成本高昂的资深高技术人员从过度工作中解放出来，让他们投身于更高价值的工作活动 当中。

◆对手工部署过程进行测试的唯一方法就是原封不动地做一次(或者几次)。这往往费时，还会造成高昂的金钱成本，而测试自动化的部署过程却是既便宜又容易。

◆另外，还有一种说法：自动化过程不如手工过程的可审计性好。我们对这个观点感到很疑惑。对于一个手工过程来说，没人能确保其执行者会非常严格地遵循文档完成操作。只有自动化过程是完全可审核的。有什么会比一个可工作的部署脚本更容易被审核的呢?

◆ 每个人都应该使用自动化部署过程，而且它应该是软件部署的唯一方式。 这个准则可以确保：在需要部署时，部署脚本就能完成工作。我们会提到多个原则，而其中之一就是“使用相同的脚本将软件部署到各种环境上”。如果使用相同的 脚本将软件部署到各类环境中，那么在发布当天需要向生产环境进行部署时，这个脚本已经被验证过成百上千次了。如果发布时出现任何问题的话，你可以百分百地 确定是该环境的具体配置问题，而不是这个脚本的问题。

当然，手工密集型的发布工作有时也会进行得非常顺利。有没有可能是糟糕的情况刚巧都被我们撞见了呢?假如在整个软件生产过程中它还算不上一个易出 错的步骤，那么为什么还总要这么严阵以待呢?为什么需要这些流程和文档呢?为什么团队在周末还要加班呢?为什么还要求大家原地待命，以防意外发生呢?

二、反模式2:开发完成之后才向类生产环境部署

在这一模式下，当软件被第一次部署到类生产环境(比如试运行环境)时，就是大部分开发工作完成时，至少是开发团队认为“该软件开发完成了”。这种模式中，经常出现下面这些情况：

◆如果测试人员一直参与了在此之前的过程，那么他们已在开发机器上对软件进行了测试。

◆ 只有在向试运行环境部署时，运维人员才第一次接触到这个新应用程序 。在某些组织中，通常是由独立的运维团队负责将应用程序部署到试运行环境和生产环境。在这种工作方式下，运维人员只有在产品被发布到生产环境时才第一次见到这个软件。

◆有可能由于类生产环境非常昂贵，所以权限控制严格，操作人员自己无权对该环境进行操作，也有可能环境没有按时准备好，甚至也可能根本没人去准备环境。

◆开发团队将正确的安装程序、配置文件、数据库迁移脚本和部署文档一同交给那些真正执行部署任务的人员，而所有这些都没有在类生产环境或试运行环境中进行过测试。

◆ 开发团队和真正执行部署任务的人员之间的协作非常少 。

每当需要将软件部署到试运行环境时，都要组建一个团队来完成这项任务，有时候这个团队是一个全功能团队，然而在大型组织中，这种部署责任通常落在多个分立的团队肩上。