概述

在昨天“正确地做事(善用工具)”的帖子里提到了代码提交频度的问题。当时我特别强调了“要保证提交的代码能编译通过”，理由是“对于每日构建很重要”。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。

照例先来说说什么是“每日构建”，每日构建在洋文里也称为Daily Build或者Nightly Build。具体定义见“这里”。简单地讲，就是每天都把整个软件项目自动编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。

为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子：

1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。

2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。

3、知名的开源组织Mozilla也大量使用每日构建。

4、知名的Linux发行版Ubuntu也使用每日构建。
　......

上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可能要问了，具体有些什么好处捏？请看“软件工程进阶之每日构建[1]：好处和优点”。

[1]：好处和优点

上一个帖子“软件工程进阶之每日构建[0]：概述”提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。

话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现bug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试......

★案例1（开发的混乱）

　有一天，开发组的小头目找来程序员甲。
　>>小头目：你负责的XX功能完成了没有？
　>>程序员甲：早做完啦！
　>>小头目：那测试人员甲怎么说一直没看到XX功能？
　>>程序员甲：不会吧！我去瞧瞧。
　若干分钟后，程序员甲回来。
　>>程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。
　>>小头目：!@#$%^&*（此处省略15字）

★案例2（测试的混乱）

　另一天刚上班。
　>>测试人员甲：今天的XX.EXE怎么一运行就崩溃？
　>>测试人员乙：有吗？我这儿好好的呀！
　>>测试人员甲：真见鬼！我找开发问一下。
　经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。
　>>测试人员甲：为啥你做的XX.EXE一运行就崩溃？
　>>程序员丙：有这回事？！让我看看你的环境。
　程序员丙在测试人员甲的机器上研究了N刻钟后。
　>>程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！
　>>测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？
　然后两人开始对骂......

★案例3（集成的混乱）

临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包本身倒是很快，半天就搞定。但是......
　>>小头目：做好的安装包应该没什么问题吧？
　>>测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。
　>>小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！
　然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本......

有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃鸟。

我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来：

★针对“开发的混乱”

对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。

★针对“测试的混乱”

在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。

在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改了Bug但是不提交代码，那么在测试人员看来，相当于他的Bug一直没有改，因此他的Bug就一直不会被关闭。

所以案例2的情况也不会出现。

★针对“集成的混乱”

对于每日构建来说，每天都会产生安装包（或者安装光盘的ISO镜像）。也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的持续集成）。因此，集成的问题，在一开始就会暴露出来，而不用等到项目后期。

其实每日构建的好处除了上述三点（这三点我认为比较重要），还有其它很多，大伙儿可以自己再琢磨一下。后面一个帖子，我把每日构建需要的准备工作介绍一下。

[2]：准备工作

上一个帖子务虚了一下每日构建的几个主要好处。今天开始来说点实在的：也就是每日构建具体要如何开始搞，要做哪些准备工作（如果你所在的团队已经在用每日构建，你可以跳过这个帖子）。

每日构建不比其它纯技术的玩意儿，它是一个集体行为，它会改变包括编程人员、测试人员、产品人员等一堆人的工作模式。所以如果你想在公司里推广它，首先得掂量一下自己有几斤几两。一般来说，至少要做到项目主管或部门主管之类的级别，才有可能推得动。假设你尚未达到这种重量级，那看完本帖就算数，不可轻举妄动，切记、切记。

说到这里，有些涉世未深的同学可能有疑惑了，我简单解释一下：假如你所在的公司非常地优秀、从谏如流、没有等级观念、易于接受新事物。且不说这样的公司在中国很少，即使你三生有幸正好待在这样的公司，公司里多半早就用上了每日构建，因此也轮不到你去操心了；反之，如果你的公司言路不畅、等级森严、抵触新事物，你在分量不够的情况下贸然跳出来，立马被一棍子打死。

有点跑题了，下面言归正传，根据管理、人员、硬件、软件这4个方面，挨个介绍一下。

★管理问题

