本文通过扩展 RTC 的构建功能，简化用户操作，方便">开发人员的协同工作，从而提升工作效率，并防止新提交的代码导致构建失败的依赖。同时，对构建结果比较方面进行扩展，能够快捷的比较出新增功能而不是单纯的变更集。最后，通过自定义用户配置来实现自动部署。
Rational Team Concert（RTC）作为构建在 IBM Rational 面向软件交付技术的下一代协作平台 Jazz 平台上的一个协作式的软件开发环境，它包含了集成的源代码控制、工作项管理和构建管理等功能。其中，RTC 有着非常强大的自动构建能力，其支持的构建过程如下：
构建定义：定义一个构建，
例如，每周进行一次项目范围集成构建。 构建引擎：表示一个在构建服务器上运行的构建系统。 构建请求：表示一个要求运行构建的请求。 构建结果：表示构建的输出。
所有与构建相关的项都属于项目区域，而与构建相关的操作由项目的流程来管理。同时 RTC 还可以完成下列任务：
提交要求运行构建定义的请求。 检查构建状态。 查看已完成的构建输出，例如，日志、下载资源和工件。
然而，由于目前 RTC 的代码版本管理和构建相对独立，缺少能及时正确的检查构建最终结果的机制。开发人员只有在将新添加的代码提交到工作流（work stream）后，才能去验证新添加的代码是否会影响到整个系统的构建。如果开发人员忘记验证构建的正确性，就将代码提交到最终的工作流（work stream），新添加的代码有可能造成整个系统的崩溃；此外，构建结果的比较功能相对简单，目前只有不同构建结果的变更集（change set）的比较，而对变更集所对应的 work iteam 的差异却不能直接查看，需要大量手工操作，才能通过变更集来查看相关联的 work iteam，来满足实际需求。但是，RTC 作为一个具有极强扩展性的平台，如图 1 所示：
图 1.RTC 的扩展架构
我们可以通过 REST API 和 Plain Java API 来对 RTC 进行扩展。Plain Java API 又包括 Work Item API, Source Control API 和 Build API。
图 2.Plain Java API
其中 Build API 提供了三个主要的接口：
ITeamBuild
Client: 用来在
Repository 中访问构建 ITeamBuildRequestClient: 用来创建、
获取和操作构建的请求 IbuildRequestQueryModel：查询构建结果
本文将着重介绍怎样通过 Build API 来实现对 RTC 自动构建的扩展。通过应用 Build API 来整合代码的提交和构建的执行，从而使开发人员在提交自己代码的同时，对自己新添加的代码来做一次构建，来验证是否会影响整个系统的构建，可以及时的发现问题并解决；另外，还对构建的比较功能进行了增强，从而实现对构建结果进行 work iteam 的比较；最后，介绍了怎样将自定义参数引入到 RTC 的自动构建中。