TeamCity : Build 版本控制系统配置

VCS (版本控制系统) 是用来跟踪项目源文件版本变化的系统。它还有其它的名字，比如 SCM(源代码管理)。当前 TeamCity 内置支持的 VCS 类型有：Git, Subversion, Mercurial, Perforce, Team Foundation Server, CVS, StarTeam, ClearCase, SourceGear Vault, Visual SourceSafe。

本文将通过实例比较详细的介绍 Build 中版本控制系统的设置。

VCS root

一个 VCS root 定义了一个到版本控制系统的连接，这个连接包含了 TeamCity 和版本控制系统通信的所有信息(源文件路径, 用户名, 密码和其它设置)。有了这些信息，TeamCity 就可以监控代码的变化并且在做 build 时把代码获得到本地。您创建的 VCS root 必须属于某个项目，它可以被这个项目和这个项目的子项目中的 build 使用。

创建 VCS root

您可以点击 “Attach VCS root” 按钮开始 VCS root 的创建过程：

选择您的 VCS 类型，点击 “Create” 按钮：

VCS 类型

TeamCity 内置支持了主流的 VCS :

您可以选择您使用的 VCS 的类型，然后按照提示完成 VCS root的创建。接下来笔者将通过一个实例来说明一些细节。VCS 的类型就选择笔者使用的 TFS (好土啊，居然还没用上 Git!)。

VCS root 名称

VCS  root 名称需要是唯一的，以区分不同的 VCS root，我们在引用 VCS root 时就是通过这个唯一的名称：

VCS root ID

VCS root ID 也必须是唯一的，它会被 TeamCity 内部的程序引用，也可以被用作 REST API 的参数。一般我们不需要手动指定它，TeamCity 会按照下面的规则自动生成：
项目名称 + 下划线 + VCS root名称。

VCS URL

指向 VCS 的 URL，填写您取代码的地址，如：

代码路径

指定从代码库中获取代码的路径：

用户名和密码

从代码库获取代码时提供的认证信息：

强制获取所有文件

这是 TFS 相关的一个选项，当 TeamCity 通过 Build Agent 获取代码时这个选项会起作用。当选中 “Enforce overwrite all files” 时，TeamCity 会通过 请求 TFS 更新所有的文件。一般情况下您是不需要这么做的。当然，有时您可能会怀疑 TeamCity 没有从 TFS 上获取代码，那时您就可以使用这个选项：

最小的检查间隔时间

这个选项指出 TeamCity 多长时间检查一次 VCS 库的变化。默认情况下使用的是从系统继承来的值。在 Administration | Global Settings 页面有系统级别的设置。如果您要自定义这个值，可以选择 custom进行设置。

所属项目

在这里您可以指定当前创建的 VCS root 属于哪个项目：

检查连接情况

您可以在完成创建前检查当前的配置是否可以正确的连接到 VCS，点击 “Test connection” 按钮进行测试：

连接成功的样子：

下面点击 “Create” 按钮完成 VCS root的创建。

配置 VCS root Checkout Rules

我们可以为 VCS root 指定适当的规则，从而控制取到的代码在 build 时的路径。VCS Checkout Rules 允许我们获取库中部分的代码，并且可以映射到 Build Agent 上的指定目录。

具体的语法请参考《TeamCity : Build 基本配置》一文中的 Artifact paths 小节。

注意，Checkout 规则只能指定目录不能指定单个文件，也不能使用统配符。

VCS checkout mode

VCS checkout mode 用来指定源代码文件到达 Build Agent 的方式。从版本 10 开始 TeamCity 支持四种类型的 VCS checkout mode：

Prefer to checkout files on agent

这种方式是最新添加的，也是推荐的默认设置。取代码的方式为先尝试从 Build Agent 上向版本库请求代码，如果不行，再从 TeamCity Server 上尝试。

Always checkout files on server

总是尝试从 TeamCity Server上请求版本库，然后把代码发送到 Build Agent 上。

Always checkout files on agent

总是尝试从 Build Agent 上向版本库请求代码，这种方式的好处是 Build Agent 上有完整的工作区，您可以在 Build 的过程中调用版本库的命令。

Do not check out files automatically

这种模式下执行 Build 前是不会从版本库获取代码的，主要用于调试。比如您可以在 Build 目录中进行文件的修改，然后启动一次 Build，从而验证您的变更。

Checkout directory

默认情况下，Build 在 Build Agent 上的工作目录是被 TeamCity 控制的。但您可以通过设置 Checkout directory 项为 Custom path 来自行控制 Build 的工作目录：

个人感觉 TeamCity 默认的选项已经很好了，除非必要，否则不要自己指定这个选项。

Clean build

如果您有需求必须再每次 Build 之前清空 Build 的工作目录，那么您可以通过设置 Clean build 选项来达到目的：

Display options

允许显示来自 snapshot dependencies 的变更：

总结

Build 中版本控制系统的配置的重要性无须多言，好在 TeamCity 提供了比较灵活多样的配置方式，让我们可以简单便捷的实现各种用例。