前文中我們在 TeamCity 中建立了一個專案 HelloApp，並在這個專案中建立了一個名為 HelloAppDailyBuild 的Build 用來編譯 demo 程式。本文我們將詳細介紹 Build 中的基本配置。下圖是 Build 基本配置的概覽：

Name

Build 配置的名稱。

Build configuration ID

Build configuration ID: 在系統中標識該 Build 配置，自動生成的規則是：專案名稱 +下劃線 + build 配置名稱。
比如要導航到一個 build 配置的頁面， URL為：
HelloApp_HelloAppDailyBuild
最後一個引數就是 Build configuration ID。這個ID非常重要，我們使用 urls, REST API 向伺服器請求資訊時，都要使用它。在伺服器上，它還作為一些配置檔案的目錄名稱。

Description

作為描述資訊，Description 會顯示在 build name 的後面：

Build number format

我們可以為 build number 指定一個格式。不同的使用者總是有不同的需求，如果您想要 build number 顯示為一個自增的整數，就可以把 build number 指定為 %build.counter%。build.counter 是由 TeamCity 來維護的，您也可以手動指定它。設定為 %build.counter% 的 build number format 看起來是這個樣子：

我們還可以指定為：
%build.vcs.number.%
或者
%property.name%
這些都是 TeamCity 維護的一些變數。一個完整的例子看起來像這個樣子 :
1.0.%build.counter%.%build.vcs.number.My_Project_svn%
注意，最好是保持 build number 的唯一性。所以應該把 build counter 加入到 build number format 中。
如果想用日期做 build number 該怎麼辦，如果還要顯示 build 在每天中的序號呢？遺憾的是預設情況下我們沒辦法完成這樣的需求，但是 TeamCity 提供了很好的擴充套件能力。我們可以寫一個外掛了實現這樣的功能：

Build counter

Build 次數的計數器，您也可以手動設定它。但您做好清楚的知道自己在幹什麼。

Artifact paths

收集 build 產物需要透過指定 Artifact paths 來完成。我們可以把產物的路徑分為兩類：準確的路徑和透過模式匹配獲得的路徑。

準確的路徑

如果您知道 build 產物的準確路徑，就可以直接寫產物的路徑。
還可以透過 teamcity 的工具進行選擇：

透過模式匹配來指定路徑

可以透過新行或者逗號來分隔不同的模式匹配規則如：

[+:]source [=> target]

這個規則把滿足條件的檔案加入到產物中。

-:source [=> target]

這條規則則是把滿足條件的檔案從產物中移除。 

方括號圍起來的引數是可選的。規則根據右面的部分進行分組，根據出現的順序依次起作用，如：

+:**/* => target_directory-:**/folder1 => target_directory

表示除了 folder1 下的內容，把其他所有內容加入到產物中。

下面是詳細的格式 :

file_name|directory_name|wildcard [ => target_directory|target_archive ]

file_name 指定產物檔案相對於 build checkout directory 的路徑。
directory_name 指定某個目錄相對於 build checkout directory 的路徑。目錄下的所有檔案和子目錄都會被作為產物。產物中檔案在目錄中的結構保持不變。但是目錄 directory_name 本身並不包含在產物中。
wildcard(萬用字元) 收集符合 Ant-like 的萬用字元匹配的檔案作為產物 (僅支援 "*" 和 "**")。萬用字元要出現在相對於 build checkout directory 的路徑中。符合條件的檔案在產物中的路徑會保持原來的路徑結構。
還可以在收集產物的規則中使用引數。引數可以是 TeamCity 內建的變數也可以是使用者自己定義的變數。

=> 後面的部分是可選的。=> 後面跟的目錄名可以用來指定產物檔案所存放的目錄。
如果沒有設定目標目錄，那麼產物會被放置在 build 產物的根目錄下。
注意，目標路徑不能是絕對路徑。非相對的路徑會在build時產生錯誤。
target_directory 收集的產物檔案會被放到這個目錄下。
target_archive 把產物打包後歸檔檔案的路徑。支援的歸檔檔案格 式有 .zip，.7z，.jar，.tar.gz，.tgz。

下面是一些常用的例子：

install.zip
// 把 build checkout directory 目錄下的所有檔案放入壓縮包 install.zip 作為產物。

dist
// 收集 build checkout directorydist 目錄下的所有內容作為產物。

target/*.jar
// 收集 build checkout directorytarget 目錄下的所有 jar 檔案作為產物。

target/**/*.txt => docs
// 收集 build checkout directorytarget 目錄及其子目錄下所有的 .txt 檔案 作為產物。並把這些檔案全部放入目標目錄 docs 中。

reports => reports, distrib/idea*.zip
// 把 build checkout directoryreports 目錄中的內容放入產物中的 reports 目錄下。
// 把 build checkout directorydistrib 目錄下符合 idea*.zip 條件的檔案放到產物的根目錄下。

// 我們還可以指定產物在 zip 歸檔檔案中的位置，如：
resultsresult1Dir1Dir2 => archive.zip!results/result1/Dir1
// Dir2 目錄中的內容將新增到歸檔檔案中的 results/result1/Dir1 目錄下。

// 產物中相同的歸檔檔名稱可以被使用多次，如:
+:*/*.html => report.zip +:*/*.css => report.zip!/css/-:*/*.txt => report.zip

Build options

Build options 為我們提供了另外一些功能。

Hanging Build Detection

探測掛起的 build，TeamCity 能夠探測可能是被掛起的 builds。
什麼樣的 build 被認為是被掛起的 build 呢？當一個 build 的執行時間明顯的超過了系統估計的平均執行時間，並且在超過預估時間後 build 也沒有發出過訊息，此時就認為 build 處於掛起狀態。TeamCity 會把已經執行過的 build 時間取平均值，從而估算出平均執行時間。當我們訂閱通知時 TeamCity 系統的通知時，可以把 掛起作為一個條件。這樣當掛起發生時我們就會收到通知。

Allow Triggering Personal Builds

這個功能允許使用者使用未提交到程式碼庫的程式碼做build，但是需要開發工具的支援。

Enable Status Widget

啟用狀態部件,這個選項讓我們可以獲得最後一次 build 的資訊，而不需要要使用認證資訊。需要注意的是，除了最後一次 build 的資訊，我們其實還可以獲得任何一次 build 的資訊。但是僅限於獲得 success/failure/internal error/cancelled 這幾種資訊。
我們可以透過不同的方式來獲得資訊，比如 HTML status widget 和 REST API。
下面我們看一下如何把 Build 資訊嵌入到您的網頁上。
先啟用 “enable status widget”:

建立一個 html 網頁，在 head 中加入：

在 body 中加入：

請用您的 TeamCity 伺服器地址更換上面字串中的佔位符，並且用有意義的 Build configuration ID 替換 xxx。然後在瀏覽器中開啟看看：

Limit Number of Simultaneously Running Builds

設定一個 build 可以同時執行的最大數。
主要是防止所有的 build agent 同時被一個 build 全部用光。