在日构建的驱动下，项目的进度将会变得非常的明显。每一天的构建结果将会通过某个渠道发布出来，团队和团队的老板可以看到软件现在的样子，项目的完成情况，出现的问题等等。这些信息构成了软件开发的基本信息。不但可以清晰地描述出项目进度，也为管理人员安排计划提供了基础数据的支持。有了基本的量化数据，软件开发才不是靠拍脑袋出成果的。
日构建的最后一个价值是提供了整合性。目前软件开发中并没有一种统一的管理软件，未来似乎也很难做到，因为不同的软件组织差异很大。在开发过程中，一些有价值的实践被加入、集成到日构建的过程中，在日构建的推动下，这些优秀实践很容易成为开发过程的一部分。在文章倡导的另一个优秀实践－测试驱动开发实践，就很容易集成到日构建中来。事实上，软件测试是非常重要的，它已经成为日构建成功的判别因素。
选择日构建还是持续集成
虽然日构建和持续集成的本质是相同的，但是他们在集成的频率方面的差异也导致了一些管理上的差异：
首先，日构建树立了一个明确的以工作日为单位的小目标，团队的目的就是为了使代码能够通过每天的构建。开发人员在明确的目标的指导下，往往能够发挥出很高的效率。持续集成则将这个频率变得更小，只要你的代码提交到代码库中，立刻就会检验你的成果，如果有问题，你必须立刻排除，否则，要么集成的过程无法继续，要么出错的开发人员的信箱被集成过程中的警告信息所填满。这种做法对团队的要求要更高一些。对于刚刚开始接触日构建的团队来说，可能会手忙脚乱。
其次，日构建有一条非常明确的分界线，开发工作要么是完成，要么是没有完成，不存在第三种状态。
日构建的基础实践
日构建的基础包括三个实践：自动构建、统一代码源和集成测试。
自动构建
自动构建的思路是通过脚本语言，而不是通过在IDE环境中点击构建按钮来完成项目的构建过程。日构建需要不断的进行集成的工作，如果手工来完成这项工作，既费时，效果又不好。所以更聪明的做法是把这件工作给自动化。在早期的Unix环境中，都是采用Make编写相应的脚本来完成构建的过程。随着先进的IDE环境的发展，慢慢的人们就不愿意再编写Make脚本了。可是现在，为了自动构建的目标，我们需要回归到手工编写Make脚本的历史上去。应该说，IDE环境中的构建方式侧重于个人开发，而自动构建则侧重于团队开发
自动构建目标就是通过一个简单的命令就能够全部的构建过程。
统一代码源
其次，保证一个开发团队共享统一的代码源。这时候我们需要使用版本控制工具。共享的代码库同样也是XP的一个基本实践。虽然XP还要求开发人员可以修改他人的代码，但我们并不提倡这种做法，这要求团队成员之间有非常高的默契程度。统一的代码源能够保证所有人的代码都归总到一起，这是日构建的基础。如果没有这一点的保证，每一次的构建我们都不得不把所有人的代码集中起来，这无疑会使构建过程变成灾难。
统一代码源能够保证任何一位团队成员获得所有的代码，并以此为基础进行开发。
集成测试
只是把代码编译通过并不能够证明软件可以正常工作，评价软件的标准应该是测试。在日构建中必须要执行集成测试，来保证软件确实是能够工作的。
集成测试也是一个同义词相当多的名词，有人把它称为验证测试（BVT－Build Verification Tests），因为他们认为这种测试主要的目的是为了验证构建的正确性。有些人把它称为冒烟测试（Smoke Test），因为他们觉得这个测试的目的是运行软件，看它是否会"冒烟"。
测试应该全部执行完毕，而不是遇到未被满足的错误就放弃测试过程。测试将形成结果，成功的测试，失败的测试，失败测试的细节。最后的结果将通过某种方式通知给相应的人员，要求他们修改设计或测试（如果是测试本身的问题的话）。
集成测试是证明构建成功的关键因素。和构建一样，集成测试也应该是自动化的。
文章来源于领测软件测试网 https://www.ltesting.net/