所谓管理问题，就是推行每日构建先要获得公司实权人物的撑腰，这点非常重要。根据我以往的经验，要改变这么多人的工作习惯，必定会遭到极大的阻力、遭到各种质疑。一不小心就会被人家的口水给淹死。

那如何让公司的老大支持它捏？你可以把以前由于缺乏每日构建所导致的种种负面问题（这时候上一个帖子的几个案例就可以派上用场啦）向公司的老大哭诉（最好声泪俱下），要尽量让公司老大明白之前的种种问题已经对公司造成了重大的、不可估量的、无法弥补的损失......

如果你的运气好，老大一激动，就把这事给批了。然后你就可以拿着鸡毛当令箭，去干后面的事情了。

如果你的运气差：老大死活不表态支持你，那你只好暂时先放弃这一打算，后面几步也就不用搞了。

★人员问题

假设你搞定了管理问题，接下来就是着手解决人员问题。主要包括两方面：人员培训和指派一个构建责任人。

人员培训主要就是告诉相关的人员，将来每日构建的流程如何，各色人等该如何分工，各自承担什么责任，出了差错如何解决等等（具体的技术内容下一个帖子细说）。培训时要尽量让大伙儿理解这玩意儿的切身好处（比如可以减少扯皮）。

构建责任人（一般是兼任，不一定需要全职）主要承担和每日构建相关软硬件的维护工作，大体类似IT运维支持人员。另外，如果你公司对源代码非常敏感的话，这个“构建负责人”就得挑一个靠得住的人来担任。

★硬件问题

为了让整个流程能够走通，你得额外去申请一个发布服务器和若干个编译服务器（我假定你公司已经有了单独的源代码服务器和Bug管理服务器）。

发布服务器大体类似于一个共享文件服务器，将来每日自动生成的东东（一般是安装包或光盘镜像）就自动存放到上面。发布服务器对硬盘的要求比较高（我负责的这个产品，每天生成3个ISO共两百多兆），其它配置倒无所谓。

编译服务器主要是为了进行自动编译。假如你开发的是跨平台软件，可能会需要多个编译服务器（每种平台配一个）；假如你开发的产品比较复杂，用一台机器编译太慢，可以考虑用多台机器并行做（听说Windows的每日构建就是多台服务器并行编译的）。编译服务器对CPU和内存的要求会比较高，其它配置倒无所谓。

★软件问题

到了这一步，基本上万事俱备了。然后就可以找个程序员来搞定和每日构建相关的各种脚本。主要有下面几种脚本：

1、从源代码服务器取出最新的源代码到编译服务器

2、在编译服务器上，把源代码编译为二进制文件，再把二进制文件制作成安装包

3、把安装包传到发布服务器

4、对安装包进行简单的冒烟测试（此脚本属于可选）

这些脚本相对都比较简单，基本上一个中等程度的程序员就能搞定。

上述就是几个方面的准备工作，下一个帖子我们来聊一下具体的流程。

[3]：流程

在上一个帖子已经介绍了几方面的准备工作，今天来说一下具体流程。对于流程的每一个环节，我会强调一下容易出问题的地方。

★提交代码到源代码管理服务器

以下为了打字方便，简称为RCS（Revision Control System）。

和老式的软件手工作坊不同，编程人员实现了某个功能点之后，不需要自己编译成二进制并提交给测试。取而代之的是，把代码提交到RCS。凡是使用过RCS的人，都应该知道如何提交代码，我这里就不细说了。

这个步骤的注意点有两个：一个是保证提交的代码是能编译通过的；另一个是提交频度的问题。这两点在“善用工具”中有提及，我这里再另外补充一点：有很多程序员在工程中添加了文件之后，忘记在RCS里面也进行添加操作。虽然他/她本地的源代码都可以编译通过，但是在编译服务器上却编译失败。

★从源代码服务器取出代码到编译服务器

这个步骤是脚本自动进行的，不需要人为干预。为了让脚本能够自己跑起来，你可能需要在操作系统里面设置一个“计划任务”来启动该脚本。

