预先测试（延迟）提交
预先测试的提交是一种方法，可以防止将有缺陷的代码提交到构建中，因此不会影响整个团队的过程。 这些图表说明了下文所述的 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 插件会构建一个“patch”——所选文件的全部内容，并将其发送到 TeamCity 服务器。 补丁也被保存在开发者的本地机器上。 当发送时，更改将出现在开发者的 changes 页面上。 开发者可以继续编写代码，并且可以修改发送到预测试提交的文件。
个人构建会像其他排队的构建一样，被排队并处理。
当构建开始时，它会检出最新的源代码，就像正常的构建一样，然后应用从 IDE 发送过来的开发者的个人更改（使用完整文件内容）。
构建如常运行
在构建结束时，个人更改将从构建的检出目录中还原，以确保它们不会影响后续的构建。
TeamCity IDE 插件会向 TeamCity 服务器发送请求，以检查所选的所有构建配置是否都已准备好个人构建。 如果构建失败，IDE会显示通知，并终止进程。
如果所有个人构建均成功完成，IDE 插件会显示进度，备份参与个人更改的文件的当前版本（因为自预测试提交启动以来，这些文件可能已经被修改），然后从保存的“patch”中恢复文件内容，执行版本控制提交（如果出现错误，例如 VCS 冲突，则报告错误），并恢复刚刚备份的文件，以使工作副本恢复到最后一次看到的状态。 在 TeamCity 插件窗口中，预先测试的提交获得错误或成功标记。