在XP开发理念中，很重要的就是要能够Daily Build，主要的理由是频繁的发布，频繁的获得反馈。但是从实际开发过程中来看，在开发的不同阶段，对于DailyBuild的需求是不一样的。在原型开发阶段，大家都在忙着写自己的部分，所有的模块还无法组装到一起时，DailyBuild其实没有什么意义，测试人员即便拿到了DailyBuild的时候，也无法进行集成测试。

DailyBuild同时也不是很适用于尚处于Unstable状态的Open Source的项目，记得一个人在批评Borland公司的Delphi8的时候曾经说过，他不喜欢为别人做免费的Beta测试。我同样也不喜欢，最近开发一个东西用到了一个Open Source的组件，结果花了一天时间来为它改bug，感觉很不爽。

此外，对于比较庞大的系统来说，DailyBuild意义也不是很大，比如我正在做的一个系统，几年的开发累计的代码已经超过了300万行，每次做一个自动任务的回归测试都需要至少4天的时间，DailyBuild基本上来说没什么价值。而且对于这么庞大的项目来说，我们甚至是反对DailyBuild的，因为一个人check-in了一个无法编译的错误代码，会导致其他人get后，产生一大堆的编译问题。据我所知，微软在开发Win2000的系统时，曾经有一次一个team check-in了一个无法编译的代码，导致7000多个编译错误，造成了一片混乱，为了定位和消除影响，花了好几天的时间，从那以后，Win2000开发组采用的是每个小组建立自己的开发模块的分支版本，只有在自己的分支版本经测试稳定后，才check-in到主版本。

同样对于，测试人员来说，他们也不喜欢DailyBuild，因为在测试过程中最消耗时间的是回归测试，而很多回归测试比如很多同界面操作相关的测试是没办法或者很难使用XUnit或者Robot自动完成的，更多的时候是依赖于手工来完成，如果频繁发布DailyBuild版本的话，就需要重复做回归测试，这对于大型的商业项目来说是不可接受的。所以，我们每发布一个新版本都至少要间隔一个月，发布前需要做一个代码的分支版本，最终Release的是分支版本，对于发现的Bug修正在分支版本和主版本上同步实现，而新功能的添加则完全在主版本上进行。这样才能保证产品质量的相对稳定。