刚才令狐说：
刚刚我在一个小时之前下载了一个DeerPack，当时还是Alpha 1，过了一个小时，就看到论坛上说Alpha 2出来了，然后去同一个地址下载，就变成Alpha2了
所以我们就这里开始简单讨论了一下关于Daily Building的话题。
我觉得不论是不是用XP，这个Daily Building都是很重要的，因为只有这样，才能准确地把握开发的进度，并且更好地保证软件的质量。
至于具体做法，说实话，我也没机会做过，据说有一些像FinalBuild这样的工具可以很方便地实现。当然对于不复杂的东东也是有很多替代方法的，比如老土的makefile，或是用一些脚本（shell、PERL、Python……），都可以实现。
剩下就是如何运作的问题。
我的设想是这样的：
每天一上班，质量部门就在SCM中创建一个Build版本分支，并把下班前一到两小时定为Build时间。
开发人员在Build时间之前把通过单元测试的稳定代码Commit到这个Build版本分支里。在Commit之后，开发人员可以继续进行开发工作，并在下班前将代码Commit到主开发版本里。
质量部门在Build时间从Build版本分支中Checkout出代码，并进行集成编译及测试，确定没有问题以后，就可以拥有一个相对稳定的版本。之后，比如第二天上班时，质量部门就可以把这个稳定的版本分支与主版本合并，再创建一个新的分支，然后重复上面所说的过程。
这一迭代过程重复进行下去，软件项目就可以很扎实地一步一个脚印地进行下去，不容易出现失控的情况。
所以我认为，在软件开发工具中，SCM是最重要的工具。像CVS/SVN都可以很好地实现上面所说的功能，不过VSS就比较困难了。
dailybuild是一种好思想,但我觉得执行起来并不一定是要拘泥于某中形式或时间限制,build的频率取决于软件当前的阶段.
受教。我再仔细想想。
节奏跟制度是两回事.
我不同意熊的看法。dailybuilding最重要的就是节奏的把握，如果没有固定的频率，就会很容易陷入失控的状态。
是一回事，没有制度化的约束就很容易失控。daily building的作用与milestone是不同的，它不应该根据软件的当前阶段来。
下载地址~~~~~Google不到。
我更倾向于认为如果一个对开发有帮助的思想，行为,一旦制度化,甚至出现强制性,惩罚性,那么很容易成为形式,让人忘了做这事情的究竟目的使什么,而容易出现执行不力的后果.这种例子在我接触过的几个公司里颇为常见,我觉得,如果软件质量落到必须靠某些强制制度来保证的时候,那么问题早就在这些”制度”的范围之外了.到不是否认这些制度包括DailyBuild的功效,只是觉得,在讨论制度，规范之外,人的因素更重要.