• 需求：更频繁地发布，更自动化地部署
• 一个自动化的解决方案
• 怎样使工作自动化
• 结论

本文来自于 Rational Edge：学习如何利用基于Java的Apache Ant构建工具的相对简单的实用工具，来自动化一个 WebSphere 平台上的Web应用程序的UCM驱动的构建/部署过程。

　软件工程师们经常发现Web应用程序的部署非常消耗时间而且容易出错。通常情况下，工程师们需要制作可部署的Web应用包，然后人工地将其部署到一个应用服务器上。这种井井有条的开发环境常常跟我在IBM China Globalization Laboratory时的工作很相似。我们用一个集成了IBM Rational ClearCase和IBM Rational Clear Quest的统一变更管理（UCM）基础架构，为我们的产品处理软件配置，称作Translation Communication Tool (TCT)。我们将每一个基于 Web 应用软件的新版本部署到IBM Webspace Application Serve(WAS)上。

虽然UCM有很多好处，比如版本管理和缺陷管理，但我们在Web应用上发现了不足之处。在利用UCM基础架构进行部署管理时缺少一个单独统一的机制，我们的集成人员不得不人手工地去除源代码（像Java和JSP文件）和内容资源（像CSS和图像文件），然后利用WAS开发工具构建一个可部署的包，最终手工将这个应用软件部署到Websphere平台。尽管UCM基础架构提供了可取消的API使部署可自动化，但是API在基础水平上是很难被理解。

在这篇文章中，我描述了一个利用基于Java的Apache Ant构建工具的相对简单的实用工具，使Web应用软件在WebSphere平台上的UCM驱动的构建/部署过程自动化的方法。由于这个实用工具，我们现在只需轻轻点击鼠标，就可以将构建部署到WebSphere平台，管理自动测试运行，甚至报告失败，然后追踪到最新一次稳定的发布。

需求：更频繁地发布，更自动化地部署

手工部署不仅仅是为那些创造和部署每一个工作版本的团队成员引入了错误并花费了更多的时间，它还降低整个团队的效率，改变了构建/部署的生命周期。

因为Web应用软件的手工部署是十分耗费时间的，开发者们完成了批量的发布版本，这样就需要更少的部署。我们在几个星期或者更多的时间内累计了一批代码修复或者新的特性，然后立即将他们部署。在这期间，一些测试人员没事可做，等待开发人员将这批可使用的代码变更或者修复处理好。这并不是最有效的利用技术资源。

当团队正在加强，修复缺陷，不停地测试新代码时，这对更频繁发布新版本是十分有利的。更少的变更，更频繁的发布意味着每个构建的回归测试所需的时间越少，用户能更快地得到新特性的好处，部署团队在他们的工作上可得到更频繁、粒度更小、更快反馈的好处。

更频繁地发布的另外的好处是大大缩减测试人员的停工期。我们发现自动化测试我们产品的所有特性是不可行的。取而代之的是，我们仅仅在关键“黑盒”组件（利用JUnit）上自动执行测试，在运行整个产品（HttpUnit）的功能测试上就需要更少的时间。无论如何，为了充分测试重要的功能，大多数情况下手工测试是不可避免，而且是QA工程师们在测试服务器上进行的（有些测试还是由“真正的”用户在产品服务器上执行的）。因此频率更高更有效的部署意味着测试人员可以在更连续的基础上进行测试工作。

一个自动化的解决方案

为解决这些顽固的问题，我们的团队为我们的TCT产品创建了一个自动构建/部署的实用工具，它让我们能够在更短的时间，更少的错误下更频繁地发布新构建，从而提高我们整个生产率和工作效率。

在这个实用工具的帮助下，只需轻松地电一下鼠标，我们现在就可以将我们的Web应用软件部署到我们的IBM WebSphere产品服务器上，也可以部署到我们的的测试服务器上或者其它平台上。如果一个测试服务器上的自动测试运行返回或者失败，这个实用软件就会通过邮件向开发者报告，通知这个应用集成人员在测试服务器上回到最后一个稳定的发布重新运行。

