软件工程进阶之每日构建[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-3-proces.html