软件构建流程是软件生命周期一个非常关键的环节，直接决定了开发工作是如何最终交付给最终用户的，但构建流程长期以来被认为最难以结构化和规范化管理，同时围绕软件构建和发布管理的最佳实践经验也不足。但随着软件复杂度的不断提高，软件交付周期的不断缩短和交付频率的提高，软件构建流程已经逐步得到重视。本文描述了利用 IBM Rational BuildForge 进行构建和发布过程管理及自动化的方法，并讨论了如何通过整合项目组、流程以及系统来改进软件开发效率，从而提高整个开发团队的效率，改进产品质量，更好地遵规。

概述

软件构建流程是软件生命周期一个非常关键的环节，直接决定了开发工作是如何最终交付给最终用户的，但构建流程长期以来被认为最难以结构化和规范化管理，同时围绕软件构建和发布管理的最佳实践经验也不足。但随着软件复杂度的不断提高，软件交付周期的不断缩短和交付频率的提高，软件构建流程已经逐步得到重视。

“软件构建管理在日益影响成功的软件部署，业务以及IT的生产率，软件构建管理正成为IT企业关注的一个重点。” - IDC

“如果不能提供一致、精确以及可重复的软件构建，会形成软件开发中的严重瓶颈从而造成软件开发团队不能很好地在不增加额外资源的前提下管理项目的复杂性。” - Hurwitz

IBM Rational BuildForge 是一个用于构建和发布自动化的系统，可以集中、自动化并且加速不同软件开发组织的软件开发过程。在与 IBM　Rational 软件开发平台的其他软件一起使用时可以帮助企业打造用于端到端的软件交付流水线的开发环境。同时也可以更好地帮助软件开发组织遵规。对于从事多种软件应用开发的组织 BuildForge 可以提供一个灵活集成的平台，从而充分利用用户在已有工具的投资来提高整个团队的交付效率、实现交付自动化和可跟踪性。

对于异地分布的团队BuildForge可以帮助不同地域的团队更高效地进行协同。BuildForge 提供的跨多种应用和硬件平台的集中访问方式可以实现全球性的报告、跟踪和硬件资源使用优化。通过 Rational BuildForge，开发团队从大量重复性的任务中解脱出来，以更聪明的方式进行工作，将精力集中在构建及发布过程的度量和改进上来。

构建远远不是编译

许多人都将构建（build）与编译混在一起，认为两者没有大的区别。实际上构建的内涵和外延远远大于编译。构建是指从源码到最终投产或上线的整个生命周期，而编译只是从源码到中间代码或可执行代码的过程。下面几张图解释了两者之间的差别。

图 1: 两者之间的差别

如上图所示，编译只是中间的黑色部分，从技术上看是从源码向机器码翻译的过程。而构建特别是基础构建能力应该包括：流程管理、多平台支持、构建流程/执行/结果的集中统一控制、以及与其他工具的无缝集成，这些都是处理当前开发环境中的硬件资源、工具、语言及脚本不可或缺的核心构建能力。

图 2: 在基础构建能力上可以进一步加强构建的可靠性和可再现性

在基础构建能力上可以进一步加强构建的可靠性和可再现性，从而进行人和硬件资源的优化，因此可以在核心构建能力上进一步进行扩展。如上图所示，这些扩展构建特性包括：基于角色的安全性访问控制、可重复性、对敏捷开发的支持、动态服务器选择以增强系统的可靠性和硬件利用率、构建流程自动化、构建队列管理、构建并行化处理、嵌入集成开发环境的自助构建服务等。

图 3: 构建管理的开发与验证的典型过程

进而，为了将前面提到的基础构建能力和扩展构建能力推广到整个组织，并且更好地应对审计和遵规要求，构建还应包括面向整个企业的报告和沟通能力。这些特性如上图所示可以包括：报告及分析能力、端到端的全生命周期跟踪、审计跟踪和日志记录、包含所有流程细节步骤及运行结果详细信息的物料清单（BOM）、跨团队的通知以及问题诊断、在构建执行过程中自然而然形成相关文档（自文档）、服务器静态（如操作系统类型、版本及补丁等）及动态属性（CPU负载、空闲内存等）管理、以及遵规和治理的支持。

本文要介绍的IBM Rational构建管理产品BuildForge覆盖了上面所涉及的方方面面的构建特性。

当前构建及发布过程面临的挑战

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文件从而安装在服务器上。

功能集成测试

功能集成测试或者也称之为“链接测试”是构建质量控制的第二道大门，通过在已部署的应用上执行整个功能测试用例集合的一个小的核心部分，来证明该构建可以进行进一步的测试，从而给测试团队以信心。