我们甚至可以筛选出我们想部署或者指定这个软件的哪个组件，我们想回到先前哪个发布，以及哪个部署点。在最简单的例子中，我们设定默认设置（比如包括所有的组件），利用克隆脚本自动定期地运行这个构建和脚本部署，正如下面所述。

怎样使工作自动化

通常情况下，我们设置构建/部署脚本在每天晚上自动运行，从而减小网络在高峰时段的压力，同时增加了这个团队的合作效率。尤其对分布在全世界不同地域的团队非常有用。例如，中国的一个开发团队在白天完成了编码工作，当他们离开时，这个变更可在测试服务器上自动构建和部署。相差很多个时区，远在德国的团队执行测试并且为第二天的代码变更和修复出示结果。（与此相反，手工构建和部署使得开发团队很难在每晚都构建和部署。因此，测试小组经常需要花好几天来等待代码变更和确定的结果。）

下面的部分逐步解释了怎样使工作自动化，在很多情形中显示了所包含的代码

步骤1：初始化环境变量

首先，我们要为Web应用构建/部署的自动化来初始化全局环境变量。例如，我们需要读取{web.dir}，{src.dir}，{lib.dir}，{bulid.classes}等等，变量来自于属性文件，并确保这些全局变量在整个自动构建/部署过程中是可以利用的。此外，我们为了一些特殊任务而读取一些变量，比如{upload.path}和{deploy.server.name}，都是上传和部署工作需要的。

下面是实现这个的代码：

步骤2：从ClearCase更新并同步代码

IBM Rational UCM的特性是，在这个软件工件的作用下整合了一个项目中的小应用程序，这个软件工件在这个明晰的、可重复的过程中是可变的。UCM帮助开发者跟踪这个变化使这个工件来满足变化的要求，因为IBM Rational ClearCase 控制着这个随着新版本一起变化的工件。

下面的脚本同步了来自ClearCase整合版本最新代码和Apache Ant工具中的备份任务。

步骤3：编译所有Java 类

通常情况下，对于一个Web应用软件，所有Java源文件应该被编译并放在的地址{build.class}，它使WEB-INF/classes所缺少的。在这个构建过程中，我们在Sun 的 JDK中用Java命令来编译所有的Java类。

步骤4：通过邮件告知构建结果

在自动化过程中，自动生成邮件是一个非常好的便于沟通的方法。我们的自动化通过发送邮件向开发者和项目经理告知构建结果，让他们知道每个构建是成功完成还是失败了。通过告知这个构建的错误，开发者们能够调查并识别来自于他们编码的错误。

步骤5：产生基线

在我们的产品的版本管理中基线对我们来说是十分重要的。我们发现最好的自动产生基线的方法是利用Apache Ant自动产生和增加这个构建版本的数字。Apache Ant是通过创建和更新一个名为tct_build_info.properties的文件的条目来实现的。

下面是这个属性文件中域名值的详细情况：

一个基线的最重要属性就是其质量。开发者可以产生无数基线，但是为更进一步的开发他们只能用好的基线。“好的”在这里的意思是可以使代码可以完全编译，一组测试可以成功运行的基线。

在基本单元测试完成之前，开发者可以为这个构建指定一个晋升水平，当然也有可能被否决。一旦这整套单元测试顺利完成，这个构建就可以升级到BUILD，这意味着我们现在拥有一个很好的基线，它可以为更进一步的开发奠定基础。图表1阐述了这个产品内部构建过程

通常情况下，我们需要调用ClearTool 命令直接完成类似于校验、升级、登记、创建基线等等任务。然而，这些命令与自动构建/部署工具之间的结合相当困难。幸运的是，Ant提供了第三方的任务，很容易地将UCM概念整合到基于Ant的自动构建/部署实用工具中去。图表1阐明了一个内部构建过程，在这个过程中Ant任务（CCCheckout，CCCheckIn，CCCMkbl，都用红色标记）都有所用处。

图1：内部构建过程。 Apache Ant提供了第三方的任务，很容易地将UCM概念整合到基于Ant的自动构建/部署实用工具中去。图表1阐明了一个内部构建过程，在这个过程中Ant任务（CCCheckout，CCCheckIn，CCCMkbl，都用红色标记）都有所用处

