部署
部署是将构建迁移到运行环境的过程。构建通常会被自动迁移到立即相关的环境（例如集成测试和系统测试环境）下。在一个安全、受控的发布流程控制下，生产环境的部署有时也可以自动完成，但通常都是由一个单独的团队手动完成的。
构建基础设施
构建基础设施包括用于源代码管理的版本控制工具（如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 产品的信息。
