预先测试（延迟）提交
预先测试的提交是一种方法，可以防止将有缺陷的代码提交到构建中，因此不会影响整个团队的过程。 这些图表说明了下文所述的 TeamCity 对预先测试提交的方法。
提交的代码更改首先要进行测试。 如果代码通过了所有的测试，TeamCity可以自动将更改提交到版本控制中。 从那里开始，这些更改将自动集成到下一个构建中。 如果任何测试失败，代码将不会被提交，且系统将通知提交的开发者。
开发人员通过执行 Remote Run 来测试他们的更改。 当选中 如果成功则提交更改 选项时，将启用预测试提交功能。
预先测试的提交是通过适用于支持的 IDE之一插件启动的。 对于远程运行，也有一个命令行工具可用。
对于 Git 和 Mercurial ，推荐使用 Branch Remote Run Trigger 方式来运行分支上的个人构建。
匹配变更和构建配置
要提交已更改的文件以进行预测试提交或远程运行，IDE 和 TeamCity 中应该能够运行 VCS 集成，并且 TeamCity 应能确认这些文件在提交后，会影响服务器上的构建配置。
如果 TeamCity 无法将更改与构建进行匹配，则会显示一条“提交的更改无法应用于构建配置”的消息。
VCS 集成应在 IDE 中正确配置，且 TeamCity 应能将开发者工作站上的文件匹配到 TeamCity 服务器上存在的构建配置。 为了能够做到这一点，VCS 应该在开发者的工作站和服务器上进行相同的配置。
这包括：
对于 CVS 、 TFS 和 Perforce 版本控制系统 - 请使用与版本控制服务器完全相同的 URL。
对于 VSS —— 请使用与 VSS 数据库（机器和路径）完全相同的路径。
对于 Subversion —— 使用相同的服务器（TeamCity 匹配 server UUID）。
对于 Git —— 当前检出的分支应将 "remote" 设置为 TeamCity 服务器监视的服务器/分支，并且应与服务器监视的分支在历史记录中有共同的提交。
如果在更改文件选择 TeamCity 时无法找到可以发送文件的构建配置，那么，启动个人构建的选项将无法使用。
预测试提交的一般流程
开发人员使用 TeamCity IDE 插件 的远程运行对话框来选择要发送到 TeamCity 的文件。
根据所选文件，将显示适用的构建配置列表。 开发者选择用于测试更改的构建配置，并设置预测试提交的选项。
TeamCity IDE 插件会构建一个“补丁”- 所有选中文件的全部内容，并将其发送到 TeamCity 服务器。 补丁也被保存在开发者的本地机器上。 当发送时，更改将出现在开发者的 changes 页面上。 开发者可以继续编写代码，并且可以修改发送到预测试提交的文件。
个人构建会像其他排队的构建一样，被排队并处理。
当构建开始时，它会检出最新的源代码，就像正常的构建一样，然后应用从 IDE 发送过来的开发者的个人更改（使用完整文件内容）。
构建如常运行
在构建结束时，个人更改将从构建的检出目录中还原，以确保它们不会影响后续的构建。
TeamCity IDE 插件会向 TeamCity 服务器发送请求，以检查所选的所有构建配置是否都已准备好个人构建。 如果构建失败，IDE会显示通知，并终止进程。
如果所有个人构建成功完成，IDE 插件将显示进度，备份参与个人更改的文件的当前版本（因为自启动预测试提交以来，这些文件可能已经被修改过），然后从保存的 "补丁" 中恢复文件内容，执行版本控制提交（如果出现错误，例如 VCS 冲突，则报告错误），并恢复刚刚备份的文件，以将工作副本恢复到最后看到的状态。 在 TeamCity 插件窗口中，预先测试的提交获得错误或成功标记。