步骤6：为不同的平台打包

在许多项目中，有不同的部署平台，比如一个测试站点相对于一个产品站点，针对不同的站点在Web应用的属性文件中需要特定的部署变量。例如，当部署一个产品站点，这个构建也许需要所有的应用组件。然而当部署一个测试站点时，你不必包含邮件通知组件，因为你不想在测试站点测试期间的用户被偶遇的邮件打扰。另一个可能是，产品站点可能运行的是Linux系统，而测试站点可能运行的是例如AIX系统。由于类似的原因，发布工程师们通常需要创建不同的部署场景。

下面的代码运行了Ant基于不同的部署平台的三个不同的任务。每个任务采用一个平台――具有特定属性（看图2），然后产生脚本构建与其平台相一致的可部署的包。

以上提供的脚本产生了两个Web模块，包括TCT2.2.war和soap.war，利用了一个特殊的命名规则将它们和一个构建版本的属性文件整合到一个可部署.ear包中去: ${tct.ear.name.prefix}.${today}.${build.version}.ear.

　
　　　图2：TCT夜晚构建过程

步骤7：上传包到WebSphere Application Server

下面是一个Ant任务，在WebSphere Application Server(我们的产品Web服务器)上上传一个a.ear可部署包到{installableAPPs}地址：

上面的脚本通过一个自动化部署管理命令，将这个步骤6中产生的这个可部署包上载到WebSphere Application Server中一个临时地址来应用。这个命令将在下一步来解释。

步骤8：WAS上的远程登陆/部署和重新启动

下面是Ant任务，远程登陆到WAS服务器并运行部署脚本“appinst2.jacl”：

下面是部署脚本，它可以通过WebSphere Application Server平台提供的wsadmin.sh命令转化并运行：

步骤9：构建服务器的结构

为更进一步提高我们构建过程的效率，我们已经配置了一个服务器专门运行我们TCT产品的夜晚构建。我们基于平台变量创建了一个文件夹结构和构建号码来维持先前的所有构建。当一个夜晚构建失败时，我们能够很容易地跟踪到先前任何一个稳定的发布，开发者们可以重新创建一个新的可使用的版本进行测试。图3阐明了我们构建服务器的结构。

　　　　　　　　　　　　　图3：TCT构建服务器的结构

关于图3，请注意下面几点：

• 构建由脚本产生，可自动考虑平台的相关性（注意图3中的“Configure App properities”）。
• 在任何一个平台环境，构建通过内部构建版本号进行组织。例如，在一个我们称作Common Development and Testing(CDT)的平台，发布由构建号如TCT2.0.1000，TCT2.0.1001，等来组织。
• 如果一个构建失败，最近的一个稳定构建将在应用集成人员的要求下被自动上载并部署到WebSphere Application Server。例如，在一
• 我们称作Local Testing Server的服务器上，如果构建TCT2.0.1001失败了，应用集成人员会筛选最近一个稳定的构建，上载并部署。

我们的开发团队通过在我们强大的CUM环境中使用自动构建实用工具，获得几个重要的利益：

• 提高效率。我们能够每天自动构建和部署我们Web 应用软件。当构建失败时，开发者们可以自动收到报告错误的邮件，先前稳定的版本可以自动重新获得。
• 可跟踪性。我们可以自动记录带有版本和发布的可部署包。只需发布工程师的一个简单的请求，每有个新的发布都会自动转化并毫无差错地重新运行。
• 灵活性。现在对于团队来说采用不同的发布环境容易多了，因为我们的构建/部署实用工具可以在不同的平台环境下自动产生不同的与之相匹配的可部署包，并将他们自动部署。

我认为无论是新手还是中等水平的实践者都会从这里的技术描述获利。通过使用这里提供的代码和脚本，运行这个构建/部署过程，你只需要将你Web应用软件中有关平台的部分整合到不同的配置地址就可以了，如图3所示。然后你就可以实现这三大利益：高效性、可追踪性和灵活性。