先从每日构建说起：每日构建是什么？

每日构建对应的英文是Daily Build，由于翻译和理解的问题，也有称之为“每日编译”

由于一般的每日构建发生在晚上，发生在晚上的每日构建，也称为Nightly Build ，中文译为“夜晚构建”或者“晚间构建”，百度检索下，“夜晚构建”要远多于“晚间构建”。

来自 http://en.wikipedia.org/wiki/Daily_build

A daily build or nightly build is the practice of each day doing a software build of the latest version of a program. This is so it can first be compiled to ensure that all required dependencies are present, and possibly tested to show no bugs have been introduced. The daily build is also often publicly available allowing access to the latest features for feedback. In this context a build is the result of compiling and linking all the files that make up a program.

译文：每日构建 或者 夜晚构建 是指每天根据最新程序版本进行软件构建的实践。因此它可以第一时间编译，确保所有必需的依赖关系存在，并有可能进行测试，显示没有新加入的错误。每日构建为了获得反馈一般也允许公开访问最新功能。

每日构建与持续集成的区别

1，持续集成发生在程序检入时，一般一天之内有多次进行，多人次检入将触发多次持续集成；而每日构建每天只发生一次，一般在所有人提交了代码之后的晚上，

2，即时获得反馈的持续集成的时间一般不长于5分钟，当天获得反馈的持续集成时间一般不长于3小时，时间越长的话，就越是接近于每日构建，隔天获得反馈的持续集成就是广义的持续集成（如果认同广义说法的话），实质上就是每日构建了；每日构建的时间窗口比较长，典型的晚上10点到第2天早上9点，可以支持大型构建，并配套进行各类测试

3，持续集成虽然时间短，但快速测试是必不可少的；每日构建并不强制要求进行测试，当然事实上，多数进行的每日构建，包括进行测试

有观点认为每日构建属于持续集成，算是持续集成的一种。其实这只是说法，无论算还是不算，每日构建和典型的持续集成是不可以互相替代的。

每日集成是什么？

根据业界关于每日构建的最佳实践，每日构建一般配套的都会进行自动测试，一个更加准确的词汇应当出现，那就是每日集成，Daily Integration

笔者给出的定义：每日集成是指每天自动检查并编译当天最新的全部程序，并基于最新编译结果自动开展测试。

多数每日构建已经符合每日集成的定义，但每日构建并不强制要求测试，为了与传统的每日构建区分开来，所以采用每日集成（Daily Integration)这词。

如何做每日集成？

每日集成的步骤

1，第一天下班前，所有修改的代码得到提交；

2，第一天晚上，一般没人加班的时候，自动检出所有代码，以下动作都为自动；

3，进行静态代码分析；

4，编译全部代码；

5，进行编译后代码分析；

6，部署到所需的测试环境，可能是多个；

7，进行单元测试；

8，进行接口测试，接口测试和单元测试可以合并在一起，共同的特征是非界面的测试；

9，进行界面测试；

10，收集各步骤的结果，进行度量，将所需信息发送email给相关人员

11，第二天上班时，分析每日集成的结果，优先处理每日集成发现的问题

对照定义，要做到每日集成，3和5推荐至少选择一个，7、8、9必须至少选择一个。

如果两个不同时区工作的话，那么要精心挑选每日集成的时间窗口，并且要控制每日集成需要的总时间不超过时间窗口。

对于中国和欧洲，下午有重合的工作时间，如果要大集成的话，中国时间晚上24：00是中欧都下班的时间，到中国时间白天9：00是每日集成的时间窗口。对于中国和美国西海岸，中国时间晚上6点到第2天凌晨1点是一个时间窗口。

当然如果每日集成执行的足够快，那么安排在中午午餐时间也是完全可以的。一天进行多次每日集成也是可以的，这就与持续集成颇为接近了。两者之间存在紧密的亲缘关系，这也就是有人认为每日集成可以算是持续集成的一种。

每日集成的好处

显然的每日集成包括了每日构建，所以也就获得了每日构建的种种好处，汇总起来，有如下的好处：

尽早集成，尽早发现问题并解决，避免最后阶段大集成失败的风险

监控代码内在质量和技术债务，代码编写的最佳实践或应当避免的不利写法得到工具检查， 技术债务维持在合理可控的范围

开发人员可以更加确定他们对代码做的修改不会破坏的任何一个版本，如果出现问题，第2天的集成报告会告诉哪里出了问题。

