16.6 拥抱部署

16.6  拥抱部署

在本章中，我们已经看到如何将部署自动化，并将它集成到构建循环中，从而成功地实施部署。但是仅仅增加一些新的开发工具并不够；整个开发过程也要做相应的调整。在构建文件中加入单元测试后，就在构建循环中加入了测试行为；同样的道理，在构建文件中加入部署，可以改变我们交付软件的方式。

当把软件交付到操作员团队手中时，原始的“瀑布”开发过程又开始显现端倪了。如图16.7所示：

如果抛开部署，那么你将无法从部署阶段或者真实的系统中获得反馈。这些反馈可以帮助应用程序进行改进，使它更容易进行部署和管理。失去了这些反馈，我们可能会开发出很难部署的应用程序，无法满足操作员团队的需要。
有什么对策呢？把部署整合到测试和持续集成的过程中如何？目标是让开发的生命周期更像图16.8所示，即部署只是“开发与测试”流程中的一个环节而已。

在这个循环周期中，操作员团队拥有测试的主机。开发者在这些机器上进行部署，运行自动化测试。这能保证操作员可以获得部署和管理应用程序的经验。这可以保证操作员可以获得部署和管理应用程序的经验，另外开发者也可以编写直接在生产系统上运行的代码。

下面还有一个小问题：如何集成一个带有运行测试的部署。我们可以阻塞Ant，直到条件判断显示应用程序已经完成了部署，即当<get>显示站点已经开始工作后，运行<junit>和<junitreport>。SmartFrog的<functionaltest>任务可以完成这件事。

另一种选择是，我们可以利用这一事实的优势：SmartFrog可以部署任何事，包括测试！运行JUnit测试的行为也是可以部署在网络主机上的事物，能够用一个测试监听器组件通过测试结果来创建HTML页面。JUnitTestSuite组件可以包含一个JUnit 3.8.x测试的列表：

HttpUnitTests extends extends JUnitTestSuite { 
server.url TBD; 
name "HttpUnitTests"; 
package "d1.webapp.test"; 
properties [["server.url",server.url]]; 
classes ["EventFeedTest", 
"HappyTagTest", 
"IndexTest"]; 
} 

这个组件可以部署在TestRunner组件下，后者可以在不同的处理器或不同的主机上运行测试，并把测试结果发送给测试监听器。HTML测试监听器会在收到结果后创建XHTML页面：在创建测试结果前不必等待整个运行的完成。不可否认的是，页面不是很好看——在展现与分析（从数十或数百个系统中收集的）测试结果这个领域里，还有很多地方需要提高。不过，这些XHTML是一个良好的起点，它对于运行大规模的测试来说很方便。

将部署集成到核心的开发循环中并不容易。开发者将必须比以前更早地与操作员协同工作；操作员也必须提前支持更多的系统。这正是你为什么要这样做的原因：两个团队在项目的一开始就应该一起工作！

持续部署

我们已经实现了部署的自动化，也将测试整合到了部署过程中。现在我们可以再向前迈一步了。团队中的持续集成服务器可以不断地重复部署应用程序和功能测试。它甚至还能够每天部署到生产系统上——当然，所有的功能测试都必须通过！

如果你想尝试一下这样做，下面是一些建议：

在向生产环境部署时，添加一个打标签的分支。这可以防止代码被意外地发布出去。

限制更新的频率，比如每天一次。如果你的客户认为你可以在一个半小时内发布一个补丁，他们会要求所有的Bug要在一小时内修改完。将构建适时地延迟一些可以减少压力，并且让开发者能够更专心地修复错误。

准备一个良好的回滚机制，并对它进行测试。

整个“持续部署”的概念都和Web站点开发中的“everlasting beta”现象相关，后者是指Web站点永远不会稳定，几乎每天都会有出现新的特性。在Web Service开发领域中，这种现象更为明显，你要为外部的调用者开发一套公共的API。就像敏捷开发鼓励开发者与顾客一起工作一样，敏捷Web站点和Web Service的开发需要开发团队与操作员一起工作，这样能够基于真实用户的体验，迅速地改进运行中的应用程序。如果将部署融入到持续集成的过程中，那么即使要对外部的调用者暴露一个Web站点和服务，敏捷开发仍然是可能的。