该脚本主要进行代码的checkout/update（不同的RCS软件叫法不同）操作。由于各种RCS软件都会提供命令行方式。所以该脚本只需要调用命令行就可以搞定。

这个步骤比较简单，一般不会出什么问题。在该脚本执行完之后，就开始自动执行后面的编译脚本。

★在编译服务器生成最终安装包

这个步骤的脚本比较复杂，得把所有需要编译的模块都编译过，然后再组装成安装包。

几乎所有编译型的编程语言，在其开发工具包中都自带有命令行的编译程序（比如JDK中的javac、VisualC++中的cl、Flex中的mxmlc等等）。有了这些编译命令，再配合一些make工具（比如Java中的Ant、VisualC++的nmake、Posix上常用的automake等等），就可以把一个工程编译成若干二进制文件。

在所有的项目都编译通过后，下一步就可以制作安装包了。大部分安装包软件（比如InstallShield、NSIS、RPM等）也都提供命令行方式。制作完安装包之后，这个步骤也就大功告成了。

这个步骤比较容易出问题的一个地方在于编译某个工程可能失败。一旦发现失败，就只能终止整个编译过程。这时候最好自动发出一个十万火急的邮件，告知每日构建的负责人及相关项目/产品的负责人。然后那个导致编译失败的家伙就有的好看了：轻则被臭骂一顿，重则被通报批评。

为什么编译失败怎么严重捏？因为每日构建号称是软件开发过程的心跳，自动编译一失败，就相当于心跳停了（下一个工作日，测试人员的工作都要受影响，项目进度也因此受影响），那当然很严重啦。所以，一般来说，规模越大的团队，对导致编译失败的处罚越重。

另一个容易出问题的地方在于增量编译。所谓增量编译就是在Make某个工程时，只编译修改过的源代码文件（主要是对比源代码文件的修改时间和对应二进制文件的修改时间来判断）。有些工具在判断增量编译时不够智能，导致本该编译的源代码文件没有编译（很容易引发诡异问题）。所以为了保险起见，我一般都使用全编译（也就是编译某个工程之前，把对应的二进制文件都删除）。

★提交安装包到发布服务器

假设安装包被成功编译出来，下一个步骤就是把安装包自动传输到发布服务器上。这个负责传输的脚本也是放在编译服务器上，在编译脚本执行完之后再被调用。

这个步骤一般也不会出什么差错，除非你公司的网络不稳定，导致传输过程文件损坏（那你只能自认倒霉了）。

★从发布服务器获取安装包进行冒烟测试（可选）

如果你从来没听说过冒烟测试，请看这里。先说明一下，冒烟测试并不是必做的步骤，不过我建议还是做一下比较好。冒烟测试是对软件最主要的功能进行一些简单基本的验证，保证自动编译出来的安装包是基本可用的。如果冒烟测试不通过（和编译失败类似，也算是严重事故），则表明软件本身有严重Bug，测试人员也就不用再费劲测试这个版本了（免得瞎忙乎）。

冒烟测试一般由某个专门的冒烟测试脚本负责。这个脚本一般放在测试服务器上，也是通过诸如计划任务来定时启动，然后从发布服务器上取下安装包，并进行相关的验证。

★测试人员从发布服务器上获取安装包并测试

如果上述几个环节都还顺利，那么，下一个工作日上班的时候，测试人员就可以从发布服务器获取到安装包，并开始进行一天的测试工作了。

这里有一个小建议：“测试人员下载安装包并进行安装”最好也是通过脚本自动来做。这样的话，当测试人员上班的时候，当天凌晨做好的安装包就已经自动安装在测试机器上了，测试人员一打开电脑，就可以开始测试软件了。

上述就是每日构建的几个主要步骤，大伙儿看完之后如果有什么问题，欢迎到Blog的评论里面提问，我会尽量予以解答。

转载必须包含本声明、保持本文完整。并以超链接形式注明作者编程随想和本文原始地址：
http://program-think.blogspot.com/2009/02/daily-build-0-overview.html