每日构建与持续集成联系与区别
1）持续集成（Continuous Integration）贵在速度，强调一个快速反馈。
比如我一签入代码，就立刻集成，给我一个反馈，我要知道我的代码是否破坏掉了构建。
持续集成是和单元测试结合在一起的，也就是说一般持续集成的时候都要做单元测试。但持续集成中不能加入更多影响“快速反馈”这条宗旨的东西，比如不能加入大量的集成测试，冒烟测试的代码，尤其是当这些代码严重影响到集成时间的时候。
持续集成一般由每次签入代码触发。我先签入代码我就要先看到构建结果，你后签入，你就要排在后面。这就要求构建时间不能太长。否则在构建的时候有很多人签入代码了，就很难知道到底是谁的代码破坏了集成,很难定位问题，反映签入代码的问题，不能给签入代码的人快速提供明确的信息。因为一般由后签入代码的人来保证集成的成功。
持续集成可以是增量构建，也可以是完全构建。当完全构建时间很长的时候， 一般采用增量构建。
我记得Martin Flower关于持续集成写过两篇文章，如果我没记错的话，好像是第一篇比较鼓励放入很多的测试到持续集成中，但是后来他对自己的说法进行了修正，说不能把很多影响集成的东西都加入进去，要保持快速集成，快速反馈，否则很难做到持续集成。
刚查了下最新版的《Continuous Integration》。上面对持续集成的实践是这样概括的，更说明了持续集成要快速反馈的重要性。
# Practices of Continuous Integration
* Maintain a Single Source Repository.
* Automate the Build
* Make Your Build Self-Testing
* Everyone Commits To the Mainline Every Day
* Every Commit Should Build the Mainline on an Integration Machine
* Keep the Build Fast
* Test in a Clone of the Production Environment
* Make it Easy for Anyone to Get the Latest Executable
* Everyone can see what's happening
* Automate Deployment
地址在这里，大家有兴趣可以去看看。
http://martinfowler.com/articles/continuousIntegration.html
2）每日构建（daily build），这个提法最早的出处，我也不知道在哪里，不过看过《微软的秘密》这本书，微软很早就做每日构建了，忘记看过Steve-McConnell啥文章，还是书了，他也提到了每日构建。
我自己感觉每日构建在快速反应上没有持续集成那么强，但是他更强调的是质量更能衡量项目的进度。
--- 由于持续集成的宗旨，决定了他不可能加入很多的测试，而每日构建则不然我们知道每日构建一般都会安排在夜里进行构建，这个时候我们有充足的时间来做构建，那么这个时候我们就可以做更多的事情，比如代码质量检查，命名规范单元测试，测试覆盖率，集成测试，冒烟测试，代码安全性检查.....等等都可以这里来做。对代码，对构建的要求更高。许多在持续集成中没能发现的问题，在这里都能发现。
--- 每日构建，因为是在晚上执行，会把当天所有的变化的代码都一起做集成，而不像持续集成是每次仅仅把自己的代码和以前的代码做集成那样。
持续集成可以是增量构建的，但是每日构建却总是一个完全构建。
--- 每日构建是项目的心跳线。一般来讲，通过每日构建我们就能看到项目的进度。比如今天有5 个bug的代码都提交了，第二天我们发现每日构建成功了，那么项目就又往前迈了一大步，项目又有所进展了。
