用一次性容器降低部署成本

名称：Disposable Container

模式：通过将安装和配置解耦，使 Web 和数据库容器的安装和配置自动化。

反模式：手动将容器安装到每个目标环境并进行配置。

在较早一期的 让开发自动化文章 “持续集成反模式，第 2 部分” 中，谈到了为什么清理一个 “受污染的” 环境有助于防止出现误判或漏判的构建。Disposable Container 可以减少在使用持久性容器时可能出现的很多问题。Disposable Container 模式基于两个原则：完全移除所有容器组件，以及 将容器的安装与配置分离。对于有些人，尤其是系统工程师来说，这似乎是一个极端的概念，因为不再要求由一个单独的团队管理和模糊化容器，不让开发人员或其他人接触到它们。然而，考虑到部署期间经常出现的、代价不菲的问题，它可以让所有团队成员的利益最大化。

一键式部署经常有一些团队和我说：“是的，我们已经实现了自动化部署。”当我问一些简单的问题时 —例如 “输入一条简单的命令（例如 ant）就可以生成一个有效的软件应用程序吗？” —回答通常是这样的：“是的，一旦安装和配置好 Web 容器……”，或者 “是的，一旦设置好数据库”。我对于一个真正自动化的部署的定义是，应该能够从一台干净的机器开始，安装 Java 平台和 Ant（有一些方法可以免除这个步骤），然后输入一条 简单命令，即可得到一个可以正常工作的软件应用程序。如果做不到，就不算是 “一键式” 部署，并且在部署过程中将出现代价不菲的人员方面的瓶颈问题。

如图 3 所示，Disposable Container 模式基于这样一个原则：一切都应该在 系统中 —（使用 第 1 部分中提到的 Repository 模式）—而不是在某个人的头脑中。 

清单 1 中的 Ant 脚本从 Internet 下载 Tomcat ZIP，移除之前的部署残留的任何容器，然后解压、安装和启动 Tomcat：

<!-- Check to see if Tomcat is running prior to this --> 
 ... 
 <exec executable="sh" osfamily="unix" dir="${tomcat.home}/bin" spawn="true"> 
  <env key="NOPAUSE" value="true" /> 
  <arg line="shutdown.sh" /> 
 </exec> 
 <delete dir="${tomcat.home}" /> 
 <get src="${tomcat.binary.uri}/${tomcat.binary.file}" 
  dest="${download.dir}/${tomcat.binary.file}" usetimestamp="true"/> 
 <unzip dest="${target.dir}" src="${download.dir}/${tomcat.binary.file}" /> 
 <exec osfamily="unix" executable="chmod" spawn="true"> 
  <arg value="+x" /> 
  <arg file="${tomcat.home}/bin/startup.sh" /> 
  <arg file="${tomcat.home}/bin/shutdown.sh" /> 
 </exec> 
 <xmltask source="${appserver.server-xml.file}"
  dest="${appserver.server-xml.file}"> 
  <attr path="/Server/Service[@name='${s.name}']/Connector[${port='${c.port}']" 
    attr="proxyPort" 
 value="${appserver.external.port}"/> 
    <attr path="/Server/Service[${name='${s.name}']/Connector[${port='${c.port}']" 
 attr="proxyName"
 value="${appserver.external.host}"/> 
 <xm＜x＞ltask> 
 <!-- Perform other container configuration --> 
 ... 
 <echo message="Starting tomcat instance at ${tomcat.home} with startup.sh" /> 
 <exec executable="sh" osfamily="unix" dir="${tomcat.home}/bin" spawn="true"> 
  <env key="NOPAUSE" value="true" /> 
  <arg line="startup.sh" /> 
 </exec> 

通过使环境处于已知状态，并以一种受控制的方式部署容器，可以减少很多常见的、引发大部分部署难题的部署错误。

在多个外部环境中运行命令

名称：Remote Deployment

模式：使用一个集中式机器或集群将软件部署到多个目标环境。

反模式：在每个目标环境中通过手动方式在本地应用部署。

一旦安装了数据库和 Web 容器，让部署在开发人员的 工作站上运行是件非常简单的事情。然而，开发与生产之间有着巨大的差异。如果组织有多个项目和不同的目标环境（例如测试或准备环境），那么常常需要从一个单独的环境集中地管理部署：一台机器或一个集群。团队常使用一台构建服务器来管理每个目标环境的部署。在 第 1 部分中，我介绍了 Headless Execution 模式，该模式采用公共和私有密钥，所以不必手动登录到每台机器。如图 4 所示，Remote Deployment 依赖于 Headless Execution、Single Command 和 Scripted Deployment 模式，因此可以方便地部署到远程机器：

