当前构建及发布过程面临的挑战
IBM Rational BuildForge 的一大优势是将不同的过程、人员以及工具集成到一个一致而高效的软件交付系统中。它主要解决了三个关键的开发挑战：应用生命周期管理，工具标准化以及遵规。
应用生命周期管理面临的挑战
一个软件产品或交付项目从编码阶段开始一直到投产或上线会涉及一个复杂的有关人员、流程以及技术的网络，为了提高软件交付的效率就必须对它们进行整合。通常开发团队会碰到下面一些问题：
*不同关键阶段（开发、配置管理、QA、发布和客户支持）的团队由于组织不同相互分离，使用不同的工具集，甚至分布在不同的地域。
*每个团队有自己的流程，许多流程是手工流程，很少进行记录和文档化，结果导致非常关键的构建和发布知识驻留在少数关键人员的头脑中。
*缺陷跟踪以及源代码控制系统经常相互分离，互不相接，形成了不同的信息孤岛，从而难以集成使用这些信息并且可能消耗大量的时间和精力。结果开发组织不能全面了解到底提交给用户的东西是什么，直到产品在用户使用过程中出现了严重问题才被动地去进行问题诊断。
随着当前对软件质量和软件交付频率的不断提高，开发团队需要一个坚实的基础来提高软件开发过程中的可重复性、可靠性和可跟踪性。因此不少开发团队都在寻求建立这样一个基础设施，目前他们面临着两个选择：
*从单一厂商购买一个端到端的应用生命周期解决方案
*实现一个集成框架将现有工具和流程连接起来
不管开发组织采用上面的哪一条改进线路，IBM Rational BuildForge 都可以帮助团队改进开发效率。
标准化还是非标准化？
对于想采用一整套内部已经集成好的工具集来进行软件开发管理的用户，IBM Rational 软件开发平台（SDP）是一个非常好的选择。集成了 IBM Rational ClearCase、IBM Rational ClearQuest、IBM Rational RequisitePro、IBM Rational BuildForge 以及 IBM Tivoli Provisioning Manager 的工具集提供了全面的从需求到生产的自动化控制。通过从单一可信任的厂商购买一整套解决方案公司可以获得紧密的产品集成，同时客户支持服务也比较简化。
其他的开发团队也发现采用一整套标准化工具对于他们自身环境和情况不允许或不现实。由于贯穿开发生命周期的沟通和集成非常关键，但是强行要求不同团队采用一致性的做法从而保证同其他团队的沟通和集成往往并不容易，还可能引起内部纠纷，从而使得这种集成风险较大。即使所有的团队都同意进行标准化，一些事件的发生也可能会引入不一致性的东西，例如收购了使用不同工具集的另一家企业或者将某一部分外包给使用不同工具集的第三方厂商。最终，一些开发团队需要一个灵活的架构来支持不同的工具集来适应组织未来的开发需要。IBM Rational BuildForge 通过一个灵活的框架提供了对任何工具集成、自动化和报告的能力。
IBM Rational BuildForge 灵活的框架可以与组织内现有的工具一起工作，并且随着时间的推移，它也可以和新购买的工具一起工作。这样通过 BuildForge 可以建立一个集成的开发生态系统，从而克服不同工具集成工作的难题。BuildForge 提供的一致性接口可以跨不同的操作系统和硬件平台，用户从同一个接口启动一个Microsoft Windows程序或者Unix 命令，用户也可以启动一个处理过程同时在不同平台，如 Microsoft Windows、Linux 和 AIX 上进行相应任务处理。这给了开发团队极大的自由度来确定适合自身环境的解决方案。
对审计和遵规管理的支持
越来越多的组织现在正面临如何遵从政府或业界规定、标准的问题。为了能通过审计，开发团队必须要展现出他们具备可重复的过程，精细的控制，并且他们必须一致性地记录系统为什么发生变化，谁具体实施了这一变化。没有一个自动化的应用生命周期管理系统，团队可能会花大量的时间从不同应用收集数据，然后进行加工来满足审计人员的要求。
当与用户开发生态系统中的其他工具连接使用时，IBM Rational BuildForge 可以提供一个详细的有关开发过程的记录，从而不用很长的准备时间就可以提供用于审计的报告。因为 BuildForge 精确捕获到了各类详细信息，如发布了什么，什么地方被修改了，进行了什么测试等，并提供一个详细的物料清单（BOM，Bill of Materials）用作遵规和审计检查的证据。
当与 IBM Rational 其他软件一起使用时，团队可以控制、自动化和跟踪他们的所有开发遵规行为，从一开始的编码一直到生产，包括各种必要的审批、工作流以及审计追踪记录等。
构建管理流程
如何面对上面所提出的挑战呢？首先软件开发组织应该明确有关构建的基本组成部分和其运作规律，特别是构建管理流程的搭建；其次应配合一些构建及发布管理工具基于有关构建的非常好的实践经验循序渐进进行改进。本节主要从构建基础设施和构建管理流程的搭建进行阐述，在阐述过程中我们将整个构建管理流程进行了分解，这样有助于读者详细了解与构建相关的各个领域，以便进行有针对性的改进。后面的章节我们将主要对构建非常好的实践经验和 IBM Rational 构建管理工具 BuildForge 进行介绍，最后一章将结合案例进行分析说明。
构建配置类型
构建的具体形式和许多因素有关，例如所采用的开发语言、操作系统及其环境、开发所采用的方法论等，但总体而言构建的配置类型可以分为私有构建、集成构建及发布构建。
私有构建是开发人员在自己工作空间内进行的构建，通常用于对自己修改的代码进行校验。集成构建是由核心职能部门或所指定的集成人员将不同开发人员的源代码收集在集成工作空间后进行的构建，集成构建由负责集成构建的人员（通常是开发组长或来自构建部门的人员）来进行，也可以通过调度程序自动定时进行。发布构建是由核心职能部门，通常是来自构建部门的人员执行的直接交付给内部或外部最终用户的构建。发布构建通常在隔离和受控的环境下进行。从构建发生数量来看，私有构建数量最大，集成构建其次，发布构建最少。
尽管构建可以分为以上三种不同配置类型，但并不意味着这三类构建采用不同的构建方式，实际上推荐的做法是重用同一组构建脚本，而仅在谁、什么地方、什么原因、构建内容等方面进行区别。使用一致的构建脚本有助于在早期阶段（私有构建或集成构建）而不是发布阶段发现错误。
端到端的构建流程域
构建管理流程不仅仅是简单的程序编译，它实际涉及一系列端到端的构建流程领域，包括：
版本控制
执行如工作空间的创建和更新、创建基线以及报告等版本控制活动，建立整个构建所运行的环境，并捕获构建流程中输入和输出的元数据，从而确保构建的可重复性和可靠性。
代码静态分析
检查是否所有的开发人员遵从了与开发语言非常好的实践相关的某种编程规范或标准。作为构建的一部分进行代码静态分析可以保证代码能够被开发团队的所有人员修改和阅读。
编译
编译是将源代码转换为可以直接运行的可执行文件或者中间对象。并非所有的项目都必须对代码进行编译处理，比如一些项目使用可以直接运行的脚本语言，但大部分项目都包含编译过程。
单元测试
单元测试是构建质量控制的第一道大门，用于评估是否开发人员的工作成果可以在代码单元一级工作在一起。如果测试全面并很好地进行了测试用例设计，只有通过了所有单元测试的构建才有可能成为一个高品质的构建。
数据处理
并非所有的构建都是单纯的编码和测试，某些特定应用中编译只是整个构建流程的一小部分，主要的构建工作是对数据文件进行解析和转换，从而生成最终的输出，例如多媒体游戏软件从模型到三维图像的处理过程。另外，也有不少应用系统的构建与数据库中的应用元数据的设置相关，这部分数据处理也是构建的一个重要组成部分。
打包
打包是最终产品的一个包装过程，它是将构建的输出结果打包成完整的可安装文件形式。打包后的结果有时也称之为“分发文件”，以 Java 为例打包就是将Java类以及库文件打包为 JAR或EAR文件从而安装在服务器上。
功能集成测试
功能集成测试或者也称之为“链接测试”是构建质量控制的第二道大门，通过在已部署的应用上执行整个功能测试用例集合的一个小的核心部分，来证明该构建可以进行进一步的测试，从而给测试团队以信心。
代码覆盖率
代码覆盖率测试是单元测试或功能集成测试的一个有效补充，它可以帮助您评估已经有多少代码经过了测试，从而明确其他的功能测试应集中在哪些方面（例如，未被测试用例遍历的代码）。
