經過 20 天的練習,我們已經大致掌握了 TeamCity 的基本功能,剛好是一個很好的機會來回顧一下這一段時間我們學習到的觀念、流程、動作以及接觸到的技術名詞。讀者可以透過這份技術名詞清單來複習一下目前用過的 TeamCity 功能,為接下來的 10 天做準備。
如同之前提到的,TeamCity 是一個 Server(+Database)+ Agent 的組合,了解 Server 及 Agent 各自的責任、分工及合作模式,會有助於我們了解 TeamCity 整體運作流程。我們以下面這張運行週期流程圖來說明:
複習完 TeamCity 的工作流程後,我們來詳細解釋以上流程裡提到的技術名詞。
在 TeamCity 的整體架構裡,主機(Server)本身並不會執行建置或測試的工作。其工作是去監控所有連線到的建置代理,依照建置代理的環境(也可以把環境類比成能力)分配序列(Queue)裡的建置工作並回報結果。所有建置結果的資訊(包括建置歷史以及除了 Artifact 和 Log 外所有跟建置有關的資料)、程式碼儲存庫裡的變更、建置代理、建置序列、使用者帳號及權限等,都是存在資料庫裡。
在這邊額外提一下,雖然把主機、資料庫和建置代理都安裝在一台電腦上是可行的,在這份系列教學文裡也是這麼做,但這通常僅是在測試情境這樣用。在 Production 環境上,還是建議把這 3 種元件都分別安裝在不同的機器上,可以大大增進整體效能,也能提升可用性、降低單點故障的風險。
建置代理是實際執行建置任務的程式,它需要在 TeamCity 主機之外獨立安裝和設定。為了測試專案是否能在不同組合下成功建置,我們通常會將建置代理安裝在不同平台、不同作業系統、搭配不同運行環境以取得最多的測試面向,讓開發者能夠即早發現有問題的來源、開發更可靠的軟體。
在 TeamCity 上的專案意思指的是一個軟體專案或特定的軟體發行版本。每個專案都可以包含多個建置設定。
一組定義建置程序的設定組合,這些設定包括版本儲存庫源頭、建置步驟、觸發器…等。
簡單來說就是版本控制設定的集合(來源位置、帳號、密碼、提取模式等設定),TeamCity 會用這些資訊與版本管理系統溝通來監看變更並用這個源頭來建立建置任務。
實際會被執行的任務。每一個建置步驟會由一個建置執行器以特定的建置工具(比方說 Ant、Gradle、MSBuild)、測試框架(比方說 NUnit) 或程式碼分析引擎運行。因此在一個建置任務裡,您可以設計一系列的步驟來執行測試、取得覆蓋率報告、建置您的專案…等。
觸發器就是在某個事件發生時會觸發建置任務的規則。比方說,當 VCS 觸發器發現版本儲存庫裡有新的變更時,就會自動觸發新的建置任務。TeamCity 支援數種觸發器,像是我們也可以使用計時器觸發器(Timer Trigger)來定期的執行特定建置任務。
所謂變更就是任何您在原始碼裡做的任何改變。每當我們完成一件工作,把程式碼提交到版本管理系統但還沒有被 TeamCity 建立一個建置任務時,這樣就算是有一個新的變更,TeamCity 發現有新的變更後,就會將它依照建置設定排進待完成的任務清單裡。
在 TeamCity 裡提到建置可以指兩件事:編譯一個應用程式的實際過程以及最後產生出的結果本身。當一個建置工作被觸發後,它就會被放進建置序列等待閒置的建置代理拿去執行。而當建置工作完成時,建置代理會把建置成品送回主機。
一個已被觸發、正在等待執行的建置清單。TeamCity 會將這些工作分配給符合運行條件且閒置的建置代理執行。要注意一點,這些建置工作都是在建置代理可以開始工作的當下才被指派,並不是在序列裡就被預先指派的。
建置工作完成後產生的檔案,比方說,Installer、WAR 檔、報表、Log,這些檔案我們統稱為「成品」。TeamCity 會將這些檔案儲存起來,我們可以依照需求下載使用。
看完這份技術名詞清單,相信您對 TeamCity、建置流程等環境有更深入的認識,應該也能釐清一些誤解。每一個名詞筆者都有附上英文原文方便對照,希望能幫助您在看原文文件時可以更容易對應。