要从集中构建服务器远程部署软件，需要使用一些机制安全地进行远程复制和运行命令。我将讨论的两个机制使用 Secure Copy（SCP）和 Secure Shell（SSH）。如清单 2 所示，在 Scripted Deployment 模式下，集中构建机器上生成的 Web 归档被远程地复制到一个目标环境：

<target name="copy-tomcat-dist"> 
  <scp file="${basedir}/target/brewery.war" 
  trust="true" 
  keyfile="${basedir}/config/id_dsa"
  username="bobama"
  passphrase=""
  todir="pduvall:G0theD!stance@myhostname:/usr/local/jakarta-tomcat-5.5.20/webapps" /> 
 </target> 

当 WAR 文件被安全地复制到远程目标环境时，我就可以在 Java Secure Channel 中使用 SSHExec之类的任务运行任何 SSH 命令，这一切都是从集中构建机器中远程执行的。另一种方法是 ssh到远程环境，并在本地运行命令。这样可以减少来回的远程传输，并缩短部署时间。

使数据库和数据处于已知状态

名称：Database Upgrade

模式：使用脚本和数据库在每个目标环境中应用增量更改。

反模式：在每个目标环境中手动应用数据库和数据更改。

在图 5 中，可以看到一个在 Scripted Deployment 中使用自动化脚本更新数据库的例子：

在较早一期的 让开发自动化文章 “实现自动化数据库迁移” 中，我谈到了以自动化的方式应用增量数据库更改的必要性。和 Scripted Deployment 中的其他部分一样，数据库更新脚本被签入到储存库中。

LiquiBase（参见 参考资料）是用于将增量更改应用到数据库的工具，可使同样的更改作为 Scripted Deployment 的一部分应用到每一个目标环境。在清单 3 中，一个 SQL 脚本被作为 LiquiBase changelog 的一部分调用。然后，Scripted Deployment（使用一种构建脚本工具实现 —例如 Ant）调用这个 changelog（使用 XML 定义）。 

<changeSet id="1" author="jbiden">

 <sqlFile path="insert-distributor-data.sql"/> 

</changeSet>    

要学习和应用自动化数据库更新，还有相当多的事情要做，但其主旨是在 Scripted Deployment 中执行更新，使所有数据库更改都在 系统中，而不是一个写好的程序或存在某个人的头脑中。

冒烟测试部署

名称：Deployment Test

模式：将自测试功能编写到 Scripted Deployments 中。

反模式：通过运行手动功能测试来验证部署，没有关注特定于部署的方面。

图 6 解释了在部署前后运行部署测试的一个例子： 

在清单 4 中，我使用 Ant 执行部署前测试，以确认正在使用的版本是正确的工具版本。在 Scripted Deployment 中，脚本可以检查正在使用的端口（这可能导致 Web 容器部署失败），检查与数据库的连接，检查容器是否已被启动，以及很多其他内部部署测试。

<condition property="ant.version.success"> 
  <antversion atleast="${ant.check.version}" /> 
 </condition> 
 <antunit:assertPropertyEquals name="ant.version.success" value="true" /> 
 <echo message="Ant version is correct." /> 
 <echo message="Validating Java version..."/> 
 <condition property="java.major.version.correct"> 
  <equals arg1="${ant.java.version}" arg2="${java.check.version.major}" /> 
 </condition> 
 <antunit:assertTrue message="Your Java SDK version must be 1.5+. \ 
  You must install correct version."> 
  <isset property="java.major.version.correct"/> 
 </antunit:assertTrue> 

更全面的部署测试可以确保应用程序的 功能性是正确的。通过使用用于 Web 应用程序的 Selenium 或用于客户机应用程序的 Abbot 之类的工具编写 特定于部署的自动化功能测试，可以验证是否已正确应用了部署更改。可以将这些测试看作 冒烟测试（smoke tests）：只需测试受部署影响的功能。例如，表 1 展示了使用 Selenium 和其他用于 Web 应用程序的工具的一些方式：

表 1. 部署测试

部署测试描述

数据库   编写一个自动化功能测试，该测试将数据插入到数据库。验证数据是否被输入到数据库中。   

简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）   编写一个自动化功能测试，该测试从应用程序发送一个电子邮件消息。   

Web 服务   使用 SoapAPI 之类的工具提交一个 Web 服务，并验证输出。   

