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 提供了比较灵活多样的配置方式，让咱们能够简单便捷的实现各类用例。