每日构建和冒烟测试也存在一些风险和缺陷，具体主要有

    1.给开发人员太大压力，开发每天都在较紧张环境中工作

    2.需要额外的测试人力资源和每日构建硬件环境的投入

    3.开发人员不能专注，既要分心去修改BUG，又要开发新的功能点

    4.对开发负责人要求更好，需要将功能细化到1-2天的有明确输出的功能点

    5.开发需要投入额外的精力来保证每日构建顺畅

    适用场景 

    1.对进度偏差控制和要求很高的项目

    2.开发检查点和里程碑制定的很细致的项目

    3.采用增量和迭代开发的项目,快速和敏捷开发的项目

    每日构建提前需要进行的准备工作

    1.对开发进度计划的要求，需要细化出每1-2天的开发进度计划，可以到一个很小的功能点。

    2.对每日构建测试计划的要求，需要根据开发进度计划来安排冒烟测试和系统测试进度计划。

    3.需要提前准备好每日构建的环境(每日构建必须是独立的环境)

    每日构建和冒烟测试工作的实现可以人工来实现，但更多的需要借助些自动化的工具来完成。对于每日构建一般要提前编写好每日够建的脚本，可以借助Ant或NAnt构建工具来完成。每日构建脚本的复杂性跟项目或系统本身复杂性相关，对于简单的只有一个项目的解决方案，可能构建脚本会很简单，而对于较复杂的系统或项目构建脚本将会教复杂。NAnt是一个强大的通过构建脚本自动编译的工具，在NAnt里面会做如下事情，而这个即使打开解决方案来编译也无法做到。

    1.调用批文件重新自动生成数据访问层组件

    2.创建相关的部署需要的cs_client,bs_client,server,service相关目录并拷贝公用文件

    3.按照公用项目->逻辑层->界面层顺序和项目间依赖关系对各个项目逐一编译

    4.调用外部工具soapsuds生成数据访问dll的代理类文件,逻辑层重新引用代理类进行编译(分布式部署需要)

    5.引用3,4步需要的dll对Web项目进行编译

    6.拷贝编译结果到相关的输出目录

    每日构建和每日编译的最大区别就在于是否进行了冒烟测试，系统必须通过了冒烟测试才能够算每日构建成功。而测试人员人工介入的测试是基于冒烟测试通过的基础上面的。这里很简单一个例子，如我们NAnt配置文件忘记拷贝一个公共文件到server目录了，这个时候每日编译可能是通过的，但如果把这个版本部署出去测试无法进行测试的。或者说冒烟测试的一个重要作用就是要彻底解决由于构建自身原因引起的各种缺陷或Bug。

    冒烟测试由于要验证整个编译的正确性，因此冒烟测试必须是针对整个系统进行冒烟测试。但冒烟测试只需要关注系统的主体功能即可，通过冒烟测试并不是说系统没有BUG，只是说通过了冒烟测试后可以说系统是一个稳定的版本，说系统的每日构建是成功了，代表系统可以转交专门的测试人员进行测试了。冒烟测试工作一般要采用自动化来进行，可以借助如LoadRunner等工具来录制自动化测试脚本，冒烟测试的脚本应该由专门的测试人员来维护，而且随着测试的进展冒烟测试脚本也应该是不断增加和补充的。

    对于每日构建失败，直接责任的开发人员需要程度责任并付出代价。微软顾问经常爱举的一个例子就是凌晨2,3点开发人员被叫到公司解决每日构建失败的问题的案例。实际操作可能很难，但对构建造成影响的必须要承担应有的责任。

    每日构建一般要配合使用源代码管理工具，而构建时间一般安排在每天下班后或晚上进行。开发人员需要保证每天检入的代码是能够顺利编译通过的，并保证在本机已经做了相关测试。每日构建并不是一定要要求每天都有新的功能点完成，如果今天开发完成的东西不是一个独立的可以提交测试的功能点，这个时候当天的源代码最好不要检入。代码的检入周期一般要在2-3天内，如果周期再长基本上就达不到每日构建的作用了。

    每日构建必须有独立和专门的构建服务器和构建环境。构建服务器和构建环境与测试环境的最大区别在于构建环境是完全Copy开发环境，单独出构建环境目的是保证构建过程不和开发环境和过程冲突。如果条件不允许的话可以将构建环境和测试环境合并，但构建环境必须和开发环境分离。

    每日构建的成功要素

    1.每天都进行编译和冒烟测试

    2.冒烟测试脚本随着测试的进度不断完善和补充

    3.构建成功在项目中拥有较高的优先级

    4.通过过程的制定保证构建失败更多的是因为异常因素而非规则不清

    5.在压力下不要抛弃过程