Web 容器   验证所有容器服务是否正确运行。   

轻量级目录访问协议（Lightweight Directory Access Protocol，LDAP）   使用应用程序，通过 LDAP 进行验证。   

日志记录   编写一个测试，该测试使用应用程序的日志记录机制编写日志。   

自动化测试不仅仅用于测试用户功能。通过创建侧重于部署测试的套件，可以检验部署的有效性，减少下游错误和开发成本。

回滚所有部署更改

名称：Environment Rollback

模式：当部署失败后，提供自动的 Single Command 更改回滚。

反模式：手动回滚应用程序和数据库更改。

图 7 解释了回滚数据库更改 —使用 Database Upgrade —以及回滚 Web 部署的自动化过程：

不管是否执行自动化部署，当部署失败时，最好有一种方式可以回滚更改。在某些情况下，错误的更改可能导致系统中断，使组织损失数百万美元。要执行 Environment Rollback，需要让目标环境回到部署前的状态。为此，实际上每个更改都需要一个回滚脚本。Web 部署常常需要回滚更多的更改。Environment Rollback 的一个例子是在部署前复制归档（例如一个 WAR 文件），并为每个更改提供回滚数据库脚本。另外还需要重新应用已应用于 Web 容器的配置更改。

清单 6 演示了一个示例，该示例使用 LiquiBase 为每个前滚语句提供一个回滚语句。我将添加一个名为 brewery的新表，同时提供一个相应的 dropTable回滚语句。

 <changeSet id="rollback-database-changes" author="bobama"> 
  <createTable tableName="brewery"> 
    <column name="id" type="int"/> 
  </createTable> 
  <rollback> 
    <dropTable tableName="brewery"/> 
  </rollback> 
 </changeSet> 

这个简单的例子仅用于说明问题，并不意味着回滚就是这么简单。恢复到前一个部署常常是一个复杂的、费时的过程（需要实现自动化）。用于编写回滚脚本的时间应该与部署失败付出的代价成比例。

保护信息不被窥探

名称：Protected Files

模式：使用储存库，只允许经过授权的团队成员共享文件。

Antipattern：在团队成员的机器上管理文件，或者将文件存储在可由已授权团队成员访问的共享驱动器上。

图 8 展示了一个受保护的版本控制储存库，它用于存放只有已授权人员或系统可以访问的文件：

在某些情况下，并不是所有团队成员都应该访问特定于环境的数据。但是，将该信息与部署脚本分离又可能使脚本无法执行。当讨论 Headless Execution 模式时，我描述了使用 SSH 密钥和 Java Secure Channel 工具复制文件，并安全地运行远程命令，而不需要人为输入命令。使用 Externalized Configuration 处理的属性很可能包含不应该让所有团队成员看到的数据。为了确保实现 Headless Execution，同时防止 .properties 文件中的数据被窥探，我使用的技巧是将这些文件签入到一个受保护的储存库中。

在清单 7 中，我配置了一个由 Apache 托管的 Subversion 储存库，先拒绝所有用户访问某个目录，然后显式地添加某些用户： 

<DirectoryMatch "^/.*/(\.svn)/"> 
  Order deny,allow 
  Deny from all 
  Allow bobama,jbiden,hclinton 
 </DirectoryMatch> 

通过保护对 Subversion 储存库的访问，可以将一个 Scripted Deployment 设为被允许的用户，使其不必输入密码就可以访问属性，从而通过 SSH 密钥定义的方式实现 Headless Execution。 

一键式部署

除了这份分两部分的系列文章中描述的 15 个部署自动化模式外，我还归纳了更多的模式，但是这 15 个模式大概可以应对我遇到的 80% 的部署情况。每个模式都是为了帮助在每个目标环境中实现真正的一键式 / 单命令部署。希望您一切顺利！

结束语

这是我的 让开发自动化系列的最后一篇文章。在两年多的时间里与您一起分享我的经验，令我感觉像在经历一场有趣的探险。编写这个系列的目的是展示如何以及为何自动化大量软件开发过程，使开发人员可以将更多的时间花在感兴趣的问题上，而不是将时间浪费在重复的、容易出错的活动上。在这个系列中，我演示了如何自动化代码检查以便适当地重构、增量式地升级应用程序数据库、应用 Continuous Integration 实践和工具、每次更改时运行自动测试、生成 GUI 安装程序、创建一键式部署、使开发人员自动生成文档、执行依赖管理、利用版本控制储存库，以及有效地使用各种构建脚本和工具。希望您在阅读这个系列时能够充满乐趣。