在相关Workspace中，整合所有不在最近一次基线中的已完成的Change Set。通过删除产生冲突的某个变更集，或者创建合并了冲突工件的新的变更集，来解决任何产生冲突的工件版本。

创建构建。此步骤的细节依赖于实现的语言、开发环境、并可能涉及编译、链接（在编译语言的情况下）和/或其他处理的结果。

这些步骤的例子包括：

1. 编译并链接源工件成为可执行程序
2. 在测试工作台或模拟器上加载二进制对象
3. 运行脚本加载/更新数据库模式
4. 打包并部署Web应用

重新运行开发人员测试，验证这些被集成元素的行为是否和独立测试时一样。确保这些测试的范围尽可能的宽广，保证最近的变更集不会引起系统其它区域的开发人员测试出现失败。

在每次迭代中将创建多个构建。对每个构建，仅当交付的变更集满足了该构建的需求时，执行此步骤。

执行系统测试的一个子集，以保证该构建已经适合投入资源开展全范围的系统测试。此层面的测试会有所不同，重点在于获取信心，此增量拥有足够的质量能够为开展系统测试建立基线。

当成功完成测试并认为此构建“良好”，那么通过Promoting Changes提交结果，以便其余的团队能够使用该结果。此步骤的细节依赖于使用的配置管理工具，但通常这涉及提交经过测试的变更集到配置库中，从而作为下一次系统增量的开发基础。这是Continuous Integration的本质。