| IBM
Rational BuildForge 集成构建解决方案
经过业界许多用户的使用证明 IBM Rational BuildForge
可以帮助软件开发组织加速软件开发流程，增强产品质量，更好地支持异地分布的开发团队并满足审计和遵规需求，下面就从这三个层面来描述一下围绕
BuildForge 的集成构建解决方案。
加速软件开发流程
开发流程中的瓶颈
Rational BuildForge 提供了多种特性来解决软件开发过程中的常见瓶颈，从而加速用户的软件开发流程，这些瓶颈包括：
1.软件开发过程中从一个团队到另一个团队低效的流转
2.缓慢串行的处理速度
3.由于系统问题造成的停工
4.硬件资源的利用不充分
5.批处理过程不透明
因此本节主要描述 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 就可以使下面的使用场景成为可能：
1.一个部门需要偶尔在 Linux 服务器上运行一些流程，通过 BuildForge
无需直接进行物理访问或对系统进行修改就可以提供受控的访问权限。例如该部门只能在该 Linux 服务器上运行某些特定的任务，而且可以在这些任务执行结束后自动将产生的结果清除掉。如果这些任务的运行过于频繁还可以禁止超过限制的运行请求。
2.一个部门的服务器可以设置为另一个部门的备份服务器，如果一个部门的关键服务器宕机，系统可以自动使用备份服务器直到首选服务器重新可用。
3.可以将一组机器组织成服务器池，不管涉及的部门或项目是什么都可以在服务器池上运行任何需要它们的流程。
4.可以仅将本部门一台机器的一部分运行能力赋予其他部门。这些场景总的说来可以在提高处理速度的同时减低企业成本。
流程透明度和用于持续改进的分析
由于 Rational BuildForge 可以跟踪用户从编码到生产期间所执行的所有活动，因此在 BuildForge
中包含了相当丰富的信息，这些信息可以帮助团队提高生产效率。Rational BuildForge 可以生成一组预先定制好的报告，供用户用来分析自己的流程并持续进行改进。同使用大量的批处理文件或脚本却只能提供对流程有限的可见性相比，使用
Rational BuildForge 可以帮助用户：
不用搜索大量的日志记录就可以快速定位问题。如下图所示 BuildForge
提供了丰富的日志自动过滤搜索机制，用户可以抽象并定义错误或警告信息的模式，例如“ERROR”、“MYSYS_ERROR_CODE”等，同时可以定义一旦在日志或返回信息中搜索到满足这些模式的字符串后需要做什么样的处理，例如置为错误并终止运行，置为警告并继续运行，尽管返回信息为警告但可以清楚警告标志并继续运行等等。另外还可以定义需要通知哪些角色的人员。
图 7: BuildForge 提供了丰富的日志自动过滤搜索机制
检查每个流程甚至每个步骤的实际执行时间，从而发现运行趋势以及反常的运行。下图示出了通过
BuildForge Performance Report 对“GCC 编译演示”项目的多次运行过程进行的分析。包括时间趋势分析以及各个步骤的时长分布。
图 8: “GCC 编译演示”项目示例
1.跟踪问题发生的具体位置，属于跨部门的问题还是某个部门内的问题。
2.随着时间推移跟踪服务器的利用率。
3.发现代码变化最频繁的部分并定位错误发生的热点地区，改进项目计划。
4.使用 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 知识库中：
1.查看当前流程的定义
2.查看流程上一次运行的结果
3.随着时间推移查看流程定义的变化
4.查看注释中关于流程为什么变化的解释原因
BuildForge 系统创建了一个关于流程的知识库，并且自动进行流程的归档从而流程以标准化、一致和可重复的方式执行。
通过自动化减少人为错误
Rational BuildForge 为用户提供了实施全方位构建和发布自动化系统的工具。在设计好一个流程后，用户可以轻松将其自动化，然后将该自动化流程共享给组织的其他部门或人员。通过
BuildForge 可以实现下列内容的自动化：
调度日常流程运行
图 12: 调度日常流程运行
1.根据一次运行或一次运行的一部分的成功或失败决定下面的活动流向
2.基于源代码的变更决定活动流向
3.基于流程运行的成败自动交付报告
4.每次运行自动生成物料清单（BOM），由此得知为什么要运行以及谁做的变更。
5.通过这些特性，每个团队都会变得更加有效率。
6.开发团队可以进行更频繁的代码构建，从而立即得到关于他们代码效果的反馈。
7.QA 团队可以获得每次发布的内容以及是否可用的细节信息，这样就可以从经过自动化测试后的构建结果开始工作，评估发布中的问题。通过自动化测试可以帮助检查许多常见问题，从而将精力集中在其他更为复杂的测试上。
8.配置管理团队在日常操作方面可以花更少的时间，把更多时间用在开发流程优化上。
9.IT 团队可以利用 IBM Rational BuildForge
的报告帮助评估当前系统的需要以及未来的系统需求。
集中控制分布访问
团队的沟通问题经常是阻碍发布及时性的一个关键因素。如果没有一个高效的构建和发布自动化系统，配置管理团队对于请求新构建、新测试以及新项目的响应能力会对开发流程产生不利影响。另外，与构建流程脱节的开发人员经常会因为等待构建结果而丧失效率。类似地，如果一个项目不可被重复并且没有很好地进行文档化，会很难确定产品不同版本的信息，重现客户的问题，结果重现客户问题经常变成整个问题修复过程中最花时间的部分。
Rational BuildForge 通过统一控制及基于角色的安全访问机制可以支持地域分布的开发团队。用户可以将来自许多部门的流程集中在一个统一系统中，然后可以将对这些流程的访问以及这些流程生成的信息扩展到整个组织中任何期望扩展到的范围。统一的配置管理组可以先创建并测试流程，然后将流程的使用权限授予其他相应组的成员，即使这些人员不都属于同一部门。不属于正式配置管理组的个人可以创建他们自己的流程并将其在公司范围内共享。同时管理人员拥有管理控制权，决定谁可以运行某个自动化流程、阅读某个报告或定义一个新流程。
通过 Rational BuildForge 开发人员可以启动构建项目，及时得到反馈并对新特性或缺陷修改进行测试，但开发人员只能启动那些有权限启动的项目。这种自助服务使得开发人员获得更高的生产效率，减少配置管理团队在响应这类请求方面花的时间。实际上如前所述，这种思路并不局限在构建及发布方面，用户可以将其扩展到想自动化的任何流程。
通过更频繁的测试周期提供敏捷性
尽管自动化测试永远不能替代 QA 团队的所有工作，但 Rational BuildForge 可以将有效的自动化测试嵌入到整个构建和发布流程中，并将测试结果在整个组织范围内共享。进而
Rational BuildForge 的自文档特性可以帮助使每个测试周期更加有效，因为每次构建包含了此次构建的过程以及最终的可执行文件所包含的内容等信息。任何迭代化开发流程，例如敏捷开发及其他方法论都要求不断进行的“编码－构建－测试”活动来给开发团队和测试团队提供频繁的反馈。Rational
BuildForge 提供了强大的自动化、调度以及源代码集成能力，帮助团队实现持续集成。通过 IBM Rational
BuildForge 测试人员可以在许多有关产品的细节信息都已明确的基础上开始测试。
1.通过自动化测试检测到的问题可以在 QA 人员得到发布版本之前就可以反馈给开发团队，这样手工测试就可以在自动化测试通过后才开始。
2.以前碰到的问题可以很快加以重测，从而加速和改进回归测试流程，以便开发人员和测试人员较少担心引入新问题，而是将精力集中在新问题的修复上。
3.可以自动执行压力测试和负载测试。
4.通过 Rational BuildForge 的体系结构决定了它可以在所有目标机器上启动测试活动并收集测试结果。
5.Rational BuildForge 定制过滤器可以对测试结果进行预处理，用详细的警告或失败列表来加强报告能力。
6.物料清单（BOM）报告可以详细报告构建中包含的缺陷修复，因此可以对每个缺陷修复进行测试或者和自动化测试结果进行逐一匹配。
7.Rational BuildForge 可以与用户的源码控制系统和缺陷追踪数据库进行集成。
测试团队还可以将 IBM Rational BuildForge 用于：
1.执行冒烟测试。在每次构建后启动一个基本测试集，依据该测试集的成败来确定本次构建是否满足基本要求，是否可以继续后续测试。
2.自动将完成的构建安装在多台目标机器上。可以使用 Rational BuildForge
来配置用户的测试环境并通知测试人员这些机器已经准备好运行测试脚本了。
3.确定执行哪些测试。Rational BuildForge 系统中的项目都有不同的类别（class）标记，用户可以使用项目类别来决定执行哪些测试。下图是项目类别定义画面，在
Start on entry 可以决定一旦项目类别转为此类后就开始执行的项目，例如一旦一个项目从开发类转为测试类后就开始执行一个测试项目。
图 13: 项目类别定义
1.如果某个开发人员只想执行一个快速构建可以选择跳过测试步骤。
2.对于自动调度执行的构建，执行一个冒烟测试以确保主要部分没有问题。
3.对于一个生产构建，运行一个完整的测试集合，可能包括扩展性或负载测试。这可能需要非常大的系统资源。
以上这些特性使得在整个流程中建立更有效率的测试成为可能，因此也就将更高的品质融入到最终产品发布中。
为集成而进行的产品设计
从本质上看 IBM Rational BuildForge 实际上是一个将不同应用组合在一起以完成复杂开发任务的解决方案。借助
Rational BuildForge 用户可以轻易地将项目中的不同应用、操作系统命令、批处理文件或外壳脚本混合在一起。
通过其独特的命令行封装能力，Rational BuildForge 可以对在目标系统上执行的每条命令在执行前创建适合该命令的必要环境。并且用户可以为与系统其他部分集成的命令定义所需的环境。
除了将不同应用链接在一起这一基本功能以外，Rational BuildForge 也可以与其他解决方案进行集成。
1.可以通过轻量级目录访问协议（LDAP）标准与现有的用户数据进行集成，这样就避免了为新的信息系统创建额外的用户登录帐号。
2.IBM Rational BuildForge 为常用的源码控制工具、缺陷跟踪工具以及测试自动化系统提供了开箱即用的适配器，这样就可以通过开发活动来驱动信息的更新。例如，BuildForge
和 Rational 配置管理工具 ClearCase 的集成可以在编译前调用 ClearCase 相关功能来扫描版本库的变化，只有版本库有变化时才进行编译。下图示出了创建一个用于源码控制的适配器界面，利用随产品提供的源码控制工具适配器模板可以快速创建一个同源码控制工具（如
ClearCase）的接口（适配器），将该接口与具体的项目链接在一起后就可以在项目活动开始前调用 ClearCase
的功能（如扫描上次编译时间以来版本库内发生的变化）了。
图 14: 创建一个用于源码控制的适配器
3.通过 IBM Rational BuildForge 的 API
接口用户可以在自己的信息系统中从其他应用程序调用 BuildForge 的功能，用户可以进行细粒度的流程控制。借助上面这些功能，Rational
BuildForge 可以成为用户开发环境中的关键组成部分，同时成为企业信息系统中的重要成员之一。
开箱即用集成的价值：IBM Rational 软件开发工具
IBM Rational BuildForge 标准版和 IBM Rational
BuildForge 企业版都可以配有开箱即用的与 IBM Rational 软件开发平台（SDP）的紧密集成，可以快速给客户带来价值。通过集成使用这些产品，公司可以管理、自动化和跟踪从需求到生产整个开发生命周期。这些集成包括：
1.IBM Rational ClearQuest。Rational BuildForge
自动检测用于特定构建过程的 ClearQuest 活动，一旦一个构建成功完成，Rational BuildForge
可以自动将相关联的缺陷状态置为已解决状态，并在 ClearQuest 中将这些已解决的缺陷关联到构建记录上，这样就可以轻松在
ClearQuest 中查出某次构建所包含的缺陷修复。Rational BuildForge 还可以通过与
ClearQuest 的接口创建一个部署单元（deployment unit），用于传递给使用 IBM
Tivoli Provisioning Manager 的部署工程师。
2.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 提供了许多集成选项来自动化并优化开发流程，包括：
1.监控源代码变化。IBM Rational BuildForge 适配器提供了持续监控第三方源码库的能力，并且当源码库发生变化时自动执行构建。系统直接监控源码变化并收集度量信息，为每次构建提供详细的源码库状态跟踪。使用
Rational BuildForge 管理控制台，可以看到每次构建中从版本检入注释到实际的文件内容都是哪里发生了变化。
2.自动化缺陷跟踪和测试。Rational BuildForge 缺陷跟踪适配器可以帮助团队跟踪缺陷并在物料清单中报告指定缺陷的状态，例如“已校验”或“已关闭”。自动报告的缺陷可以帮助用户了解某次特定构建中都修复了哪些缺陷。
3.自动化测试用例运行并通过提供的测试适配器将测试结果记入物料清单。
适配器技术将源代码变化、缺陷以及测试与特定的构建关联起来，这样加强了对构建组成部分的详细了解。IBM
Rational BuildForge 可以捕获关键的构建统计信息，包括所施加的变更、构建时间和日期等并为了便于访问将这些信息集中存储在一个位置。
支持审计和遵规管理
如本文前面所讨论的，遵规是大多数开发团队正在考虑的一个重要问题。即使开发团队不对公司的财务系统负责，但开发团队所交付的产品或服务对于公司的收入而言很可能是至关重要的，同时开发团队应该准备应对审计方面的要求。
作为萨班斯法案的结果，许多公司已经意识到标准化、可重复和文档化的开发流程也是一个关键的业务最佳实践。关键是尽量减少收集相关审计数据的代价，从而减少开发团队的负担。IBM
Rational BuildForge 可以捕获关键数据并提供从编码到生产全生命周期的可跟踪性，因此可以用作对应遵规和审计的证据。当使用
Rational BuildForge 来运行构建和发布流程时，系统自始至终自动跟踪用户的流程。将越多的流程放入
Rational BuildForge 系统，对于开发环境的了解也就越清晰。
系统保留了用户所有流程的版本信息，对于每个产品迭代，用户可以看到改变了什么，谁进行的修改以及为什么要进行这样的修改。并且系统为每个完成的流程运行提供了物料清单（BOM）。
对流程进行自动跟踪
即使是最简单的脚本只要在 Rational BuildForge 中运行，因为系统保存了每次项目运行的数据，它也可以作为一个有价值的遵规工具。例如一个普通的批处理文件或外壳脚本，它的作用是将文件从一个位置复制到
Web 服务器上，当在 Rational BuildForge 中运行它时它很快就远远不是一个普通脚本了。再看看下面这些例子：
1.系统可以通过电子邮件和基于 Web 的信息板进行项目运行成功或失败的报告。
2.尝试运行的命令和结果输出或者错误信息都保存在日志中。
3.系统可以调度脚本反复运行多次，保证标准流程每次都以同一方式得以执行。
4.系统可以发现可用的服务器资源来运行脚本，而不是依赖某一台特定机器。
5.系统会对脚本的执行人进行日志记录。
其他用户动作，如对脚本的修改也会被记录下来。另外， 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 的示例流程
物料清单就象一张从流程中的一个团队传到另一团队的工作说明书，没有物料清单构建就是一个神秘的黑箱，不知道里面装的是什么，也不知道结果是什么；而拥有了物料清单团队可以快速评估一次新的构建对他们意味着什么。物料清单就象一张从流程中的一个团队传到另一团队的工作说明书，没有物料清单构建就是一个神秘的黑箱，不知道里面装的是什么，也不知道结果是什么；而拥有了物料清单团队可以快速评估一次新的构建对他们意味着什么。总之，物料清单将流程以及流程端到端的运行结果都封装到一个直接可用的包中，适于审计或遵规校验。
|