代码覆盖率

代码覆盖率测试是单元测试或功能集成测试的一个有效补充，它可以帮助您评估已经有多少代码经过了测试，从而明确其他的功能测试应集中在哪些方面（例如，未被测试用例遍历的代码）。

部署

部署是将构建迁移到运行环境的过程。构建通常会被自动迁移到立即相关的环境（例如集成测试和系统测试环境）下。在一个安全、受控的发布流程控制下，生产环境的部署有时也可以自动完成，但通常都是由一个单独的团队手动完成的。

构建基础设施

构建基础设施包括用于源代码管理的版本控制工具（如IBM Rational ClearCase， CVS等）、构建工具（如用于 C/C++ 的 make，用于 Java 的 Ant 等）以及参与构建的硬件（包括开发人员桌面机、构建服务器以及版本控制服务器等）。

构建的定义、执行和报告

构建的定义也就是构建的脚本化，例如使用 GNU Make 或 Apache Ant 进行脚本编写的过程。这些脚本定义了应用的各个部分应该如何编译和链接在一起以形成最终的系统或应用。这些脚本也可能将处理过程的其他部分自动化，例如数据库的配置和安装。在构建定义阶段可以定义任何可以自动化执行的部分。

构建执行或构建控制是以受控（通常是自动化）方式进行构建脚本的执行。构建控制也包括对构建结果（成功或失败）的报告。构建报告分为不同类型的报告，如基本编译报告、单元测试报告、发布报告等。

构建相关角色和职责

从上面各节的介绍可以看到构建流程是不同用户、不同团队之间工件以及沟通的重要渠道，许多不同角色的用户，从开发人员、测试人员到构建人员、项目经理甚至运营维护团队都会受构建流程的影响。但是这里我们主要介绍一下直接与构建流程相关的核心用户角色及其职责：

开发人员

编写源代码，执行单元测试，提供构建所需的工件。

构建工程师

通过工具和/或编写脚本建立构建流程，并负责构建流程的自动化执行。

部署工程师

负责将构建输出结果迁移到运行环境中。在大型企业中部署工程师通常来自与开发部门不同的IT运营部门。

在一些企业上面的一些角色可能是交叉的，即一个人可能即担任构建工程师同时又是开发人员。

构建频率

构建频率是软件开发团队另外一个需要做的重要决策，即多久进行一次集成构建或发布构建。在软件开发上普遍使用了以下三种不同的构建调度策略：

每周构建

每周构建普遍用于有多支开发团队的大型软件开发项目，不同开发团队的成果或变更每周定期提交到一个系统集成区域，在集成后进行系统集成构建。

每日构建及冒烟测试

每天（通常在夜间）基于当天所提交的变更进行一次集成构建，另外在构建后进行一组冒烟测试。

持续集成构建

一种广泛用于敏捷开发方法的构建方式，即不断对版本库进行监控，一旦有变化进入版本控制库就自动开始集成构建，持续集成构建通常构建时间较短（小于10分钟）并且伴随完整的单元测试。

通常而言构建越频繁，也就越有可能尽早发现集成问题。因此用户应该努力尽可能频繁地进行构建。

关于构建的最佳实践经验

软件开发生命周期的其他规程，例如需求管理、配置与变更管理以及测试等长期以来总结出了不少最佳实践经验，同时形成了多种商业化工具、出版物以及覆盖这些最佳实践的分析报告等，但有关构建和发布的实践及工具仍然较少，但这种现状正在得以改变，特别是 IBM Rational BuildForge 的出现。尽管许多软件开发组织通过自己开发来进行构建和发布过程的管理，但这些方案功能一般不太完整，同时没有很好的可扩展性，很难进行维护从而满足企业需求的不断增长。

同其他 IBM Rational 产品一样，IBM Rational BuildForge 里渗透了许多关于软件构建和发布管理的最佳实践经验。由于不同用户的情况和需求不同，因此这里列出的最佳实践经验没有实施次序上的要求。不同用户在应用这些经验时可以根据自身情况，从容易见效、投入低的实践开始，逐步进行构建和发布过程的改进。

• 完整的可再现性
• 构建流程的自动化和与关键系统的集成
• 从物理资源中进行流程及元数据的抽象
• 流程优化及架构设计支持
• 构建加速技术
• 所有使用人员能够进行构建信息的集中访问和协作
• 尽早构建，经常构建
• 构建流程与部署环境的集成
• 根据业务目标进行性能度量

本文的后续部分，将介绍 IBM Rational BuildForge 的产品特性，以及如何利用 IBM Rational BuildForge 建立起的构建管理平台，改进构建流程的管理和控制效率。

参考资料

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