# 十、每日连编是朋友 自动地一因为你设定代码每天在固定的时间构建。在Unix环境下使用cron在windows下使用“任务 计划”。 每天一或者更频繁.当然每天构建的次数越多越好啦。但是有时候构建次数还是有上限的，原因和 版本控制有关系，等会儿我会谈到的。 完整地一很可能你的代码有多个版本。多语言版本，多操作系统版本，或者高端低端版本。每日构建 (daily build)需要构建所有这些版本。并且每个文件都需要从头编译，而不是使用编译器的不完美的增 量编译功能。 以下是每日构建（daily build)能带来的好处： 当一个bug被修正了，测试者可以很快得到最新的修正后的版本开始重新测试，以验证bug是否真正地 被修复了。 开发人员可以更加确定他们对代码做的修改不会破坏1024个操作系统上的任何一个版本。验证这一点 不需要在他们的机器上安装OS/2 (IBM公司生产的PC机操作系统）。 那些每天将修改过的代码导入（check in)版本控制服务器的开发人员知道，他们对一个模块导入的 修改不会拖别的开发人员的后腿。拖后腿的意思是，那些开发别的模块的程序员使用这个修改过的模块， 出了问题，于是他们自己的模块也没有办法开发下去了。每日构建则不会有人拖后腿。如果把一个开发团 队比作一台PC机，那么团队中的一个程序员对某个模块的修改导致其他人无法开发别的模块，相当于PC机 发生了蓝屏。当一个程序员忘记把他（她）新建立的文件导入到repository (指版本控制服务器上的代码 树）时，这种开发过程中的“蓝屏”会经常发生。因为在这个程序员自己的计算机上有这个文件，所以他 (她）构建这个程序没有问题。但是其他程序员是从版本控制服务器上导出（check out)代码的，由于 服务器上没有这个文件，他们遇到了链接错误（link e「「o「），无法继续工作了。 外部团队（例如市场销售部门，进行beta测试的一些客户）可以获得一个比较稳定的版本，这样对他 们开展自己的工作比较有利。 假如你将每日构建出的二进制文件（例如一个可执行程序，一个dll等等）存档管理，那么当你发现一 个非常奇怪的，无法解决的bug时，你可以通过对这些文件进行二进制搜索（binary search)来确定什么 时候这个bug第一次出现。如果有对代码进行了完善的版本控制，你也可以找出是谁在何时对代码进行的导 入（check in)导致了这个bug。 当开发者修正了测试者报告的一个错误时，如果测试者同时报告了发现错误时的构建的版本，开发人 员可以直接在那个版本中测试是否bug真正被修复了。（译者按：测试者报告出现了一个bug,只是报告了 一个错误症状，而错误的原因可能有多个，每个原因可能在不同的模块中。前文中的方法是为了避免只修 正了一个模块中一个原因，别的模块由于在变动，于是掩盖了而不是修复了bug)以下是如何进行每日构建（dai lybui ld)的具体步骤。你需要用最快的电脑建立一个每日构建服务器。 写一个脚本，可以自动从版本控制服务器中导出（checkout)完整的代码，（你当然使用版本控制，不是 吗？），然后对代码从头开始进行构建（build)，要构建所有的版本。如果你有一个安装打包程序，也要 在脚本中自动运行。所有会卖给最终用户的东西都要包括在构建过程中。把构建出来的版本放在各自的的 目录里，不同时间构建的相同版本也应该按日期整理好，不要相互覆盖。每天固定的时间运行这样的脚本。 最关键的是所有这些步骤都应该由脚本自动化完成，从导出（checkout)代码到将最终产品放在网上 供用户下载（当然在开发阶段，产品是放在一台测试服务器上的）。要保证开发过程中的任何东西的任何 记录是由文档记录的而不是由某个人的脑子来记录的，这是唯一的办法。否则你会碰到这样的情况，产品 需要发布了，可是只有Shaniqua知道如何将产品打包的，可是他刚刚被巴士撞了。在Juno公司（本文作者 工作过的公司之一），要进行每日构建，你唯一需要学会的东西就是双击每日构建服务器桌面上的一个快 捷方式。 如果你在发行程序的当天发现了一个小bug,没有问题。修正它，然后重新运行每日构建脚本，现在你 可以安安心心的发行程序了。当然，黄金定律是每日构建脚本应该是把所有的事情从头做一遍，遵循这个 定律就不会有什么问题。 将你的编译器的警告参数设到最大（在微软的VC中是-W4 ;在GCC中是-Wall),当遇到任何一个最微 小的警告时就应该停下来。 如果每日构建失败了，可能整个开发团队的工作会因此进行不下去。当务之急是立刻找出原因，使得 每日构建能成功进行下去。某天也许你会一天运行好几次每日构建脚本的。 每日构建一旦失败，应该自动地将失败用email通知整个团队。提取错误日志中的恰当部分并包括在 email正文中也不是很难。每日构建脚本也可以将当前的状态报告整理成一个html文件，自动发布到一个所 有人都可以访问的web服务器上，这样测试者可以很快知道那个版本的构建是成功的。 当我在微软的excel团队中工作时，我们的一个有效办法是，谁导致每日构建（daily build)失败， 他（她）就得负责照看当日的每日构建（译者按：微软通常每日构建都在半夜），直到有另一个人导致构 建失败而接替他（她）。这样做当然可以使每个开发者都小心不要因为自己代码的错误破坏了构建，更重 要的是团队中的每个人都可以学会每日构建（daily build)的原理。 如果你的团队在同一个时区工作，在午饭时间进行每日构建（daily build)是个不错的主意。午饭前 每个程序员导入（check in)代码，这样当程序员在吃饭时，构建系统在工作。当程序员吃完饭回来时， 如果每日构建失败了，所有的人也都在，可以尽快找出失败的原因。当构建系统运作起来时，没有人再会 担心别人导入（check in)代码会妨碍自己的工作了。 如果你的团队同时在两个时区工作，计划好每日构建（dailybuild)的时间使得一个时区的工作不会 影响另一个时区的工作。在Juno公司，纽约程序员在晚上7: 00导入（checkin)到版本控制服务器。如果 他们的导入导致构建失败，印度Hyderabad市（译者按：印度科技重镇）的程序员在纽约时间晚上8: 00以 后的工作几乎无法进行下去。我们每天进行两次每日构建（dailybuild)，每次构建的时间都在两地的程 序员回家之前，这下就没有问题了。