【IT168 技术文章】
XP方法中把日构建列为软件开发管理中的非常好的实践；敏捷软件开发中也把持续集成当作是保证软件项目成功的一个原则。无独有偶，2003中国软件技术大会，上海微创软件公司技术总监蔡培讲述了微软公司的软件开发管理，演讲中提到微软软件开发管理中的一个重要实践，也就是日构建。（日构建和持续集成本质上是一样的，只是前者的频度是每日一次，而后者则并未限定频度。为了便于讲述，本文中不再区分这两个概念。）
关于日构建的作用和意义，书籍和网络上已有相关文章介绍，本文不再赘述。本文假设读者已经充分认识到日构建或者持续集成的好处，并且正打算把它应用到企业的开发管理流程中去，但是对于如何做日构建和持续集成，无论从技术上还是管理上还比较迷茫，那么这里将务实地与大家交流一下相关的一些的经验。
1.1. 日构建中的要素
归纳一下，日构建中有如下几项要素：
1.1.1 版本管理
所有参与构建的开发工件都应该纳入版本管理。有了版本管理，才能为了日构建稳定而可靠的输入。版本管理工具要为日构建提供的支持仅需包括一个命令行客户端工具。
1.1.2 流程自动化
日构建的处理复杂性依赖项目的大小以及加入的实际过程数量和内容而不同，但是不管怎样，努力达到流程的全部自动化是日构建的一个要求。流程的自动化有利于提高日构建的运行效率，减少人工干预引入的错误可能。
1.1.3 为日构建定制的管理制度
日构建完整的流程不仅只涉及到开发人员，实际还涉及到需求人员、设计人员、测试人、员、项目经理等多个角色，是一天中各方工作成果的集中体现。如此重要的活动，并涉及到多个责任主体，必然也要制定相应的管理制度来规范各个角色的行为，以便保障该项重要活动的有序、有效进行。
1.2. 日构建的一些策略
1.2.1代码统一管理
一般来说，只要软件开发中全部使用了版本管理工具来管理开发输出的工件，就具备了日构建的该项要素。实际情况中，无论采用微软的VSS，Rational的ClearCase，还是开源的CVS，都可以通过特定的客户端工具，以命令行的形式来获得所需项目的最新版本（或者特定版本）的工件来进行构建。（这里之所以说是工件，而不特指代码，是因为实际构建中的元素不仅有代码，还可能包括其他一些参与编译或者运行的工件，比如说元数据。）
日构建虽然是一个软件企业的日常开发管理行为，但是它一般是以项目作为构建基础的。不同的项目尽管不建议，但是还是允许采用不同的日构建工具、流程。
一般来说，我们会是先有版本管理工具，再有日构建的相应工具，而且，可能存在多个项目所使用的版本管理工具不一致。比如一个企业可能同时采用VB和Java开发不同的项目。那么采用VB的项目，基于与VirtualStudio的集成，可能更多选择了VSS作为版本管理；而采用Java开发的项目则可能选择CVS作为版本管理。对于一个软件企业来讲，为不同的项目选择不同的配置管理工具可能是个无奈之举，但是在选择配置管理工具的时候，该工具是否能够很好支持日构建应该成为一个考虑项。
下表给出了可以成功构造日构建系统的常见模式。
简单的日构建流程包括：下拉源代码－＞编译代码－＞运行测试。
复杂一点的日构建流程可能包括：
1. 下拉工件
从版本管理工具获得源代码、参与运行的资源文件（图标和图片）、配置、元数据等。
2. 工件统计(Statistic)/审计(Audit)
统计代码的有效行数以衡量生产率，个人工作量。
审计则可能包括审计工件命名风格，命名规范，多语言处理，异常处理等等。自动审计功能配合合适的管理制度，有助于帮助企业实现开发的规范化。
3. 编译或加工
编译很容易理解，这里的加工指对源代码进行某种事先处理，比如根据源代码生成配置文件和部署描述文件。另外，还可能包括特殊目的的代码替换和测试覆盖插入（Source Code Instrumentation）。
4. 部署、配置
让一个软件运行起来可能需要进行配置和部署。比较典型的是j2ee的程序，需要配置客户端和在应用服务器部署EJB描述符。
5. 运行
让软件按照特定的要求运行起来。（比如按照单元测试的要求，或者按照性能测试的要求）
6. 测试
日构建中可以引入各种测试。比较常见的是单元测试，实际上能够够自动化验证的集成测试和性能测试也可以加入进来。
7. 测试统计和审计
测试过后可能留下许多测试数据，比如单元测试的成功比例，每个单元测试执行的时间，性能测试留下的分析数据等等，这些数据可以在这一步充分利用起来，通过分析得出某种结论。
8. 发布报告和邮件通知
日构建过后，除了输出各种工作组件，重要的还要发布日构建报告。日构建报告最好以网页的形式在一个固定的地方公布，内容可以保罗万象，比如模块的责任人、编译成功与否、部署成功与否、单元测试的个数、单元测试的成功率、代码覆盖率、工件统计等等。为了便于大家察看，可以附带简要的邮件通知。
