SOA 的体系架构中很强调“分布式”这个概念，不仅是构架的分布式，开发模式也体现了“分布式”的概念，SOA 的开发团队经常分布于全球不同的角落，比如：Service 层的开发位于中国、测试组位于中国、UI 层的开发位于美国。这种分布式的时区差异导致了如果美国出 Build 的时间是北京时间的凌晨 4：00，中国测试团队每天早上上班的第一件事就是从美国的服务器中取下 Build 然后把它部署到服务器上，重复的劳动不仅耗费大量的人力物力，且由于 SOA 组件的配置比较复杂，手工配置很容易出错，加大了测试团队的风险。

　　除了开发和测试的分布式模式带来的挑战之外，由于 SOA 是一个基于服务的构架，服务粒度的细化导致在一个企业级 SOA 应用中会有大量的服务需要发布出来，可能导致的部署的 EAR 包比传统构架的多，体系结构也比较复杂。有一个真实客户的例子，在采用 SOA 构架后其 IT 架构包括如下几部分：

　　● 50 个 Websphere 的集群 (cluster)，200 个应用服务器 (application server) 在 40 个节点 (node) 上。

　　● 整个应用程序包含 26 个 EAR 包在 11 个独立的实例上 (instance)，这就意味这 11*26 的部署工作。

　　● 12 个 SIBus, 2 个 JMS queues，每个集群 (cluster) 一个数据源 (dada source)。

　　管理和配置这个复杂的环境无论对测试人员还是客户来说都是一个噩梦，自动化部署不仅可以大大提高测试的工作效率、减少项目风险而且可以向客户提供一种”one click”的解决方案，对客户屏蔽诸多技术的细节和配置的复杂性，提高客户对 SOA 技术的忠诚度。

　　本文将根据我们在项目中的经验总结出一种每天按需求自动下载、部署、配置 Build 的自动化方案。

　　自动下载 SOA 组件

　　SOA 的分布式开发环境

　　下图是一个很典型的 SOA 的开发和测试环境。

　　在图中所示的这种软件开发环境中，Service 开发团队和测试团队位于中国，UI 开发团队位于美国，Service 开发团队和 UI 开发团队都有自己的 Build Server，用于存放自己每天所发布的 Build，测试团队有自己的一套 SOA 测试环境，它需要每天安装和配置 SOA 的 Service 组件和 UI 组件用于测试。本章将介绍测试团队如何在这种分布式环境中实现自动化测试。

　　自动获取 Build

　　在当前的脚本语言中 Ant 和 Python 是最流行的两种语言：Python 是一种非常灵活强大的动态脚本编程语言，具有完整的面向对象特性；Ant 是纯 Java 语言编写的，具有良好的跨平台性，由于 Ant 的构建文件时以 XML 书写，容易维护且结构清晰。我们将结合两种语言各自的优点运用于我们的脚本之中。我们以 Windows 为例，整个自动化脚本的目录结构如下所示：

　　图 2.2 自动化脚本的目录结构

　　有几个目录需要重点介绍一下：

　　EAR：是我们存放下载后 Build 的路径，他有两个子目录 service 和 UI 分别用于存放 SOA 的服务层和用户界面层的 Build。

　　Lib: 存放应用程序所需要的共享库，某些应用程序部署上后需要配置共享库。

　　在 BuildScript 目录下有一个 deployBuild.bat 文件，一个 buildToTest.py 文件。