这个过程就是，每天把所有代码文件编译、链接、组成一个可执行程序，然后对这个程序进行冒烟测试，也就是一个相对简单的检查，看一看这个程序是否能够体现出程序正常运行所能体现的一些最基本的正常表象。
这样做的好处是：
- 最小化了集成阶段的工作风险，减少了后期成本；
- 降低了最后产出的软件产品质量低的风险；
- 让故障诊断变得容易；
- 增强了团队对软件项目质量的信心，提高了大家士气；
怎么做好每日构建呢？
每日构建，顾名思义就是每日进行的。如果把每日构建形容为一个项目的同步脉搏。那么在这些脉搏之间不同的开发者的代码，允许有一点不同步，但是在每个同步点，这些代码必须返回到同步的状态。当我们坚持保证所有的同步脉搏，你就能保证开发团队不会失去同步。这样，我们的软件项目就会尽可能的可控。
在实际构建工作中，我们应该根据项目的规模，预期每天的开发工作量来决定构建的周期，当然周期应该不会太长。过于频繁，可能会让开发和测试每日在构建过程中花费过长的时间；反之，不能很好的控制好我们的质量。
对无效的构建进行检查
每日（周期性）构建过程中的软件应该能够工作。如果这个软件不可用，那么这个构建应被认为无效的，修复这个构建的任务被认为是最高优先级的。一个“良好的”构建至少应该做到：
成功的编译所有的文件、库和其他部件；
成功的链接所有的文件、库和其他部件；
不包含任何关键错误，如这些缺陷可能使程序不能启动，或者可能对运行有困难；
通过冒烟测试。
那么，什么是冒烟测试呢？
冒烟测试应该对整个系统进行端到端的验证。通常我们会事前设计一些冒烟测试用例，然后对其进行测试。它不应该是详尽而周密的，但是它应有能力暴露出主要问题。如果构建通过冒烟测试，则认为足够稳定的并可以用来进行后续的详尽测试。
在实际工作中，除了每日构建的冒烟测试外，在开发交付详尽测试时，测试团队也应该首先根据冒烟用例来进行冒烟测试：如果测试通过，我们即可进行后续的详尽测试，如系统测试；如果没有通过，那么应该返回给开发，让其进行修复后再进行冒烟测试，直到通过冒烟测试为止再进入到后面的详尽测试。
冒烟测试必须随系统的演进而演进，即应该实时的增加对应的冒烟用例，以及冒烟测试的工作范围。
当然，冒烟测试可能对于运营系统，MIS、BBS、OSS等系统不一定适用。所以我们应该根据具体的项目来决定是否采用。