【IT168 技术文章】
在本文的前面两部分我们介绍了 IBM Rational 进行构建管理过程改进的原理和方法。本文的第三部分我们将介绍 IBM Rational BuildForge 的实施案例研究。
IBM Rational BuildForge 集成构建解决方案
经过业界许多用户的使用证明 IBM Rational BuildForge 可以帮助软件开发组织加速软件开发流程，增强产品质量，更好地支持异地分布的开发团队并满足审计和遵规需求，下面就从这三个层面来描述一下围绕 BuildForge 的集成构建解决方案。
加速软件开发流程
开发流程中的瓶颈
Rational BuildForge 提供了多种特性来解决软件开发过程中的常见瓶颈，从而加速用户的软件开发流程，这些瓶颈包括：
软件开发过程中从一个团队到另一个团队低效的流转
缓慢串行的处理速度
由于系统问题造成的停工
硬件资源的利用不充分
批处理过程不透明
因此本节主要描述 BuildForge 的功能及特性是如何解决上面的问题或瓶颈的。
加快流程流转，减少徒劳工作
Rational BuildForge 的自文档化（在项目创建及执行过程中自动形成相关文档）特性保证了更佳的团队协作，特别是分布在不同工作地点的团队。位于开发周期上游的团队不必担心没有将正确的信息传递给下游团队，这样他们可以将精力集中在如何正确处理他们自己的工作以及如何对系统中的信息进行封装方面，他们知道系统会对这些信息进行存储和传递。下面一些 BuildForge 的特性提供了这方面的支持：
物料清单（Bill of Materials）：系统将流程运行过程中相关内容的描述（包括使用检查点 checkpoint 列出发生变化的文件）组织起来并存放到一个包中。
图 1: 物料清单的一个例子
上图示出了物料清单的一个例子，从 Job Steps 中可以看出一个构建流程包含的全部步骤，这些步骤运行在哪台服务器上，用时分别多少等；还可以在 Step Manifests 看到每个步骤具体的环境变量及系统参数设置；在 Checkpoints 可以看到本次构建增加了一个新的文件 hello.exe。
日志（Logs）：系统记录了活动以及命令的输出，并根据用户及项目的安全性设置跨组织地进行系统运行日志共享。下图示出了一个 BuildForge 每个步骤运行的日志，根据需要还可以对日志内容进行过滤。
图 2: BuildForge 每个步骤运行的日志
注释（Notes）：BuildForge 允许用户在项目任务、项目运行结果添加注释，增强项目任务的可维护性，项目运行结果的可读性。
图 3: BuildForge 允许用户在项目任务、项目运行结果添加注释
这些特性结合在一起清晰诠释了在开发期间到底发生了什么。系统可以跟踪谁在哪台机器做了什么事情，结果是什么，消耗时间是多少等。这种跟踪能力不仅加强了各类人员对于流程及其运行的理解，还有效帮助企业遵守审计规则。
加快执行速度的同时延长系统正常工作时间
使用 Rational BuildForge，用户可以通过并行处理以及服务器池（server pooling）技术加快构建速度并延长系统正常工作时间。用户可以使用这些特性来：
将多台机器组成一个服务器池，然后在该服务器池上运行多个项目。只要一台服务器被充分占用，系统可以自动将处理流程重定向到同池的其他服务器上。
图 4: 将多台机器组成一个服务器池
上图示出了在采用服务器池时 BuildForge 的具体做法，首先 BuildForge 使用服务器收集器（Collector）来定义收集服务器哪方面的信息，例如 CPU 负载、空闲的内存、操作系统以及操作系统版本、CPU 数量等，这些信息可能会用作服务器分池的条件。下图示出了在物料清单（BOM）报告中在项目运行过程中实际采集到的信息。
图 5: 在物料清单（BOM）报告中在项目运行过程中实际采集到的信息
然后 BuildForge 通过服务器选择器（Selector）提供了服务器池的组织方式，例如把所有 OS_SYSNAME 为 Windows XP 并且空闲内存大于 512 M 的机器组织成一个池，接着将指定某些 Windows 项目运行在这个服务器池上。这样就充分利用了服务器资源，而且大大增强了构建系统的健壮性。
用一个流程即可在多台机器上启动多个并发执行的任务从而更快得到结果。如下图所示，同一项目中的两个步骤 5 和 6 可以并行执行，用户甚至可以指定步骤 5 在某台机器上运行，步骤 6 在另一台机器运行，也可以交由服务器池自动调度。
图 6: 可在多台机器上启动多个并发执行的任务
在不同机器上启动对同一应用程序不同操作系统版本的处理。例如某个应用程序的发布包括 Windows、Linux 以及 AIX 三个版本，我们可以同时在三台不同操作系统的机器上在它们各自的环境中进行同一应用的构建和发布。
如果 Rational BuildForge 尝试在某台机器上运行而该服务器宕机或不可用时，处理流程会递交给同服务器池的另一台缺省指定的机器，使得流程不会被中断。
同一任务在服务器池所包含的每台机器上运行一次。例如，如果用户想把一个代码更新部署到所有的 Linux 服务器上，这个更新可以立即以并行方式进行部署。
使用较少的硬件达到更快的速度
在进行 IBM Rational BuildForge 实施时，可以实现将部门的硬件资源以受控方式进行共享。没有这种集中管理方式，一个部门往往按项目组分配机器，例如某台 AIX 服务器就是给某项目组用的，其他项目组无法使用，结果造成硬件资源随着时间推移利用率不高。但如果使用 Rational BuildForge 就可以使下面的使用场景成为可能：
一个部门需要偶尔在 Linux 服务器上运行一些流程，通过 BuildForge 无需直接进行物理访问或对系统进行修改就可以提供受控的访问权限。例如该部门只能在该 Linux 服务器上运行某些特定的任务，而且可以在这些任务执行结束后自动将产生的结果清除掉。如果这些任务的运行过于频繁还可以禁止超过限制的运行请求。
一个部门的服务器可以设置为另一个部门的备份服务器，如果一个部门的关键服务器宕机，系统可以自动使用备份服务器直到首选服务器重新可用。
可以将一组机器组织成服务器池，不管涉及的部门或项目是什么都可以在服务器池上运行任何需要它们的流程。
可以仅将本部门一台机器的一部分运行能力赋予其他部门。
这些场景总的说来可以在提高处理速度的同时减低企业成本。
流程透明度和用于持续改进的分析
由于 Rational BuildForge 可以跟踪用户从编码到生产期间所执行的所有活动，因此在 BuildForge 中包含了相当丰富的信息，这些信息可以帮助团队提高生产效率。Rational BuildForge 可以生成一组预先定制好的报告，供用户用来分析自己的流程并持续进行改进。同使用大量的批处理文件或脚本却只能提供对流程有限的可见性相比，使用 Rational BuildForge 可以帮助用户：
不用搜索大量的日志记录就可以快速定位问题。如下图所示 BuildForge 提供了丰富的日志自动过滤搜索机制，用户可以抽象并定义错误或警告信息的模式，例如“ERROR”、“MYSYS_ERROR_CODE”等，同时可以定义一旦在日志或返回信息中搜索到满足这些模式的字符串后需要做什么样的处理，例如置为错误并终止运行，置为警告并继续运行，尽管返回信息为警告但可以清楚警告标志并继续运行等等。另外还可以定义需要通知哪些角色的人员。
图 7: BuildForge 提供了丰富的日志自动过滤搜索机制
检查每个流程甚至每个步骤的实际执行时间，从而发现运行趋势以及反常的运行。下图示出了通过 BuildForge Performance Report 对“GCC 编译演示”项目的多次运行过程进行的分析。包括时间趋势分析以及各个步骤的时长分布。
图 8: “GCC 编译演示”项目示例
跟踪问题发生的具体位置，属于跨部门的问题还是某个部门内的问题。
随着时间推移跟踪服务器的利用率。
发现代码变化最频繁的部分并定位错误发生的热点地区，改进项目计划。
使用 Rational BuildForge 公开的数据库模式产生用户自己的报告。从 BuildForge 7.0.1 开始加入了一个新的可选模块 BuildForge QuickReport，通过 QuickReport 可以基于 BuildForge 数据库简单地通过点击即可生成基于 Web 的报告、图表。下图分别示出了一个简单的对各项目构建成功率进行统计的报告的设计界面及最终结果。
图 9: 一个简单的对各项目构建成功率进行统计的报告的设计界面
图 10: 一个简单的对各项目构建成功率进行统计的最终结果
改进产品质量
当然，单纯加快软件开发速度是不够的，如果在组织中实施了 Rational BuildForge 用户还可以从拥有了统一的构建和发布自动化系统、标准化的开发流程以及更好的团队沟通而得到多种与质量改进有关的好处。
可重复的流程
通过 IBM Rational BuildForge 每次都是以一致的方式运行构建和发布流程。Rational BuildForge 可以根据用户需要多次重复运行一个项目，例如使用上一次构建的环境反复运行后续构建， BuildForge 还可以显示用户在运行时定制的值。BuildForge 解决方案非常适合重复已有的流程，反复进行测试或问题诊断的开发方式，如迭代化开发、敏捷开发等。甚至用户可以创建流程中的共享片段，使该片段成为一个共享项目，当其他项目需要该共享项目内容时直接调用共享项目即可。这样通过标准化流程提供了有价值的质量控制，减少了新项目的设置及启动时间。
图 11: 某个流程步骤可以通过 Inline 调用另一个共享的项目流程片段
如上图所示，某个流程步骤可以通过 Inline 调用另一个共享的项目流程片段；根据本步骤的结果（成功或失败）可以通过 Pass Chain 或 Fail Chain 分别启动另一个不同的项目。
知识保持
人员变动是所有组织不可回避的事实，但 Rational BuildForge 可以帮助企业克服这一难题。BuildForge 的统一知识库自动保存了企业基础设施中的流程信息，保护了信息投资并且大大降低了流程的学习曲线。团队成员可以在 Rational BuildForge 知识库中：
查看当前流程的定义
查看流程上一次运行的结果
随着时间推移查看流程定义的变化
查看注释中关于流程为什么变化的解释原因
BuildForge 系统创建了一个关于流程的知识库，并且自动进行流程的归档从而流程以标准化、一致和可重复的方式执行。
通过自动化减少人为错误
Rational BuildForge 为用户提供了实施全方位构建和发布自动化系统的工具。在设计好一个流程后，用户可以轻松将其自动化，然后将该自动化流程共享给组织的其他部门或人员。通过 BuildForge 可以实现下列内容的自动化：
调度日常流程运行
图 12: 调度日常流程运行
根据一次运行或一次运行的一部分的成功或失败决定下面的活动流向
基于源代码的变更决定活动流向
基于流程运行的成败自动交付报告
每次运行自动生成物料清单（BOM），由此得知为什么要运行以及谁做的变更。
通过这些特性，每个团队都会变得更加有效率。
开发团队可以进行更频繁的代码构建，从而立即得到关于他们代码效果的反馈。
QA 团队可以获得每次发布的内容以及是否可用的细节信息，这样就可以从经过自动化测试后的构建结果开始工作，评估发布中的问题。通过自动化测试可以帮助检查许多常见问题，从而将精力集中在其他更为复杂的测试上。
配置管理团队在日常操作方面可以花更少的时间，把更多时间用在开发流程优化上。
IT 团队可以利用 IBM Rational BuildForge 的报告帮助评估当前系统的需要以及未来的系统需求。
集中控制分布访问
团队的沟通问题经常是阻碍发布及时性的一个关键因素。如果没有一个高效的构建和发布自动化系统，配置管理团队对于请求新构建、新测试以及新项目的响应能力会对开发流程产生不利影响。另外，与构建流程脱节的开发人员经常会因为等待构建结果而丧失效率。类似地，如果一个项目不可被重复并且没有很好地进行文档化，会很难确定产品不同版本的信息，重现客户的问题，结果重现客户问题经常变成整个问题修复过程中最花时间的部分。
Rational BuildForge 通过统一控制及基于角色的安全访问机制可以支持地域分布的开发团队。用户可以将来自许多部门的流程集中在一个统一系统中，然后可以将对这些流程的访问以及这些流程生成的信息扩展到整个组织中任何期望扩展到的范围。统一的配置管理组可以先创建并测试流程，然后将流程的使用权限授予其他相应组的成员，即使这些人员不都属于同一部门。不属于正式配置管理组的个人可以创建他们自己的流程并将其在公司范围内共享。同时管理人员拥有管理控制权，决定谁可以运行某个自动化流程、阅读某个报告或定义一个新流程。
通过 Rational BuildForge 开发人员可以启动构建项目，及时得到反馈并对新特性或缺陷修改进行测试，但开发人员只能启动那些有权限启动的项目。这种自助服务使得开发人员获得更高的生产效率，减少配置管理团队在响应这类请求方面花的时间。实际上如前所述，这种思路并不局限在构建及发布方面，用户可以将其扩展到想自动化的任何流程。
通过更频繁的测试周期提供敏捷性
尽管自动化测试永远不能替代 QA 团队的所有工作，但 Rational BuildForge 可以将有效的自动化测试嵌入到整个构建和发布流程中，并将测试结果在整个组织范围内共享。进而 Rational BuildForge 的自文档特性可以帮助使每个测试周期更加有效，因为每次构建包含了此次构建的过程以及最终的可执行文件所包含的内容等信息。任何迭代化开发流程，例如敏捷开发及其他方法论都要求不断进行的“编码－构建－测试”活动来给开发团队和测试团队提供频繁的反馈。Rational BuildForge 提供了强大的自动化、调度以及源代码集成能力，帮助团队实现持续集成。通过 IBM Rational BuildForge 测试人员可以在许多有关产品的细节信息都已明确的基础上开始测试。
通过自动化测试检测到的问题可以在 QA 人员得到发布版本之前就可以反馈给开发团队，这样手工测试就可以在自动化测试通过后才开始。
以前碰到的问题可以很快加以重测，从而加速和改进回归测试流程，以便开发人员和测试人员较少担心引入新问题，而是将精力集中在新问题的修复上。
可以自动执行压力测试和负载测试。
通过 Rational BuildForge 的体系结构决定了它可以在所有目标机器上启动测试活动并收集测试结果。
Rational BuildForge 定制过滤器可以对测试结果进行预处理，用详细的警告或失败列表来加强报告能力。
物料清单（BOM）报告可以详细报告构建中包含的缺陷修复，因此可以对每个缺陷修复进行测试或者和自动化测试结果进行逐一匹配。
Rational BuildForge 可以与用户的源码控制系统和缺陷追踪数据库进行集成。
测试团队还可以将 IBM Rational BuildForge 用于：
执行冒烟测试。在每次构建后启动一个基本测试集，依据该测试集的成败来确定本次构建是否满足基本要求，是否可以继续后续测试。
自动将完成的构建安装在多台目标机器上。可以使用 Rational BuildForge 来配置用户的测试环境并通知测试人员这些机器已经准备好运行测试脚本了。
确定执行哪些测试。Rational BuildForge 系统中的项目都有不同的类别（class）标记，用户可以使用项目类别来决定执行哪些测试。下图是项目类别定义画面，在 Start on entry 可以决定一旦项目类别转为此类后就开始执行的项目，例如一旦一个项目从开发类转为测试类后就开始执行一个测试项目。
图 13: 项目类别定义
如果某个开发人员只想执行一个快速构建可以选择跳过测试步骤。
对于自动调度执行的构建，执行一个冒烟测试以确保主要部分没有问题。
对于一个生产构建，运行一个完整的测试集合，可能包括扩展性或负载测试。这可能需要非常大的系统资源。
以上这些特性使得在整个流程中建立更有效率的测试成为可能，因此也就将更高的品质融入到最终产品发布中。
为集成而进行的产品设计
从本质上看 IBM Rational BuildForge 实际上是一个将不同应用组合在一起以完成复杂开发任务的解决方案。借助 Rational BuildForge 用户可以轻易地将项目中的不同应用、操作系统命令、批处理文件或外壳脚本混合在一起。
通过其独特的命令行封装能力，Rational BuildForge 可以对在目标系统上执行的每条命令在执行前创建适合该命令的必要环境。并且用户可以为与系统其他部分集成的命令定义所需的环境。
除了将不同应用链接在一起这一基本功能以外，Rational BuildForge 也可以与其他解决方案进行集成。
可以通过轻量级目录访问协议（LDAP）标准与现有的用户数据进行集成，这样就避免了为新的信息系统创建额外的用户登录帐号。
IBM Rational BuildForge 为常用的源码控制工具、缺陷跟踪工具以及测试自动化系统提供了开箱即用的适配器，这样就可以通过开发活动来驱动信息的更新。例如，BuildForge 和 Rational 配置管理工具 ClearCase 的集成可以在编译前调用 ClearCase 相关功能来扫描版本库的变化，只有版本库有变化时才进行编译。下图示出了创建一个用于源码控制的适配器界面，利用随产品提供的源码控制工具适配器模板可以快速创建一个同源码控制工具（如 ClearCase）的接口（适配器），将该接口与具体的项目链接在一起后就可以在项目活动开始前调用 ClearCase 的功能（如扫描上次编译时间以来版本库内发生的变化）了。
图 14: 创建一个用于源码控制的适配器
通过 IBM Rational BuildForge 的 API 接口用户可以在自己的信息系统中从其他应用程序调用 BuildForge 的功能，用户可以进行细粒度的流程控制。
借助上面这些功能，Rational BuildForge 可以成为用户开发环境中的关键组成部分，同时成为企业信息系统中的重要成员之一。
开箱即用集成的价值：IBM Rational 软件开发工具
IBM Rational BuildForge 标准版和 IBM Rational BuildForge 企业版都可以配有开箱即用的与 IBM Rational 软件开发平台（SDP）的紧密集成，可以快速给客户带来价值。通过集成使用这些产品，公司可以管理、自动化和跟踪从需求到生产整个开发生命周期。这些集成包括：
IBM Rational BuildForge 标准版和 IBM Rational BuildForge 企业版都可以配有开箱即用的与 IBM Rational 软件开发平台（SDP）的紧密集成，可以快速给客户带来价值。通过集成使用这些产品，公司可以管理、自动化和跟踪从需求到生产整个开发生命周期。这些集成包括：
IBM Rational ClearQuest。Rational BuildForge 自动检测用于特定构建过程的 ClearQuest 活动，一旦一个构建成功完成，Rational BuildForge 可以自动将相关联的缺陷状态置为已解决状态，并在 ClearQuest 中将这些已解决的缺陷关联到构建记录上，这样就可以轻松在 ClearQuest 中查出某次构建所包含的缺陷修复。Rational BuildForge 还可以通过与 ClearQuest 的接口创建一个部署单元（deployment unit），用于传递给使用 IBM Tivoli Provisioning Manager 的部署工程师。
IBM Rational Application Developer。通过在开发人员使用的 Rational Application Developer 集成开发环境中提供对构建流程的受限访问，Rational BuildForge 打破了开发与配置管理之间的隔阂，从而允许开发人员在进行小组级构建之前即可在自己使用的集成开发环境中运行预先定义好的构建流程并立即得到结果，从而达成更高质量和更及时的发布。下图是嵌入到 Rational Application Developer 中 BuildForge 的透视图。
图 15: 嵌入到 Rational Application Developer 中 BuildForge 的透视图
同第三方应用的集成
前面第 6 章产品清单中已经提到 IBM Rational BuildForge Adaptor Toolkit 允许用户将第三方软件，如源码管理工具、缺陷跟踪管理工具以及测试自动化工具与 BuildForge 集成起来，从而建立软件配置管理系统和构建环境之间无缝的链接，提高效率并且可以跟踪源代码、缺陷以及测试的变化。用于第三方的适配器包括 CVS，Perforce SCM，Borland StarTeam，Microsoft Visual SourceSafe，Subversion 以及 Bugzilla。用户也可以为满足特定要求修改这些适配器，或者创建与自己开发的工具或者与其他第三方工具集成的适配器。
Rational BuildForge Adaptor Toolkit 提供了许多集成选项来自动化并优化开发流程，包括：
监控源代码变化。IBM Rational BuildForge 适配器提供了持续监控第三方源码库的能力，并且当源码库发生变化时自动执行构建。系统直接监控源码变化并收集度量信息，为每次构建提供详细的源码库状态跟踪。使用 Rational BuildForge 管理控制台，可以看到每次构建中从版本检入注释到实际的文件内容都是哪里发生了变化。
自动化缺陷跟踪和测试。Rational BuildForge 缺陷跟踪适配器可以帮助团队跟踪缺陷并在物料清单中报告指定缺陷的状态，例如“已校验”或“已关闭”。自动报告的缺陷可以帮助用户了解某次特定构建中都修复了哪些缺陷。
自动化测试用例运行并通过提供的测试适配器将测试结果记入物料清单。
适配器技术将源代码变化、缺陷以及测试与特定的构建关联起来，这样加强了对构建组成部分的详细了解。IBM Rational BuildForge 可以捕获关键的构建统计信息，包括所施加的变更、构建时间和日期等并为了便于访问将这些信息集中存储在一个位置。
支持审计和遵规管理
如本文前面所讨论的，遵规是大多数开发团队正在考虑的一个重要问题。即使开发团队不对公司的财务系统负责，但开发团队所交付的产品或服务对于公司的收入而言很可能是至关重要的，同时开发团队应该准备应对审计方面的要求。
作为萨班斯法案的结果，许多公司已经意识到标准化、可重复和文档化的开发流程也是一个关键的业务非常好的实践。关键是尽量减少收集相关审计数据的代价，从而减少开发团队的负担。IBM Rational BuildForge 可以捕获关键数据并提供从编码到生产全生命周期的可跟踪性，因此可以用作对应遵规和审计的证据。当使用 Rational BuildForge 来运行构建和发布流程时，系统自始至终自动跟踪用户的流程。将越多的流程放入 Rational BuildForge 系统，对于开发环境的了解也就越清晰。
系统保留了用户所有流程的版本信息，对于每个产品迭代，用户可以看到改变了什么，谁进行的修改以及为什么要进行这样的修改。并且系统为每个完成的流程运行提供了物料清单（BOM）。
对流程进行自动跟踪
即使是最简单的脚本只要在 Rational BuildForge 中运行，因为系统保存了每次项目运行的数据，它也可以作为一个有价值的遵规工具。例如一个普通的批处理文件或外壳脚本，它的作用是将文件从一个位置复制到 Web 服务器上，当在 Rational BuildForge 中运行它时它很快就远远不是一个普通脚本了。再看看下面这些例子：
系统可以通过电子邮件和基于 Web 的信息板进行项目运行成功或失败的报告。
尝试运行的命令和结果输出或者错误信息都保存在日志中。
系统可以调度脚本反复运行多次，保证标准流程每次都以同一方式得以执行。
系统可以发现可用的服务器资源来运行脚本，而不是依赖某一台特定机器。
系统会对脚本的执行人进行日志记录。
其他用户动作，如对脚本的修改也会被记录下来。另外， Rational BuildForge 注释（notes）可以帮助记录每个变化发生的原因。
当用户与现有工具进行集成时，Rational BuildForge 可以将多个孤立的信息源转换成随时可用的用于遵规的数据。
流程的版本化
当将一个流程加入 Rational BuildForge 后，就可以获取关于流程（项目）的许多信息了：项目中所包含的步骤、项目所需的环境变量、项目应该运行在哪台或哪些服务器上。不管在任何时候，只要用户对流程进行修改项目记录就可以得到更新；系统保留了当前版本的流程作为该流程的缺省指令集。每次在运行项目时系统都保存了运行信息的副本，即使项目定义已经发生了变化，用户仍然可以审查项目运行记录以便了解当时项目执行的确切步骤。进而系统可以重建先前的运行，按照当时的指令重新运行项目，而不用考虑已经发生的变化。这样任何加入 Rational BuildForge 的流程立即就可以变成可重复和可追踪的流程。如果流程的变化导致质量问题，用户可以返回到最近一次质量达标的状态。尽管 BuildForge 系统在自己的数据库中自动保存了流程记录，但用户可以将流程指令归档到自己的源码控制系统中。这样就可以将流程指令与用于创建产品的源码放在一起进行保存和管理。用户也可以将流程归档这一操作本身用 Rational BuildForge 加以自动化。
通过物料清单（BOM）建立自文档系统
IBM Rational BuildForge 包括一个可配置的物料清单，每次运行一个流程时 BuildForge 系统会自动生成一个物料清单用来提供详细的有关流程运行的信息，可以用物料清单来对流程的运行结果进行检查。同一产品（项目）由于使用人员角色不同流程往往执行方式也有不同，因此可以用物料清单作为记录流程的一种文档。
系统可以在物料清单中自动包含每次构建中一些感兴趣的信息。
通过使用 BuildForge 所提供的内置命令，用户可以在流程中加入一些任务来将一些额外的信息写入物料清单。例如，用户可以将在流程工作目录下的所有文件信息保存起来，然后检查这些文件在不同的检查点是如何变化的。下图是在 BuildForge 的示例流程的第 4 步中嵌入了 BuildForge 内部点命令 .scan baseline，其目的是记录编译前的所有文件状态，然后在第 5 步编译步骤之后，在第 6 步设立一个检查点（利用另一个 BuildForge 点命令 .scan checkpoint），检查文件的变化，例如新增了哪些文件、目录等。
图 16: BuildForge 的示例流程
物料清单就象一张从流程中的一个团队传到另一团队的工作说明书，没有物料清单构建就是一个神秘的黑箱，不知道里面装的是什么，也不知道结果是什么；而拥有了物料清单团队可以快速评估一次新的构建对他们意味着什么。
物料清单就象一张从流程中的一个团队传到另一团队的工作说明书，没有物料清单构建就是一个神秘的黑箱，不知道里面装的是什么，也不知道结果是什么；而拥有了物料清单团队可以快速评估一次新的构建对他们意味着什么。
总之，物料清单将流程以及流程端到端的运行结果都封装到一个直接可用的包中，适于审计或遵规校验。
IBM Rational BuildForge 案例研究
IBM Rational BuildForge 在短短 6 年左右时间内在全球获得了广泛应用，包括独立软件供应商、硬件厂商、电信、金融、软件游戏厂商等多类业界领先的用户。下面主要结合 IBM Rational 和某个世界领先的独立软件供应商为例分析他们是如何利用 BuildForge 解决各自面临的问题的。
IBM Rational 自身使用 BuildForge 的概况
自 2006 年 IBM 收购 BuildForge 并归入 Rational 软件部门后，Rational 迅速将 BuildForge 用于自身的研发管理流程中。在使用 BuildForge 之前 Rational ClearCase、ClearQuest 等产品线的 350 多名开发人员分布在全球几个实验室中，而开发的多个产品又涉及多种操作系统平台，发布工程组一直在寻找一个更为健壮的多平台支持、流程自动化并且可扩展的构建和发布环境来更好地利用人力资源和硬件资源，保质保进度地完成产品发布。在实施了 BuildForge 后 Rational 三个产品线已经建立起了一整套可扩展的构建和发布管理基础设施，明显改进了开发团队生产率、资源利用率和产品质量。而且在充分利用了现有开发工具和构建脚本的同时，团队增加了对他们对端到端的开发流程的了解程度，进而能不断提高其可靠性。
“IBM Rational 软件一致致力于提高自身软件开发实践从而改进我们自己的产品质量和开发效率，这就要求我们的端到端开发生命周期必须是可预计、可扩展的并且完全可以进行跟踪。BuildForge 的构建和发布管理平台是 IBM Rational ClearCase 开发团队生产业界领先的 Rational ClearCase 产品所使用系统的核心部分。BuildForge 的自动化和控制能力帮助我们以更准确的预判性来交付更高质量的产品。” —— Lee R. Nackman，副总裁，产品开发及客户支持，IBM Rational 软件
下面展开介绍一下 Rational 自身使用 BuildForge 后的经验和好处。
通过脚本开发自己搞构建自动化只能走这么远
在实施 BuildForge 之前发布工程团队通过脚本开发自动化了他们许多构建和发布流程，但是他们发现系统并不能扩展用来满足不断增加的新需求和复杂性。由于每个任务都是独立运行的，因此整个流程执行时不得不时时等待其他任务的完成来进行不同任务之间的协同。如果一些任务比预期时间晚完成，可能会导致整个项目失败。例如当夜间构建失败后通常会花一整天进行诊断和测试。同时他们发现内部开发的系统并不能充分利用超过 100 多台不同操作系统的机器。项目与具体的机器捆绑在一起，结果往往造成一些机器非常繁忙而其他的机器却闲着。进而为每个流程而专门书写的脚本使得团队成员很难共享工作，一个人不在别人很难接替他的工作。
痛定思痛——建立基于 BuildForge 的统一构建和发布管理系统
在对 BuildForge 进行评估后，项目组立即意识到可以用简单而更聪明的方式利用他们的资源。BuildForge 帮助发布工程团队通过一致的管理控制台集中管理原来分散的流程。BuildForge 无缝地与团队现有的脚本和工具（IBM Rational ClearCase、 IBM Rational ClearQuest、IBM Rational Robot 以及其他）集成在一起，因此可以快速基于现有做法进行自动化运行。现在他们可以建立流程之间的智能链接从而导演整个“编码－构建－测试－发布”周期。IBM Rational 软件开发经理 Dave Barr 说：“使用我们以前的系统，如果整个流程的某个环节出了问题，我们不得不停下来花很多时间（通常一天）来进行检查并重新开始。现在我们可以很快发现哪里出了问题并快速补救以免浪费更多时间。更重要地整个流程更加可靠和健壮，需要恢复的次数也减少了。”
事半功倍
通过 BuildForge， IBM Rational 软件团队变被动响应为积极主动，主管人员可以从他们的 BuildForge 控制板中即可有效监控项目的运行，并且可以快速指出错误发生的位置并在发生错误时及时解决错误。BuildForge“隐藏”了他们构建的所有复杂性，团队成员只要按一个按钮就可以执行相关的任务，这样团队成员不经过特定流程或项目的培训也可以更容易地与他人分担工作负载。现在他们差不多一个星期可以省出一天来放在其他任务关键性的工作上，同一批人还能给其所支持的其他团队以更多的服务。Barr 说：“BuildForge 使得我们可以轻松同时管理多个项目，我的团队从一个地方就可以得到他们需要的所有信息。另外，由于构建变得更加可靠，出现紧急问题的时候也少了”。
更加高效的构建和发布
BuildForge 帮助发布工程团队优化了硬件资源的使用，得到了更好的性能和更快的发布周期。现在他们众多的服务器已经组织成多个服务器池并有效地分布在不同的开发地点。通过使用线程选项，没有依赖关系的任务可以跨不同服务器、不同操作系统同时运行，这大大减少了一些 IBM Rational 软件产品的构建时间，从 1 天下降为小于 3 个小时。
通过更频繁的测试周期获得更好的质量
现在他们可以更快和更可靠地进行构建，团队可以用更多的周期来进行软件测试，QA 团队可以立即对 BuildForge 系统进行访问以获取最新构建包含了哪些内容，到底需要测试什么等。通过提高可靠性，IBM Rational 有了更多的测试时间来保证产品质量。
未来——支持开发人员得到更多好处
基于他们现有 BuildForge 的初步实施成功，发布工程团队计划将系统进而开放给开发团队。利用内置的基于角色的安全性，开发人员可以从他们自己的集成开发环境在授权范围内直接访问已经批准生效的生产流程。这样开发人员就能够在 IBM Rational ClearCase 版本库中检入变更内容之前或之后都可以对他们自己的工作进行校验，在影响夜间构建前提前发现和解决错误。开发人员由此可以对他们的代码更有信心，整个团队期望能得到进一步的生产率及质量的提高。
某独立软件供应商
业务挑战——不可预期的构建和发布，相互脱节的开发工具
作为一家全球领先的桌面出版软件供应商，拥有 50 个产品线、150 个产品开发组、2000 多名分布在全球的开发人员。但长期以来分离的构建和发布流程使得开发团队各自为政，形成了多个相互重复、自行开发的构建系统。150 个产品开发组的 150 个配置经理每人都使用他们自己的手工的、没有很好文档化的构建流程，结果构建过程时间长而且经常失败，发布也很难再现，开发成本相当惊人。另外，每个开发工具都有自己的信息，由于这些信息不能共享，因此无法得到关于发布内容的可见性。总是不断重头做同一件事但却缺乏端到端的构建和发布流程集成造成该软件供应商产品质量不高、不能按期发布以及发布成本高。因此他们感到他们需要一个可靠、集中管理的系统来减少成本，使得 50 个产品开发团队都统一到这个构建管理平台上来。
业务解决方案——可预期性和集成性
公司成立了一个专门的工程服务小组（ESG）来为构建和发布流程创建相关标准，他们想将所有的开发系统（源码控制、测试、缺陷修复、本地化、CD制造等）全部连接在一起，形成那个一个紧密集成的面向服务的架构。在对比了多种解决方案，包括他们自己开发的解决方案后，由于 BuildForge 的灵活性、可扩展性和快速见效的特点，该公司最终选择了BuildForg。
在采用了 BuildForge 解决方案后，通过一个跨不同团队、产品和平台的集中管理的系统，用户可以对构建和发布的非常好的实践进行管理和自动化。BuildForge 可以相当容易地插入到现有的开发环境中，将分离的工具连接到一起从而创建贯穿整个应用开发生命周期的、透明的流程。通过实现自动化的、一致的流程，发布周期以及产品质量均得到了改进。
另外，BuildForge 确实帮助用户加速了他们的发布过程。用户想更多采用敏捷方法来改进质量，但他们知道他们以前的系统是不能支持这种想法的。在采用 BuildForge 之前 1 个月只能完成 18 次构建，在采用了 BuildForge 之后可以进行 360 次构建，提高了 20 倍。这使得他们的配置管理团队更有效率，更少的投入可以得到更多的回报。
业务结果——开发流程完全连接在了一起
由于开发流程被完全集成在一起，因此开发流程运作得更加平滑。
配置管理团队不用添加额外的资源就可以满足每个项目的需要。
开发、配置管理、QA 以及管理团队都可以访问集中管理的系统，了解每个发布的状态。
开发周期从每月 18 次构建变为每月 360 次构建，而且构建人员减少了一半。
配置管理团队的生产率提高了 90%。
“没有 BuildForge 我们是不能以现在这种效率进行运作的，它每年为我们节省了数百万美金。” —— 高级计算机科学家
总结
本系列描述了 Rational BuildForge 进行构建和发布过程管理及自动化的方法，讨论了如何通过整合项目组、流程以及系统来改进软件开发效率，从而提高整个开发团队的效率，改进产品质量，更好地遵规。
本系列首先对编译和构建的差异给出了说明，然后对文中常用的名词或术语进行了描述，接下来在“当前构建及发布过程面临的挑战”对当前应用生命周期管理中，特别是构建及发布过程面临的挑战。为了更好地帮助读者理解 IBM Rational BuildForge 的实现原理及功能，特别在介绍具体产品功能前加入了有关构建流程的一些基础知识及非常好的实践经验。在“IBM Rational BuildForge 简介”部分对 BuildForge 的基本功能进行了描述，之后是基于 BuildForge 的集成构建平台解决方案介绍，以及给软件开发、质量改进以及遵规带来的好处，最后是一些用户的案例研究。
参考资料
本系列的 第一部分 介绍了 IBM Rational BuildForge 进行构建管理过程改进的原理和方法。
本系列的 第二部分 介绍 IBM Rational BuildForge 的产品特性。
访问 IBM Rational 软件交付平台 V7专题，了解 Rational V7 产品的方方面面。
访问 IBM developerWorks 中国网站 Rational 专区 了解更多关于 Rational 产品的信息。
