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 提供了比較靈活多樣的配置方式，讓咱們能夠簡單便捷的實現各類用例。