4.自动功能测试

　　卸载、安装操作成功后，即对选用的测试用例进行测试，测试用例经过精心挑选，根据功能分为不同的核心单元，周一到周五只运行核心的测试用例，时间再运行所有的用例。用例无法在一个Lab一个晚上运行时，则将用例分布配置在多个Lab里面，并行运行。

　　5.结果汇报及存档

　　定点(如早上9:00)对前晚上进行的所有操作进行汇报，包括不同产品的编译、打包、测试，不同Lab上不同服务器的卸载、安装结果，不同Lab上功能测试用例通过情况等信息自动以邮件的方式通知开发和测试人员，并将结果存档方便随时查看，对其中的关键数据如测试用例通过率等写于数据库，便于跟踪分析。

　　自动测试统计结果如图2所示。

　　图2 自动测试统计结果

　　6.流程整合和协作

　　流程1~2、5发生在编译服务器群上，流程3~4发生在运行环境Lab群上，需要将1~5流程集成自动化，并且流程间需要相互协作。我们采取集中控制的方式，将1~5所需要脚本工具和配置文件集中放置，这样便于管理和维护，其他服务器通过NFS共享访问脚本工具和配置文件，只需要在其他服务器上配置相关的cron job，便能相互协作起来。协作流程如图3所示。

　　图3 协作流程示意图

　　回顾与反思

　　经过近一年的完善，我们的OSS系统终于从之前的数周才能一次手工集成，达到了每天集成，许多人工操作和检查统计工作均自动化，不仅仅大大解放了Build Manager的工作，而且避免了人工差错，提高了效率。对于像OSS这种历史悠久的复杂系统，持续集成是一个长期优化、完善的实践过程。毕竟持续集成不是一朝一夕可以实现的，而应该成为一种持之以恒的习惯。

　　总之，一个完善的运行良好的持续集成，必须考虑如下问题：

　　1.持续集成的频度和粒度

　　每个开发人员提交代码更改之前，在自己的branch上需要确保编译、单元测试通过，避免不必要的集成失败，只有开发人员确认的可靠代码，才进行集成。对于小型系统可以做到每次提交都集成，对于像我们OSS这样的大型系统，可以做到每天一集成。

　　2.统一构建、并行构建

　　对于多产品的系统，采用统一的构建、打包、安装方式有助于灵活实现自动化。并行构建、并行测试、并行安装等可以充分利用服务器物理资源缩短集成时间。

　　3.协作整合

　　在并行的同时，也需要采用合适的同步协作的方法，以保证系统正确运行。如编译、打包、单元测试的进程在编译服务器群上，安装、卸载、功能测试等进程在运行系统的Lab服务器群上，而邮件通知则又需要将这些进程运行的结果整合起来。简单的文件或目录共享远程调用往往能完成这些控制权的转移，实现协作和工具整合。

　　4.高性能build server

　　高性能的编译服务器或服务器群也是持续集成中强有力的支撑。支持并行编译的话将更好。

　　5.完善的结果报告

　　完善的结果报告能缩短开发或测试人员发现、解决问题的时间。完整有效的报告应该包含软件版本信息，本次集成中所做的修改，单元测试和回归测试结果，卸载/安装结果。

　　6.持续集成工具

　　在持续集成实践过程中，一个完善的SCM系统(如ClearCase、SVN、CVS)，分支并行开发的策略几乎是必备的支撑。同时，如果在Unix或Linux环境下，亦无须迷信于专门的持续集成工具，有些时候，借助各种脚本工具与cron job完全可以满足这些需要。

　　7.自动化

　　持续集成必须跟自动化结合，才能真正的发挥其威力。