第3章　移动到云端：TiP的演化——在线的持续回归测试

　　Ken Johnston

　　Felix Deschamps

　　来自微软公司的Ken Johnston和 Felix Deschamps讲述了他们是如何通过在云端实施自动化测试，从而将基于产品的自动化测试变更为基于服务的自动化测试的。微软的邮件服务产品Microsoft Exchange Server中绝大多数的测试已经实施自动化了，而且其中大量的自动化是可以重用的。大多数测试人员对于“在线测试”（Testing in Production, TiP）这个概念还比较陌生，但是这一章解释了为什么进行持续监测是必要且有益的，同时为那些也正在考虑这么做的人提供了一些非常有用的小窍门。案例发生在美国，经历了3年多的时间，毫无疑问，使用到了微软公司的一些工具，如表3-1所示。

　　表3-1　案例研究特征

　　3.1　本案例研究的背景

　　你会将一个价值十亿美元的业务作为赌注放在云端吗？

　　Exchange 2007的发布对我们团队来说是非常令人振奋的。在刚推出这款产品的时候，我们已经成功地对产品架构进行重新设计，以使它能在本地的.Net平台上运行，从而转化到通过“角色”（role）来支持服务器管理，把64位机器作为目标平台，采用Windows PowerShell作为自动化服务器管理的工具箱。我们已经做好了迎接下一个挑战的准备！

　　那时，微软的总架构师Ray Ozzie正准备构建微软云计算未来的发展蓝图。我们都很清楚，云计算将会越来越重要，而正好Exchange产品也在寻求这种百年一遇的重大商机。通过云计算，我们可以在为客户降低成本的同时，给他们提供更好的服务，同时，我们也可以将Exchange产品中的业务发展壮大。

　　实施云计算这一举措也为我们引入了更多的问题。我们如何构建一组特性来吸引IT专业人员升级到Wave 14 （发布名称为Microsoft Exchange Server 2010）版本，同时又能以某一服务作为目标呢？我们又该如何对产品架构重新进行设计，以使它能够在运行遍布全球的服务前提下实现规模经济效益呢？何况现在我们不仅仅需要构建所需的软件，而且还要构建数据中心，这从何做起？

　　我们进入到完整的原型和发现模式。我们学习了很多新的web服务概念，以便通过冗余将服务进行纵向和横向扩展：

　　我们需要对多租户进行架构设计，这样单个服务实例就能服务于多个客户组织（租户）。

　　我们将为了满足某个功能的一组逻辑上的机器确定为不同的单元（有时称为小群组），这样有利于规划所获取的单元。

　　服务必须是遍布全球的，以支持业务连续性规划（Business Continuance Planning，BCP），并通过区域市场减少延迟。

　　我们学习了如何使服务成为一种业务，以及为什么必须对固定资产费（Capital Expenditure, CAPEX，如购买新的服务器开销等）、运营费用（Operational Expenditure，OPEX，比如给经营服务的员工发放工资等）以及总销货成本（Cost Of Goods Sold，COGS）进行管理。懂得了服务器并不是像变魔法似的出现在数据中心，恰恰相反，我们必须提前一年就拟定采购计划，同时，对整个数据中心的空间大小、供电和网络配置也要进行安排。对于那些曾经从事过一段时间的服务工作的人来说，这听起来都是些基本的知识，但是我们想让整个团队的人员都清楚这些服务理念，并真正懂得我们将服务业务实施云策略的意义。

　　受到以上学习过程的启发，我们决定使用以下的一组原理来推动Wave 14的发布：

　　复用和扩展现有的基础设施。

　　Exchange将保留一个代码库。

　　我们的团队是一个整体，不会分裂为服务工程团队和服务运营团队两个独立的团队。