那些每天将修改过的代码导入（check in）版本控制服务器的开发人员知道，他们对一个模块导入的修改不会拖别的开发人员的后腿。拖后腿的意思是，那些开发别的模块的程序员使用这个修改过的模块，出了问题，于是他们自己的模块也没有办法开发下去了。每日集成则不会有人拖后腿。如果把一个开发团队比作一台PC机，那么团队中的一个程序员对某个模块的修改导致其他人无法开发别的模块，相当于PC机发生了蓝屏。当一个程序员忘记把他（她）新建立的文件导入到repository（指版本控制服务器上的代码树）时，这种开发过程中的“蓝屏”会经常发生。因为在这个程序员自己的计算机上有这个文件，所以他（她）构建 这个程序没有问题。但是其他程序员是从版本控制服务器上导出（check out）代码的，由于服务器上没有这个文件，他们遇到了链接错误（link error），无法继续工作了。

外部团队（例如市场销售部门，进行beta测试的一些客户）可以获得一个比较稳定的版本，这样对他们开展自己的工作比较有利。

假如你将每日构建出的二进制文件（例如一个可执行程序，一个dll等等）存档管理，那么当你发现一个非常奇怪的，无法解决的bug时，你可以通过对这些文件进行二进制搜索（binary search）来确定什么时候这个bug第一次出现。如果有对代码进行了完善的版本控制，你也可以找出是谁在何时对代码进行的导入（check in）导致了这个bug。

当开发者修正了测试者报告的一个错误时，如果测试者同时报告了发现错误时的构建的版本，开发人员可以直接在那个版本中测试是否bug真正被修复了。测试者报告出现了一个bug，只是报告了一个错误症状，而错误的原因可能有多个，每个原因可能在不同的模块中。前文中的方法是为了避免只修正了一个模块中一个原因，别的模块由于在变动，于是掩盖了而不是修复了bug

当一个bug被修正了，测试者可以很快得到最新的修正后的版本开始重新测试，以验证bug是否真正地被修复了

每日集成环境建成后，全自动化运行，节省大量人工劳动，提升了编译集成打包的效率

如上所述，缺陷将尽早发现尽早修复，提升软件产出质量，进而提升开发效率

每日集成的工具

因为每日集成的主体是全自动过程，所以每日集成对工具高度依赖，没有工具就没有每日集成。而且，一般的每日集成依赖于多个工具组合。

1，配置管理类工具：Git，SVN，TFS，CVS，ClearCase等等

2，集成管理类工具：Jenkins（原名Hudson），CrouseControl

3，编译类工具：maven, ant,nant等等

4，测试类工具：xUnit系列，Selenium，QTP等等

5，代码检查类工具：Sonar,PMD,Findbugs, Checkstyle, Fxcop等等

6，度量监控类工具，集成监控类CCTray，Jenkins; 覆盖率度量 emma, jacoco，NCover等等

以上列表还不是全部，为了在集成及集成配套动作方面得到更多好处和便利，外围还有更多的工具，而且在持续的增加

对应于特定的开发环境，可以找到各类工具，有些工具以插件的方式提供，比如Jenkins附带很多插件，甚至也可以自己开发配套工具（插件）

每日集成对于敏捷软件开发的意义

目前(2013年7月）而言，每日集成的名气远远小于持续集成，每日构建虽然早就出现，但其热度在敏捷世界貌似也远比不上持续集成。持续集成随着XP的推广而闻名遐迩，广为人知。

而从敏捷软件开发宣言和原则来看，每日集成是完全符合宣言和原则的好实践。虽然每日集成的实践并不是敏捷世界原创的，但支持技术优秀的工具和方法，并不因为非敏捷原创而反对。

每日集成带来了快速反馈，每日集成的时间窗口要远远长于持续集成的时间窗口，可以完成包括界面自动化测试在内多个费时的任务，可以给软件进行一次全身体检（对于超级复杂大软件，采用并行编译集成测试的方法，但仍然不排除一晚上的时间仍然不够，这种境况下，每周集成weekly integration是个选择）。

对于还没有开展持续集成的软件开发团队而言，每日集成是值得优先于持续集成采纳的技术实践。原因如下：

1，每日集成拥有的时间窗口长于持续集成，可以把多种活动加入到每日集成，比持续集成更加全面

2，对原有开发的变更幅度小于采纳持续集成，在熟悉了每日集成后，再进行持续集成，这样的学习曲线要优于先采纳持续集成

对于已经开展了持续集成的软件开发团队而言，只需迈出几步，就能进行每日集成，获得更多好处：

1，将所有持续集成所用到的测试全部加入到每日集成，由于持续集成时间窗口短，随着时间推移，部分持续集成的测试用例可能已经被移出了最经常集成的集合，那么每日集成的测试集欢迎这些测试。

2，原持续集成环境略加配置，加上每日集成即可

3，逐步加入界面自动化测试

4，考虑加入代码检查分析

说明：在持续集成的基础上进行每日集成，并不是替代持续集成，两者作用是不同的。