图 5: 每个任务又包含了一组可以发到远程构建服务器上运行的命令以及配合使用的环境变量

    以第1个任务“Create View for Source”为例，如上图所示其中包含了一个创建 ClearCase 静态视图的命令，此外还可以在任务属性中定义其他内容，例如可以指定该任务使用不同于项目的环境变量、运行在不同的服务器上等等。

    一旦一个项目定义完毕就可以使用 BuildForge 调度程序调度该项目到时自动运行，或者可以作为授权用户登录 BuildForge 手动启动项目。一旦项目开始运行，系统将根据所选择的构建服务器（直接指定或动态选择）在该服务器上运行特定的命令，命令执行结果将被回写到 BuildForge 数据库中。如前所述用户可以利用 BuildForge 多项目串接的特性进行构建工作流设计，从而根据前一项目的执行结果自动触发后续项目的运行。

    项目运行结束后根据项目或任务定义可以自动通知相关人员告知项目的运行结果（成功或失败），例如一个集成构建项目，如果其成功则通知测试/QA 人员在指定位置接收构建结果开始测试；如果其失败则通知相关开发/集成人员在指定位置接收构建结果对失败原因进行分析。

    下图示出了已完成的构建结果，可以清楚地看出某个项目的历史构建结果记录，哪些构建成功、哪些失败、哪些成功但带有警告信息、构建时间、编号、构建用时等关键信息，点击具体某次构建还可以看到更为详细的说明。

    图 6: 已完成的构建结果

    一个项目内的任务可以是传统的构建任务，例如对应用程序的编译，但 BuildForge 并不局限于此，实际上在 BuildForge 中可以定义和运行多种多样的任务，从源代码的检入/检出，到源代码的编译、链接、测试以及部署，下面是一个典型的构建项目可能包括的步骤：

    将源代码文件从版本库取到构建服务器上
    对源代码进行编译并报告编译进度
    在成功的编译结果上执行自动化单元测试
    创建一个安装程序
    将该安装程序上传到一个站点，并通知团队成员可以使用该安装程序进行应用安装
    通过运行安装程序生成可执行文件
    运行自动化测试，对该可执行文件进行测试
    报告测试结果
    启动另一个附属项目来更新标准链接库
    将可执行文件和其他文件传递给QA部门以进行后续测试
    将完成的发布工件部署到生产环境，例如 Web 服务器或者发送到 CD 工厂
    使用 Rational BuildForge 也可以完成其他类型的项目或任务，如：

    将一个源文档文件（MS Word）转换为一个 PDF 格式的文件，将其复制到 Web 站点的下载链接位置，更新 Web 页面的相应文件列表，并更新网站搜索索引。
    允许开发人员运行单个组件的构建，并每天运行一个主构建来编译整个产品，该主构建会引用其他的组件构建结果。
    在 5 或 20 台机器上以串行或并行方式运行同一个构建流程。
    允许项目组运行他们自己的构建，但只有授权人员才能更新 Web 服务器。
    BuildForge 系统是如何运作的
    IBM Rational BuildForge 的设计思路非常简单，即不管当前用户使用的是什么工具（包括配置管理、编译工具等）它都可以为开发团队提供可靠的构建发布管理系统，这一想法最终落实到了一个灵活而健壮的自动化基础设施中，从而可以为遍布全球的分布式开发团队使用。不管目标服务器的位置在哪儿，或操作系统是什么， IBM Rational BuildForge 可以使用户通过基于 Web 的浏览器界面即可在多台服务器上执行具体的命令。下图是 BuildForge 的功能架构图，其中包括：

    BuildForge 管理控制台（management console），这是一个基于 Web 的PHP应用，运行在一台 Apache HTTP 服务器上。通过管理控制台用户可以将命令组织到步骤和项目中来进行构建项目的编制，同时管理这些命令使用的服务器资源和环境变量，还可以进行构建运行监控、构建报告生成、构建任务调度等管理任务。
    BuildForge 引擎（engine），使用通过管理控制台输入的信息并将其存放到数据库中，同时与安装在目标服务器上的代理（agent）进行通信来执行具体的项目任务和发送通过。BuildForge引擎根据管理控制台输入的指令来工作。
    核心的关系型数据库，其中存放了完整的用于跟踪每次项目执行的项目信息。用户信息和系统动作也被保存在数据库中以便从中抽取数据进行分析，满足审计和报告的要求。该数据库可以使用多种数据库（如 Oracle、DB2、SQL Server 以及 MySQL 等）。
    在分别运行不同操作系统的计算机上安装的代理（Agent），代理程序用来响应来自系统的指令。代理程序从数据库中抽取环境信息在目标服务器上为项目动态构造相应的环境，从而保证项目中的每条命令都是在完全满足命令执行的环境下执行的。
    BuildForge IDE插件，作为开发人员可以使用 BuildForge IDE 插件直接在 IDE 环境下进行构建任务的提交，运行监控和报告。从而实现构建的开发人员自助服务。现在支持的 IDE 插件包括 Eclipse、.Net 以及 Rational Application Developer。
    BuildForge 的功能架构图

    一些 BuildForge 的使用场景

    借助上面的 BuildForge 组件，BuildForge 系统可以象一个框架一样将用户的开发资源紧密结合在一起。下面是一些典型的 BuildForge 使用场景，这些均可以使用 BuildForge 来进行自动化和跟踪：

    配置管理经理使用 BuildForge 管理控制台每天构建某旗舰产品的最新开发版本，而且该产品有用于多种操作系统的版本。BuildForge 系统了解该项目编译的每个具体步骤，根据规格要求在运行时 BuildForge 系统创建了对应不同操作系统的相应环境。在运行到某些公共步骤时，项目分出两个子流程，一个用于 Red Hat Linux 操作系统，另一个用于 Microsoft Windows 系统，每个子流程都从版本库中检出各自的代码在不同服务器上并行开始产品编译。
    通过整个构建流程，配置管理团队可以对整个项目的处理流程有一个清晰的、实时的了解。如果这些流程中的其中之一出现了问题，相应失败流程会通知负责本部分程序的开发人员。一旦项目成功完成，构建得到的可执行文件被上传到内部的 Web 服务器上进行测试，同时自动通知相应的 QA 团队。
    开发人员对该产品中属于自己工作的部分进行测试，如果开发人员通常使用的构建服务器已经宕机，系统会自动将处理流程重定向到其他可用的服务器上并记录本次运行实际使用的服务器。当流程执行结束后开发人员会收到 e-mail 通知，告知最新的构建结果存放在哪里。服务器宕机对开发人员和配置管理人员都不会造成影响，他们也不需要立即对此做出反应。
    Web 站点管理员创建了一个流程，每天数次从一台部署服务器收集所有更新过的 Web 页面并将他们复制到公共服务器上的相应位置。通过一个简单的自动化处理流程，该 Web 站点管理员能够更新文件、重启 Web 服务器并将更新文件的历史版本归档到另一台服务器上。现在当该站点管理员不在的时候，其他团队成员可以经过短时间培训即可了解该过程并帮助执行该流程。
    项目组使用多台机器进行产品压力测试。该测试不仅需要与配置管理团队配合进行，而且需要使用隶属于不同部门的多台机器在夜间进行。由于机器分属不同部门，该项目组被授予了严格的访问控制权限，因此这些部门可以不用担心破坏服务器的环境就可以安全地共享服务器资源。任何在测试期间生成的文件可以在测试结束后自动清除，从而恢复服务器的原有状态。
    IBM Rational BuildForge 的优势

    IBM Rational BuildForge 完全体现和支持第 1 部分提出的 9 大构建非常好的实践，其独特的设计方法展现了区别于其他产品和方法的明显优势，这些优势的结果表现在以下两个方面：

    扎实定位在任何软件项目的真正提交件——可执行文件的构建过程及跟踪上。
    忠实报告在开发期间到底发生了什么。
    构建关键的、可靠的开发工件——可执行文件

    通过第 1 部分的概述和第 3 章“当前构建及发布过程面临的挑战”可以看到，许多软件开发企业中有关构建和发布管理的科学化、自动化是比较薄弱的，绝大部分精力基本都放在在开发本身上，而忽略了从源代码到最终产品的流程优化，结果一个常见现象是配置管理人员或构建人员人手不足，而且从代码到最终产品的过程基本以手工为主，不仅容易出错，而且容易依赖某些个人的特定知识，结果这一过程中出现的问题往往会对开发做出的巨大努力大打折扣，有时用户甚至认为在产品最终交付前这方面不出问题才怪呢。但是产品开发团队的最终交付件就是可执行文件，它是面对最终用户的最终产品形态，这也是 BuildForge 关注的重点。下面通过几个例子进一步说明关注可执行文件构建管理的重要性和必要性：

    开发人员写了几个月的代码，结果发现一个可执行文件由于不正确的构建而在用户应用系统中工作不正常。
    您的版本控制系统告诉您一个缺陷已经修复了，但是实际上该缺陷修复分支上的代码根本没有并入最终的发布版本中。尽管配置及变更管理系统可以用于跟踪代码变化，但当用户想跟踪某个特定问题到底解决没有时，它不会告诉你在最终可执行文件中到底是否包含了该问题的修改。
    用户的缺陷跟踪数据库指出一个问题已经被修复了，但这实际上依赖于人的录入。而可执行文件实际上才是产品的最终和最真实的记录。为了做到精确的审计，必须以从可执行文件提取数据的方式进行开发管理。当使用 Rational BuildForge 来构建产品时系统可以报告出在可执行文件中嵌入的缺陷修复。因此 BuildForge 将开发流程紧密结合在一起，从而允许用户进行逆向跟踪，从问题追溯到产生问题的代码。结果构建和发布管理流程可以和应用交付流程中的其他阶段紧密结合达成一致性管理，从而将开发可能遇到的灾难最小化。
    忠实报告在开发期间到底发生了什么

    Rational BuildForge 的报告是从实际运行的流程中获取到的，不管该流程是软件编译流程、自动化测试流程、Web 站点更新流程还是什么其他的流程。这与其他基于文档的开发管理系统不同，基于文档的开发管理系统需要手工输入数据。如果使用 Rational BuildForge 来打造集成的开发环境，可以得到下面的好处：

    用户的源代码控制系统告诉用户什么代码被检入了；而 Rational BuildForge 则告诉用户在发布版本中实际包含的代码到底是什么。
    用户的缺陷跟踪系统告诉用户哪些缺陷修复会放在本次发布中；而 Rational BuildForge 则可以告诉用户在发布版本中实际嵌入了哪些缺陷修复，并且可以执行自动化测试对这些修复进行校验。
    当一个用户打电话报告在一个具体软件发布中出现的问题，您可以利用 Rational BuildForge 来确定在那次发布中都包含了哪些东西。
    当用户在自己公司的 Web 站点上碰到了一个问题，Rational BuildForge 可以精确告诉用户站点都发生了哪些变化，并且帮助回滚到早期版本。
    IBM Rational BuildForge 产品清单

    IBM Rational BuildForge 标准版
    提供了全面的构建和发布处理自动化功能，支持分布式服务器访问及流程跟踪。
    IBM Rational BuildForge 企业版
    在标准版的基础上进一步提供一些高级功能，如流程的并行执行，服务器配置自动发现和动态服务器分配。
    IBM Rational BuildForge Adaptor Toolkit
    提供了直接可用的与一些第三方软件（如 ClearCase、ClearQuest、CVS、Subversion 等）的集成以及灵活的 API 接口。为了达到更好的集成、信息共享以及源代码、缺陷、测试结果以及更多内容的跟踪，用户通过这一软件和API接口可以建立构建和发布环境与用户自己的第三方配置管理工具、专有工具的无缝链接。
    IBM Rational BuildForge QuickReport
    基于 Web 的报告定制工具，用户无需 SQL、脚本以及 API 方面的知识通过点击即可生成各类针对构建数据库的报告、图表等。
    小结
    本文概述了 IBM Rational BuildForge 的基本特性。在下一部分，将介绍基于 IBM Rational BuildForge 的集成构建解决方案，以及案例研究。

    参考资料
    在本系列的 第一部分 介绍了 IBM Rational BuildForge 进行构建管理过程改进的原理和方法。
    在本系列的 第三部分 将介绍如何利用 IBM Rational BuildForge 建立起的构建管理平台，改进构建流程的管理和控制效率。
    访问 IBM Rational 软件交付平台 V7专题，了解 Rational V7 产品的方方面面。
    访问 IBM developerWorks 中国网站 Rational 专区 了解更多关于 Rational 产品的信息。