集成与构建指南（6）

1          集成构建基本流程

1.1         概述

在构建开始前，构架师应当确定项目初步的基本源码包组织结构，和包之间的依赖关系等，并定义项目统一的构建目录结构。构架师还应指导集成员制定集成构建计划，以确定集成的内容、构建周期和日程表。在项目构建阶段初期，构架师应密切参与或直接承担集成的工作，从而为项目源码结构确定演进的方向；其后还应给予足够的关注，并经常性地修订和维护源码目录结构，以便在整体上把握项目源码和最终交付工件。

随后的每个构建周期都包含：实施—〉单元测试—〉提交—〉集成—〉冒烟测试的基本过程。

1.2         集成过程说明

实施员在私有的开发工作站上，按照项目统一的源码结构组织其单元开发目录，完成源码和单元测试代码的编制，并在集成员的指导或帮助下编制私有构件的自动化构建脚本（为了编码和调试方便，实施员通常选择GUI集成环境进行编译，这种IDE内部格式的编译项目既不标准，也不适于集成构建使用，因此维护额外的构建脚本是必要的），在构建成功后向集成流（Stream）提交成果（delivery）；在结束提交之前，实施员应尽可能在本机尝试集成构建，以验证构建脚本、单元测试代码与源码可用，之后完成提交。

集成员在集成服务器获取各实施员提交的构件源码，先根据需要调整各源码结构以解决构件间的编译冲突，再编制或修改集成构建脚本，加入集成构造目标（target），并增添对新增单元构建脚本的调用，以实施统一的批量编译、链接，最终生成集成构造；为了实现并验证集成目标，可能需要修改源码，增加或修改用于集成测试的代码，和进行集成调试等，这可由集成员或实施员来完成此项工作；集成员开始执行干净的集成构建（为了实现持续集成，可以配置操作系统任务，定时在夜间自动执行构建任务），生成可执行交付工件（也包括静态或动态链接库等）；为了验证构建步骤成功，随后需要执行冒烟测试，其原则是尽可能利用已有的测试代码，通过在构建脚本中调用它们，实现自动化的冒烟测试（对于GUI目标系统而言，实现自动化较为困难，往往依靠手工完成冒烟测试）。

集成员或配置管理员为构建成功的一个构造建立基线；测试员将在测试工作站上对此基线进行集成测试；实施员则可能在各自的开发工作站上，重设开发基线于此基线上（rebase），以在新的基础上继续后续开发工作。

1.3         持续集成过程说明

集成员通过配置CruiseControl工具，可以将部分较为简单、不需要人工干预和希望经常重复执行的集成工作交给工具来自动完成。集成员可以配置多个持续集成项目，包括若干个多人同时在开发的子构件、最终发布的集成包等。

CruiseControl在活动时段，循环执行各构建周期，包含：引导初始化—〉检测源码变化—〉集成构建—〉单元测试—〉发布构建和测试结果等步骤。

每当实施员在私有开发工作站上，将源码检入（Checkin）、加入源码控制（Add to Source Control）、或者向集成流（Stream）提交成果（delivery）时，CruiseControl在随后的构建周期循环中，将通过检测源码变化步骤检测到这一变化，CruiseControl此时会等待预定的间隔，看看是否有新的源码变化出现，避免实施员批量检入或加入源码控制时遗漏后续变更；CruiseControl开始调用Ant封装（wrapper）配置文件执行构建，它首先更新目标源码目录下的所有内容（调用ClearCase ccupdate指令），以同步变化的源码，再进行编译、链接，完成预定的冒烟测试，并将结果记录到相应的日志中；CruiseControl在构建完成后，通过e-mail将成功或失败的结果通知提交源码变更的实施员、以及指定的其他人员，并生成构建报告网页，相关人员通过e-mail接受通知的同时，也可以登陆CruiseControl的发布网页来浏览构建报告详细信息。