一旦构建结束——自动化部署过程

　　构建应用程序只是开发生命周期中的一部分。一旦代码编译测试后，需要进行其他的活动，例如部署到阶段性(staging)环境、冒烟测试、功能测试和性能测试、准备发布说明和提醒QA人员最新的发布。

　　将最新的构建结果自动部署到集成服务器上是一件相对简单的事情。而将其部署到阶段性环境或者生产环境下，则需要涉及一些与常规构建作业不一样的工作。一般而言你需要一个更加严格，更加正规且有更多可跟踪性和问责的过程。它通常涉及到的任务如下：

　　* 为阶段发布标记源代码

　　* 编译测试应用程序

　　* 发布构建产品

　　* 将应用程序部署到阶段性环境中

　　* 运行数据库更新脚本或者其他特定环境脚本

　　* 运行冒烟，功能和性能测试

　　* 准备并发布产品说明

　　* 提醒关于最新阶段发布的相关利益人

　　这通常是一个手工任务，但是其中的大部分工作没有理由不能自动化。事实上，开发生命周期中的自动化包装，部署和发布具有很稳固的商业意义。一方面自动化能够得到更加可靠的构建：计算机不会忘记部署过程中的某一步，也不会在发生测试失败后继续进行。它还能够节约开发人员的时间：阶段性发布由之前几小时的 shell脚本编程变为了只要点击一下按钮。它比以前的速度要更快，并且可以在没有人的情况下完成工作(例如，通宵或者午休时间)。

　　像Maven 2这样的工具也能够帮助自动化一些步骤。Maven Release插件使得Maven的用户能够自动化处理一些如“更新版本号”，“Subversion中新增标签”，以及“向Maven存储库中发布构建产品”的工作。它可以用来管理阶段构建，并决定在不同的环境部署不同的发布产品。尽管如此，一旦产品构建结束并且可以部署到阶段性环境者生产环境时，这个过程就会变得更复杂。

　　千真万确，现实世界中的部署步骤数目经常要比简单的用一个WAR文件多。根据应用程序架构和产品平台，你可能需要在阶段性环境者生产环境下的数据库中运行SQL更新脚本、用一个专用的工具部署web服务、运行自动化的冒烟测试或者做一定量服务端的工作。

　　CI可以帮助简化比这些还要复杂的步骤。例如通过分布式构建，你可以设立阶段性环境或生产环境上的构建代理，并在该机器上直接运行相应的任务。几乎所有的 现代CI工具都支持相当好的安全模型，目的是为了将应用和产品环境限制给一些特定的人，以及跟踪谁在什么时间运行了什么构建。

　　这是CI的一个相对较新的应用，不同的工具在处理应用程序部署时使用的方法也不一样。有一些，如Hudson，允许在构建作业中定义多个步骤，只有当前一 个步骤成功后，才能执行后续步骤。其他的像Cruise和Anthill Pro，都尝试将部署生命周期中的如阶段和生产环境直接集成到构建工具中，尽管有时候这样会带来额外的复杂度开销。

　　还有更多低层次的操作可以和CI服务器联合起来使用。一个选择是使用诸如Ant或者Maven的构建工具。Ant对于这种类型的脚本特别灵活。另一个流行的选择是古老的Makefile，或者Unix上的shell脚本。它们的缺点是操作系统相关的，并且对于那些不熟悉shell脚本精髓的Java 开发人员来说很难掌握。想要与Java更加友好，可以选择动态语言诸如Groovy或者Gant(一个使用Groovy而不是XML来制作Ant脚本的工具)。 Groovy在提供所有轻量级的动态脚本语言中所有的优点的同时，也保留了对Java开发人员的熟悉程度和可读性。

　　总结

　　这些只是使用现代持续集成环境完善构建过程和增强团队的几个方法。持续集成环境绝对不仅仅是一个构建计划表，它还可以用来帮助打开队伍内部的沟通渠道、保持构建过程平稳有效的运行、时刻监控代码质量以及自动化发布和部署过程。