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

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

　　以下为了打字方便，把源代码管理系统简称为 RCS（Revision Control System）。
　　和老式的软件手工作坊不同，编程人员实现了某个功能点之后，不需要自己编译成二进制并提交给测试。取而代之的是，把代码提交到 RCS。凡是使用过RCS 的人，都应该知道如何提交代码，俺这里就不细说了。
　　这个步骤的注意点有两个：一个是保证提交的代码是能编译通过的；另一个是提交频度的问题。
　　这两点在“善用工具”中有提及，这里再另外补充一点：有很多程序员在项目/工程中添加了文件之后，忘记在 RCS 里面也进行“添加操作”。虽然他/她本地的源代码都可以编译通过，但是在编译服务器上却编译失败。

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

　　这个步骤是脚本【自动】进行的，不需要人为干预。
　　为了让脚本能够自己跑起来，你通常需要在操作系统里面设置一个“计划任务”来启动该脚本。
　　该脚本主要进行代码的 checkout/update（不同的 RCS 软件叫法不同）操作。由于各种 RCS 软件都会提供命令行方式。所以该脚本只需要调用命令行就可以搞定。
　　这个步骤比较简单，一般不会出什么问题。在该脚本执行完之后，就开始【自动执行】后续的编译脚本。

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

　　这个步骤的脚本比较复杂，得把所有需要编译的模块都编译过，然后再组装成安装包。
　　几乎所有编译型的编程语言，在其开发工具包中都自带有命令行的编译程序（比如 JDK 中的 javac、Visual C++ 中的 cl、Flex 中的 mxmlc ...）。有了这些编译命令，再配合一些 make 工具（比如 Java 中的 Ant、VC 的 nmake、Posix上常用的 automake ...），就可以把一个工程编译成若干二进制文件。
　　在所有的项目都编译通过后，下一步就可以制作安装包了。大部分安装包软件（比如InstallShield、NSIS、RPM等）也都提供命令行方式。制作完安装包之后，这个步骤也就大功告成了。
　　这个步骤比较容易出问题的一个地方在于编译某个工程可能失败。一旦发现失败，就只能终止整个编译过程。这时候最好能【自动】发出一个十万火急的邮件，告知每日构建的负责人及相关项目/产品的负责人。然后那个导致编译失败的家伙就有的好看了：轻则被臭骂一顿，重则被通报批评。
　　为什么编译失败怎么严重捏？因为每日构建号称是软件开发过程的心跳，自动编译一失败，就相当于心跳停了（下一个工作日，测试人员的工作都要受影响，项目进度也因此受影响），那当然很严重的啦。所以，一般来说，规模越大的团队，对导致编译失败的处罚越重。
　　另一个容易出问题的地方在于增量编译。所谓增量编译就是在 Make 某个工程时，只编译修改过的源代码文件（主要是对比源代码文件的修改时间和对应二进制文件的修改时间来判断）。有些工具在判断增量编译时不够智能，导致本该编译的源代码文件没有编译（很容易引发诡异问题）。所以为了保险起见，俺一般都使用全编译（也就是编译某个工程之前，把对应的二进制文件都删除）。

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

　　假设安装包被成功编译出来，下一个步骤就是把安装包【自动】传输到发布服务器上。这个负责传输的脚本也是放在编译服务器上，在编译脚本执行完之后再被调用。
　　这个步骤一般也不会出什么差错，除非你公司的网络不稳定，导致传输过程文件损坏（那你只能自认倒霉了）。

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

　　如果你从来没听说过“冒烟测试”，请看“这里”的介绍。
　　先说明一下，冒烟测试并【不是必做】的步骤，不过俺建议还是做一下比较好。冒烟测试是对软件最主要的功能进行一些简单基本的验证，保证自动编译出来的安装包是【基本可用】滴。如果冒烟测试不通过（和编译失败类似，也算是严重事故），则表明软件本身有严重 Bug，测试人员也就不用再费劲测试这个版本了（免得瞎忙乎）。
　　“冒烟测试”一般由某个专门的冒烟测试脚本负责。这个脚本一般放在测试服务器上，也是通过诸如计划任务来定时启动，然后从发布服务器上取下安装包，并进行相关的验证。

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

　　如果上述几个环节都还顺利，那么，下一个工作日上班的时候，测试人员就可以从发布服务器获取到安装包，并开始进行一天的测试工作了。
　　这里有一个小建议：“测试人员下载安装包并进行安装”最好也是通过脚本【自动】来做。这样的话，当测试人员上班的时候，当天凌晨做好的安装包就已经【自动】安装在测试机器上了，测试人员一打开电脑，就可以开始测试软件了。这不是很爽吗？


　　上述就是每日构建的几个主要步骤，下一个帖子聊一下与每日构建相关的工具。