每日构建（daily build）是你的朋友(Joel on Software)[2]|中文方案文档站(提供各类方案下载,WORD文档下载,范文,案例等)

最关键的是所有这些步骤都应该由脚本自动化完成，从导出（check out）代码到将最终产品放在网上供用户下载（当然在开发阶段，产品是放在一台测试服务器上的）。要保证开发过程中的任何东西的任何记录是由文档记录的而不是由某个人的脑子来记录的，这是唯一的办法。否则你会碰到这样的情况，产品需要发布了，可是只有Shaniqua知道如何将产品打包的，可是他刚刚被巴士撞了。在Juno公司（本文作者工作过的公司之一），要进行每日构建，你唯一需要学会的东西就是双击每日构建服务器桌面上的一个快捷方式。
如果你在发行程序的当天发现了一个小bug，没有问题。修正它，然后重新运行每日构建脚本，现在你可以安安心心的发行程序了。当然，黄金定律是每日构建脚本应该是把所有的事情从头做一遍，遵循这个定律就不会有什么问题。
将你的编译器的警告参数设到最大（在微软的VC中是-W4 ; 在GCC中是-Wall），当遇到任何一个最微小的警告时就应该停下来。
如果每日构建失败了，可能整个开发团队的工作会因此进行不下去。当务之急是立刻找出原因，使得每日构建能成功进行下去。某天也许你会一天运行好几次每日构建脚本的。
每日构建一旦失败，应该自动地将失败用email通知整个团队。提取错误日志中的恰当部分并包括在email正文中也不是很难。每日构建脚本也可以将当前的状态报告整理成一个html文件，自动发布到一个所有人都可以访问的web服务器上，这样测试者可以很快知道那个版本的构建是成功的。
当我在微软的excel团队中工作时，我们的一个有效办法是，谁导致每日构建（daily build）失败，他（她）就得负责照看当日的每日构建（译者按：微软通常每日构建都在半夜），直到有另一个人导致构建失败而接替他（她）。这样做当然可以使每个开发者都小心不要因为自己代码的错误破坏了构建，更重要的是团队中的每个人都可以学会每日构建（daily build）的原理。
如果你的团队在同一个时区工作，在午饭时间进行每日构建（daily build）是个不错的主意。午饭前每个程序员导入（check in）代码，这样当程序员在吃饭时，构建系统在工作。当程序员吃完饭回来时，如果每日构建失败了，所有的人也都在，可以尽快找出失败的原因。当构建系统运作起来时，没有人再会担心别人导入（check in）代码会妨碍自己的工作了。.
如果你的团队同时在两个时区工作，计划好每日构建（daily build）的时间使得一个时区的工作不会影响另一个时区的工作。在Juno公司，纽约程序员在晚上7：00导入（check in）到版本控制服务器。如果他们的导入导致构建失败，印度Hyderabad市（译者按：印度科技重镇）的程序员在纽约时间晚上8：00以后的工作几乎无法进行下去。我们每天进行两次每日构建（daily build），每次构建的时间都在两地的程序员回家之前，这下就没有问题了。

每日构建（daily build）是你的朋友(Joel on Software)[2]

[入库：2006年2月23日] [更新：2007年3月24日]