持續整合 - 快速指南

持續整合 - 概述

持續整合 (Continuous Integration) 最初於 2000 年隨著名為 **Cruise Control** 的軟體的出現而被引入。多年來，持續整合已成為任何軟體組織中的關鍵實踐。這是一種開發實踐，它要求開發團隊確保對軟體程式的每次程式碼更改都進行構建和後續測試。這個概念旨在解決在構建生命週期中後期發現問題的難題。持續整合的引入是為了確保程式碼更改和構建不會孤立地進行，而不是讓開發人員孤立地工作且整合不足。

為什麼要持續整合？

持續整合已成為任何軟體開發流程中非常重要的組成部分。持續整合流程幫助軟體開發團隊解答以下問題。

所有軟體元件是否按預期協同工作？– 有時系統會變得非常複雜，每個元件都有多個介面。在這種情況下，確保所有軟體元件都能無縫協同工作始終至關重要。
程式碼是否過於複雜而無法整合？– 如果持續整合流程持續失敗，則可能表示程式碼過於複雜。這可能是一個訊號，表明需要應用適當的設計模式來使程式碼更簡潔、更易於維護。
程式碼是否符合既定的編碼標準？– 大多數測試用例始終會檢查程式碼是否符合正確的編碼標準。透過在自動構建後進行自動測試，這是一個檢查程式碼是否滿足所有所需編碼標準的好時機。
自動化測試涵蓋了多少程式碼？– 如果測試用例沒有涵蓋程式碼的所需功能，那麼測試程式碼毫無意義。因此，始終應該確保編寫的測試用例涵蓋應用程式的所有關鍵場景。
最新更改後所有測試是否都成功？– 如果測試失敗，則沒有必要繼續部署程式碼，因此這是一個檢查程式碼是否準備好進入部署階段的好時機。

工作流程

下圖快速展示了任何軟體開發專案中整個持續整合工作流程的工作方式。我們將在後續章節中詳細介紹這一點。

因此，根據上述工作流程，持續整合流程通常的工作方式如下。

首先，開發人員將程式碼提交到版本控制儲存庫。同時，整合構建機器上的持續整合伺服器輪詢原始碼儲存庫以查詢更改（例如，每隔幾分鐘）。
提交發生後不久，持續整合伺服器檢測到版本控制儲存庫中發生了更改，因此持續整合伺服器從儲存庫檢索程式碼的最新副本，然後執行構建指令碼，該指令碼整合軟體。
持續整合伺服器透過向指定的專案成員傳送電子郵件的方式生成反饋。
如果該專案的構建透過，則執行單元測試。如果測試成功，則程式碼已準備好部署到暫存伺服器或生產伺服器。
持續整合伺服器繼續輪詢版本控制儲存庫中的更改，整個過程重複進行。

持續整合 - 軟體

軟體部分是任何持續整合流程中最重要的方面。本章重點介紹整個持續整合流程所需的軟體。

原始碼儲存庫

原始碼儲存庫用於維護所有原始碼及其所有更改。兩種最流行的原始碼儲存庫管理工具是 Subversion 和 Git，其中 Git 是最近最流行的系統。我們現在來看一下如何在系統上安裝 Git。

系統要求

記憶體	2 GB RAM（推薦）
磁碟空間	安裝需要 200 MB HDD。需要額外的儲存空間來儲存專案原始碼，這取決於新增的原始碼量。
作業系統版本	可在 Windows、Ubuntu/Debian、Red Hat/Fedora/CentOS、Mac OS X 上安裝。

安裝 Git

**步驟 1** - Git 的官方網站是 https://git-scm.tw/。單擊連結後，您將進入 Git 官方網站的主頁，如下面的螢幕截圖所示。

**步驟 2** - 要下載 Git，只需向下滾動螢幕，轉到“下載”部分並單擊“下載”。

**步驟 3** - 單擊 Windows 連結，Git 的下載將自動開始。

**步驟 4** - 單擊下載的 Git .exe 檔案。在本例中，我們使用的是 Git-2.6.1-64-bit.exe 檔案。單擊下一個螢幕上出現的“執行”。

**步驟 5** - 單擊以下螢幕上出現的“下一步”按鈕。

**步驟 6** - 單擊以下螢幕上的“下一步”以接受通用許可協議。

**步驟 7** - 選擇 Git 安裝的位置。

**步驟 8** - 單擊“下一步”以接受需要安裝的預設元件。

**步驟 9** - 選擇“從 Windows 命令提示符使用 Git”選項，因為我們將從 Windows 使用 Git。

**步驟 10** - 在以下螢幕中，接受“簽出 Windows 樣式，提交 Unix 樣式換行符”的預設設定，然後單擊“下一步”。

**步驟 11** - 在以下螢幕中，選擇“使用 Windows 預設控制檯視窗”選項，因為我們使用 Windows 作為 Git 的安裝系統。

安裝現在將開始，安裝完成後，可以按照後續步驟配置 Git。

配置 Git

安裝 Git 後，需要執行配置步驟才能對 Git 進行初始配置。

首先需要做的就是在 Git 中配置身份，然後配置使用者名稱和電子郵件。這很重要，因為每次 **Git 提交** 都使用此資訊，並且它不可變地嵌入到您開始建立的提交中。可以透過開啟命令提示符然後輸入以下命令來執行此操作：

git config –global user.name “Username”
git config –global user.email “emailid”

以下螢幕截圖是一個示例，以便更好地理解。

這些命令實際上會相應地更改 Git 的配置檔案。為確保您的設定已生效，您可以透過發出以下命令列出 Git 配置檔案的設定。

git config --list

以下螢幕截圖顯示了輸出示例。

持續整合伺服器

整個持續整合管道所需的下一個關鍵軟體是持續整合軟體本身。以下是業界最常用的持續整合軟體：

**Jenkins** - 這是一款開源持續整合軟體，許多開發社群都在使用它。
**Jet Brains TeamCity** - 這是市面上最流行的商業持續整合軟體之一，大多數公司都將其用於持續整合需求。
**Atlassian Bamboo** - 這是 Atlassian Pvt. Ltd. 公司提供的另一款流行的持續整合軟體。

上述所有軟體都使用相同的持續整合模型。在本教程中，我們將以 **Jetbrains TeamCity** 作為持續整合伺服器。

安裝 TeamCity

以下是您在計算機上安裝 Jet Brains TeamCity 的步驟和系統要求。

系統要求

記憶體	4 GB RAM（推薦）
磁碟空間	安裝需要 1 GB HDD。需要額外的儲存空間來儲存每個專案的構建工作區。
作業系統版本	可在 Windows、Linux、Mac OS X 上安裝。

安裝

**步驟 1** - TeamCity 的官方網站是 https://www.jetbrains.com/teamcity/。單擊給定的連結後，您將進入 TeamCity 官方網站的主頁，如下面的螢幕截圖所示。您可以瀏覽頁面以下載 TeamCity 的所需軟體。

**步驟 2** - 下載的 .exe 用於執行 **TeamCity-9.1.6.exe**。雙擊可執行檔案，然後單擊下一個彈出螢幕中的“執行”。

**步驟 3** - 單擊“下一步”以開始設定。

**步驟 4** - 單擊“我同意”按鈕以接受許可協議並繼續安裝。

**步驟 5** - 選擇安裝位置，然後單擊“下一步”。

**步驟 6** - 選擇安裝的預設元件，然後單擊“下一步”。

這將啟動安裝過程。完成後，將進行配置過程。

**步驟 7** - 選擇伺服器執行的埠號。最好使用不同的埠，例如 **8080**。

**步驟 8** - 接下來，它會詢問 TeamCity 需要以哪個帳戶執行。選擇 SYSTEM 帳戶，然後單擊“下一步”。

**步驟 9** - 接下來，它會詢問需要啟動哪些服務。接受預設服務，然後單擊“下一步”。

配置 TeamCity

安裝完成後，下一步是配置 TeamCity。可以透過在瀏覽器中瀏覽以下 URL 來開啟此軟體：

http://locahost:8080

**步驟 1** - 第一步是提供 TeamCity 將執行的構建的位置。選擇所需的位置，然後單擊“繼續”按鈕。

**步驟 2** - 下一步是指定用於儲存所有 TeamCity 工件的資料庫。在本教程中，可以選擇 **內部 (HSQLDB)**，這是在使用產品進行測試時最適合的內部資料庫。

然後，TeamCity 將處理所有必要的步驟以使其啟動並執行。

**步驟 3** - 接下來，您將被要求接受許可協議。接受並單擊“繼續”。

**步驟 4** - 您需要建立一個管理員帳戶，該帳戶將用於登入 TeamCity 軟體。輸入所需詳細資訊，然後單擊“建立帳戶”按鈕。

您現在將登入 TeamCity。

構建工具

構建工具是一種確保程式以特定方式構建的工具。該工具通常會執行一系列任務，這些任務是程式以正確方式構建所必需的。由於在我們的示例中，我們將研究一個.Net程式，因此我們將MSBuild視為構建工具。MSBuild工具檢視包含用於構建專案的任務列表的構建檔案。讓我們來看一個Web配置專案的典型構建檔案。

以下是需要考慮的構建檔案的主要部分。

IIS設定

以下設定用於確定埠號、Web伺服器上的路徑以及應用程式執行時所需的認證型別。這些是重要的設定，當我們稍後在教程中學習如何執行部署時，將透過MSBuild命令更改這些設定。

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>https://:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

這用於告訴構建伺服器執行此專案所需的所有依賴二進位制檔案。

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

.Net Framework版本

TargetFrameworkVersion 指明專案執行所需的.Net版本。這是絕對必要的，因為如果構建伺服器沒有安裝此版本，則構建將失敗。

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

部署環境 – Amazon

在本教程中，我們將確保我們的持續整合伺服器能夠將我們的應用程式部署到Amazon。為此，我們需要確保以下工件已到位。

資料庫伺服器

執行以下步驟以確保在Amazon中為部署準備資料庫伺服器。

步驟1 − 轉到Amazon控制檯 − https://aws.amazon.com/console/.

使用您的憑據登入。請注意，您可以申請Amazon網站上的免費ID，這將允許您獲得免費層級，使您可以免費使用Amazon上的一些資源。

步驟2 − 轉到RDS部分以建立您的資料庫。

步驟3 − 在下一個彈出的螢幕中點選“例項”。

步驟4 − 在下一個彈出的螢幕中點選啟動資料庫選項。

步驟5 − 選擇SQL Server選項卡，然後為SQL Server Express選擇“選擇”選項。

步驟6 − 確保輸入以下詳細資訊以確認您正在使用Amazon提供的免費層級的資料庫。

步驟7 − 所有欄位都填寫完畢後，點選“下一步”按鈕。

步驟8 − 在下一個彈出的螢幕中，接受所有預設設定，然後點選啟動資料庫例項。

步驟9 − 然後您將看到一個螢幕，顯示資料庫正在成功啟動。在同一頁面上，將有一個按鈕用於檢視資料庫例項。點選連結檢視您的資料庫例項正在設定。

一段時間後，上述螢幕的狀態將更改為通知資料庫例項已成功建立。

Web伺服器

下一步是在Amazon上建立您的Web伺服器，該伺服器將託管Web應用程式。這可以透過按照後續步驟來完成。

步驟1 − 轉到Amazon控制檯 − https://aws.amazon.com/console/.

使用您的憑據登入。請注意，您可以申請Amazon網站上的免費ID，這將允許您獲得免費層級，使您可以免費使用Amazon上的一些資源。

步驟2 − 轉到EC2部分以建立您的Web伺服器。

步驟3 − 在下一個螢幕中，點選“啟動例項”。

步驟4 − 點選Windows – Microsoft Windows Server 2010 R2 Base。

步驟5 − 選擇t2.micro選項，這是免費層級的一部分。點選下一步：配置例項詳細資訊。

步驟6 − 接受下一個彈出的螢幕上的預設設定，然後選擇下一步：新增儲存選項。

步驟7 − 接受下一個螢幕上的預設設定，然後選擇下一步：標記例項選項。

步驟8 − 接受下一個螢幕上的預設設定，然後選擇下一步：配置安全組選項。

步驟9 − 接受下一個螢幕上的預設設定，然後選擇檢視並啟動選項。

步驟10 − 在下一個彈出的螢幕中點選“啟動”。

步驟11 − 在下一個彈出的螢幕中，系統將提示您建立一個金鑰對。這將用於稍後登入伺服器。只需建立金鑰對並點選啟動例項。

例項現在將在Amazon中設定。

持續整合 - 降低風險

專案可能會出現問題。透過有效地實踐CI，您可以瞭解在開發過程中的每一步都會發生什麼，而不是在專案進入開發週期後期才發現。CI幫助您在問題發生時識別和減輕風險，使您可以根據具體證據更容易地評估和報告專案的健康狀況。

本節將重點關注使用持續整合可以避免的風險。

任何專案都需要管理許多風險。透過在開發生命週期的早期消除風險，這些風險在系統實際上線時發展成問題的可能性就會降低。

風險1 – 缺乏可部署的軟體

“在我的機器上執行正常，但在其他機器上卻不行” – 這可能是任何軟體組織中最常見的短語之一。由於每天對軟體構建進行的更改數量眾多，有時人們對軟體構建是否真正有效缺乏信心。此問題具有以下三種副作用。

對我們是否能夠構建軟體缺乏或沒有信心。
在內部（即測試團隊）或外部（即客戶）交付軟體之前，整合階段漫長，在此期間沒有其他工作完成。
無法生成和重現可測試的構建。

解決方案

消除IDE和構建過程之間的緊密耦合。使用單獨的機器專門用於整合軟體。確保構建軟體所需的一切都包含在版本控制儲存庫中。最後，建立一個持續整合系統。

持續整合伺服器可以監視版本控制儲存庫中的更改，並在檢測到對儲存庫的更改時執行專案構建指令碼。持續整合系統的能力可以增強，包括讓構建執行測試、執行檢查和在開發和測試環境中部署軟體；這樣您將始終擁有一個可工作的軟體。

“無法與資料庫同步” – 有時開發人員無法在開發過程中快速重新建立資料庫，因此難以進行更改。這通常是由於資料庫團隊和開發團隊之間的分離造成的。每個團隊都將專注於自己的職責，彼此之間幾乎沒有合作。此問題具有以下三種副作用：

害怕更改或重構資料庫或原始碼。
難以使用不同的測試資料集填充資料庫。
難以維護開發和測試環境（例如，開發、整合、QA和測試）。

解決方案

解決上述問題的辦法是確保將所有資料庫工件放入版本控制儲存庫中。這意味著重新建立資料庫模式和資料所需的一切：資料庫建立指令碼、資料操作指令碼、儲存過程、觸發器以及任何其他資料庫資產都是必需的。

透過刪除和重新建立資料庫和表，從構建指令碼中重新構建資料庫和資料。接下來，應用儲存過程和觸發器，最後插入測試資料。

測試（和檢查）您的資料庫。通常，您將使用元件測試來測試資料庫和資料。在某些情況下，您需要編寫特定於資料庫的測試。

風險2 – 在生命週期後期發現缺陷

由於多個開發人員頻繁對原始碼進行許多更改，因此程式碼中始終可能引入缺陷，這些缺陷可能只能在後期階段檢測到。在這種情況下，這可能會造成很大的影響，因為在軟體中檢測到的缺陷越晚，消除缺陷的成本就越高。

解決方案

迴歸測試 − 這是任何軟體開發週期中最重要的方面，反覆測試。如果對軟體程式碼進行任何重大更改，則絕對必須確保執行所有測試。這可以透過持續整合伺服器實現自動化。

測試覆蓋率 − 如果測試用例沒有涵蓋程式碼的全部功能，則測試毫無意義。務必確保建立的用於測試應用程式的測試用例是完整的，並且所有程式碼路徑都經過測試。

例如，如果您有一個需要測試的登入螢幕，您不能只進行成功登入的測試用例。您需要有一個負面測試用例，其中使用者輸入不同的使用者名稱和密碼組合，然後需要檢視在這種情況下會發生什麼。

風險3 – 缺乏專案可見性

手動溝通機制需要大量的協調才能確保及時地將專案資訊傳播給合適的人員。向旁邊的開發人員傾斜並讓他們知道最新的構建在共享驅動器上是相當有效的，但它並不具有很好的可擴充套件性。

如果其他開發者也需要這些資訊，而他們正在休息或暫時無法聯絡怎麼辦？如果伺服器宕機，你會如何收到通知？有些人認為可以透過手動傳送電子郵件來降低這種風險。但是，這並不能保證資訊在正確的時間傳達給正確的人，因為你可能會意外地漏掉相關人員，而且有些人可能當時無法訪問他們的電子郵件。

解決方案

這個問題的解決方案仍然是持續整合伺服器。所有CI伺服器都具有在構建失敗時自動觸發電子郵件的功能。透過向所有關鍵利益相關者自動傳送通知，還可以確保每個人都瞭解軟體的當前狀態。

風險4 – 低質量軟體

有缺陷，也有潛在缺陷。當你的軟體設計不完善，或者不符合專案標準，或者難以維護時，你可能會遇到潛在缺陷。有時人們將其稱為程式碼或設計異味——“暗示可能存在問題的症狀”。

有些人認為低質量軟體僅僅是推遲的專案成本（交付後）。它可以是推遲的專案成本，但它也會在將軟體交付給使用者之前導致許多其他問題。過於複雜的程式碼、不遵循架構的程式碼和重複的程式碼——通常都會導致軟體缺陷。在這些程式碼和設計異味演變成缺陷之前發現它們可以節省時間和金錢，並可以提高軟體質量。

解決方案

有一些軟體元件可以執行程式碼質量檢查，這些元件可以與CI軟體整合。這可以在程式碼構建後執行，以確保程式碼實際符合正確的編碼指南。

持續整合 - 版本控制

版本控制系統，也稱為原始碼控制、原始碼管理系統或修訂控制系統，是一種儲存多個檔案版本的方法，這樣當你修改檔案時，你仍然可以訪問以前的修訂版本。

第一個流行的版本控制系統是一個專有的UNIX工具，稱為SCCS（原始碼控制系統），它可以追溯到20世紀70年代。它後來被RCS（修訂控制系統）取代，之後又被CVS（併發版本系統）取代。

現在最常用的版本控制系統是Subversion和Git。讓我們首先看看為什麼我們需要使用版本控制系統，然後看看如何將我們的原始碼放入Git原始碼儲存庫系統。

版本控制系統的用途

我們更傾向於使用“版本控制”而不是“原始碼控制”的一個原因是，版本控制不僅僅用於原始碼。與建立軟體相關的每一個工件都應該在版本控制之下。

開發者應該將其用於原始碼 − 預設情況下，所有原始碼都需要儲存在版本控制系統中

相關工件 − 每個系統都將擁有與原始碼相關的工件，例如資料庫指令碼、構建和部署指令碼、文件、庫以及應用程式的配置檔案、編譯器和工具集合等等。所有這些都補充了整個開發和部署過程，也需要儲存在版本控制系統中。

透過將應用程式的所有資訊儲存在原始碼控制中，可以更容易地重新建立應用程式執行的測試和生產環境。這應該包括應用程式軟體棧的配置資訊以及構成環境的作業系統、DNS區域檔案、防火牆配置等等。

至少，你需要所有可以重新建立應用程式二進位制檔案及其執行環境所需的內容。目標是將專案生命週期中任何時候可能發生變化的所有內容以受控的方式儲存起來。這允許你在專案的任何時間點恢復整個系統的精確快照，從開發環境到生產環境。

甚至將開發團隊開發環境的配置檔案儲存在版本控制中也很有幫助，因為它使團隊中的每個人都可以輕鬆地使用相同的設定。分析師應該儲存需求文件。測試人員應該將他們的測試指令碼和流程儲存在版本控制中。專案經理應該將他們的釋出計劃、進度表和風險日誌儲存在這裡。

簡而言之，團隊的每個成員都應該將與專案相關的任何文件或檔案儲存在版本控制中。

使用Git進行原始碼版本控制系統

本節將重點介紹如何使用Git作為版本控制系統。它將重點介紹如何將程式碼上傳到版本控制系統以及如何管理其中的更改。

我們的演示應用程式

在本教程中，我們將研究一個簡單的Web ASP.Net應用程式，該應用程式將用於整個持續整合過程。我們不需要關注此練習的整個程式碼細節，只需概述專案的功能就足以理解整個持續整合過程。這個.Net應用程式是使用Visual Studio整合開發環境構建的。

下面的螢幕截圖是Visual Studio環境中解決方案的結構。這是一個非常簡單的Web應用程式，其主要程式碼位於Demo.aspx檔案中。

Demo.aspx檔案中的程式碼如下所示：

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

程式碼非常簡單，只需將字串“持續整合”輸出到瀏覽器。

當你在Google Chrome中執行專案時，輸出將如下圖所示。

將原始碼移動到Git

我們將展示如何透過命令列介面將原始碼移動到Git，以便終端使用者更清楚地瞭解如何使用Git。

步驟1 − 初始化Git儲存庫。轉到命令提示符，轉到你的專案資料夾，然後發出命令git init。此命令將把必要的Git檔案新增到專案資料夾中，以便Git在需要將其上傳到儲存庫時能夠識別它。

步驟2 − 新增需要新增到Git儲存庫的檔案。這可以透過發出git add命令來完成。點選項告訴Git需要將專案資料夾中的所有檔案新增到Git儲存庫。

步驟3 − 最後一步是將專案檔案提交到Git儲存庫。此步驟是確保所有檔案現在都是Git的一部分所必需的。要發出的命令在下面的螢幕截圖中給出。–m選項用於向檔案的上傳提供註釋。

你的解決方案現在可以在Git中使用了。

持續整合 - 功能

以下是持續整合的一些主要功能或實踐。

維護單個原始碼儲存庫 − 所有原始碼都維護在一個儲存庫中。這避免了原始碼分散在多個位置。諸如Subversion和Git之類的工具是維護原始碼最流行的工具。
自動化構建 − 軟體的構建應該以可以自動化的方式進行。如果需要執行多個步驟，則構建工具需要能夠執行此操作。對於.Net，MSBuild是預設的構建工具，對於基於Java的應用程式，你擁有諸如Maven和Grunt之類的工具。
使你的構建可自測 − 構建應該是可測試的。構建直接發生後，應該執行測試用例以確保可以針對軟體的各種功能進行測試。
每次提交都應該在整合機器上構建 − 整合機器是構建伺服器，應該確保構建在此機器上執行。這意味著所有依賴元件都應該存在於持續整合伺服器上。
保持構建速度快 − 構建應該在幾分鐘內完成。構建不應該花費數小時才能完成，因為這意味著構建步驟配置不正確。
在生產環境的克隆中進行測試 − 構建環境應該與生產環境的性質接近。如果這些環境之間存在巨大差異，則可能會出現構建在生產環境中失敗而構建伺服器上透過的情況。
每個人都可以看到正在發生的事情 − 構建、測試和部署的整個過程應該對所有人可見。
自動化部署 − 持續整合導致持續部署。絕對有必要確保構建易於部署到登臺環境或生產環境。

持續整合 - 需求

以下是持續整合最重要的需求列表。

定期簽入 − 持續整合正常工作的最重要實踐是頻繁簽入原始碼儲存庫的主幹或主線。程式碼的簽入應該每天至少進行幾次。定期簽入帶來了許多其他好處。它使更改更小，因此不太可能破壞構建。這意味著當在任何後續構建中出現錯誤時，可以知道軟體的最新版本。

它還有助於更嚴格地進行程式碼重構並堅持保留行為的小更改。它有助於確保更改大量檔案的可能性較小與其他人的工作衝突。它允許開發人員更具探索性，嘗試想法並透過恢復到上次提交的版本來丟棄它們。
建立一個全面的自動化測試套件 − 如果沒有全面的自動化測試套件，透過構建僅意味著應用程式可以編譯和組裝。雖然對於一些團隊來說，這是一個巨大的進步，但擁有某種程度的自動化測試以增強對應用程式實際工作的信心至關重要。

通常，在持續整合中進行3種類型的測試，即單元測試、元件測試和驗收測試。

單元測試旨在單獨測試應用程式的小部分行為。它們通常可以在不啟動整個應用程式的情況下執行。它們不會訪問資料庫（如果你的應用程式有資料庫）、檔案系統或網路。它們不需要你的應用程式在類似生產的環境中執行。單元測試應該執行得非常快——即使對於大型應用程式，你的整個套件也應該能夠在十分鐘內執行。

元件測試測試應用程式的幾個元件的行為。與單元測試一樣，它們並不總是需要啟動整個應用程式。但是，它們可能會訪問資料庫、檔案系統或其他系統（這些系統可能是存根的）。元件測試通常需要更長時間才能執行。
保持構建和測試過程簡短 − 如果構建程式碼和執行單元測試花費的時間太長，你將遇到以下問題。
- 人們將停止進行完整的構建，而會在簽入前執行測試。你將開始出現更多失敗的構建。
- 持續整合過程耗時很長，以至於在你再次執行構建之前可能已經進行了多次提交，因此你無法知道哪個檢入破壞了構建。
- 人們會減少檢入頻率，因為他們必須等待很長時間才能完成軟體構建和測試執行。
不要在構建中斷時檢入 − 持續整合的最大錯誤是在構建中斷時檢入。如果構建中斷，則相關的開發人員將等待修復它。他們儘快找出中斷的原因並進行修復。如果我們採用這種策略，我們將始終處於最佳位置來找出導致中斷的原因並立即修復它。

如果我們的同事進行了檢入並因此破壞了構建，那麼為了最大限度地修復它，他們需要清晰地解決這個問題。當違反此規則時，構建修復的時間不可避免地會長得多。人們習慣了看到構建中斷，很快就會出現構建一直中斷的情況。
在提交之前始終在本地執行所有提交測試 − 始終確保首先在本地機器上執行為應用程式設計的測試，然後再在 CI 伺服器上執行它們。這樣做是為了確保編寫了正確的測試用例，如果 CI 過程中出現任何故障，則是因為測試結果失敗。
對因您的更改而導致的所有中斷負責 − 如果您提交了更改並且您編寫的所有測試都通過了，但其他測試失敗了，則構建仍然中斷。這通常意味著您在應用程式中引入了迴歸錯誤。這是您的責任——因為您進行了更改——修復因您的更改而導致的所有未透過的測試。在 CI 的上下文中，這似乎顯而易見，但實際上在許多專案中這並非常見做法。

持續整合 - 構建解決方案

各種程式語言都提供各種構建工具。一些最流行的構建工具包括用於 Java 的 Ant 和用於 .NET 的 MSBuild。使用專門為構建軟體設計的指令碼工具，而不是自定義的 shell 或批處理指令碼集，是開發一致、可重複構建解決方案的最有效方法。

那麼，我們首先為什麼需要構建過程呢？對於初學者來說，對於持續整合伺服器，構建過程應該易於使用，並且應該無縫實施。

讓我們來看一個 .Net 構建檔案可能是什麼樣子的簡單示例：

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

關於上述程式碼，需要注意以下幾個方面：

使用名為 Build 的名稱指定目標。其中，目標是在構建過程中需要執行的一系列邏輯步驟。您可以擁有多個目標，並且目標之間存在依賴關係。
在我們的目標中，我們保留一個選項訊息，該訊息將在構建過程啟動時顯示。
MSBuild 任務用於指定需要構建哪個 .Net 專案。

以上示例是一個非常簡單的構建檔案的案例。在持續整合中，確保此檔案保持最新狀態，以確保整個構建過程無縫進行。

在 .Net 中構建解決方案

.Net 的預設構建工具是 MSBuild，它隨 .Net framework 一起提供。根據您系統上的框架，您將擁有相關的 MSbuild 版本。例如，如果您在預設位置安裝了 .Net framework，則會在以下位置找到MSBuild.exe檔案：

C:\Windows\Microsoft.NET\Framework\v4.0.30319

讓我們看看如何構建我們的示例專案。假設我們的示例專案位於名為C:\Demo\Simple的資料夾中。

為了使用 MSBuild 構建上述解決方案，我們需要開啟命令提示符並使用 MSBuild 選項，如下面的程式所示。

msbuild C:\Demo\Simple\Simple.csproj

在上面的示例中，csproj是特定於 .Net 的專案檔案。csproj 檔案包含所有相關資訊，以確保軟體正確構建所需的資訊存在。以下是 MSBuild 命令輸出的螢幕截圖。

只要構建成功並且沒有錯誤，您就不必擔心輸出警告。

持續整合 - 構建指令碼

現在讓我們來看一下 MSBuild 檔案的某些方面，看看它們是什麼意思。從持續集成周期的角度來看，瞭解這些方面非常重要。

構建指令碼用於構建解決方案，該解決方案將成為整個持續集成周期的一部分。讓我們看一下在我們的示例解決方案中作為 Visual Studio 的一部分建立的通用構建指令碼。即使對於簡單的解決方案，構建指令碼也相當大，因此我們將介紹其中最重要的部分。預設情況下，構建指令碼將儲存在一個與 Visual Studio 中主解決方案同名的檔案中。因此，在我們的案例中，如果您開啟Simple.csproj檔案，您將看到將用於構建解決方案的所有設定。

對所用 MSBuild 版本的依賴性 − 以下設定將使用安裝在 CI 伺服器上的 MSBuild 檔案。

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == 
   ''">10.0</VisualStudioVersion>

<VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" />

<Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

正確構建解決方案需要哪些檔案 –ItemGroup 標記將包含專案成功構建所需的所有必要的 .Net 檔案。這些檔案需要相應地駐留在構建伺服器上。

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

要使用的 Web 伺服器設定是什麼 − 當我們討論持續部署主題時，您將看到如何使用 MSBuild 覆蓋這些設定並將其部署到我們選擇的伺服器。

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

CI - 在伺服器上構建

下一步是確保解決方案在構建伺服器上構建。第一部分是一個手動步驟，因為在使用持續整合工具之前，我們首先必須確保構建以與客戶端機器上相同的方式在構建伺服器上執行。為此，我們必須執行以下步驟：

步驟 1 − 將整個解決方案檔案複製到伺服器。我們建立了一個 Amazon 例項伺服器，該伺服器將用作我們的構建伺服器。因此，將整個.Net解決方案手動複製到伺服器上。

步驟 2 − 確保伺服器上存在框架。如果您在客戶端機器上使用 .Net framework 4.0 編譯了應用程式，則必須確保它也安裝在伺服器機器上。因此，請轉到伺服器上的C:\Windows\Microsoft.NET\Framework位置，並確保存在所需的框架。

步驟 3 − 現在讓我們在伺服器上執行 MSBuild 並看看會發生什麼。

好的，看起來我們遇到錯誤了。持續整合中有一個重要的教訓，那就是您需要確保構建在構建伺服器上有效。為此，您需要確保在構建伺服器上安裝所有先決條件軟體。

對於 .Net，我們需要安裝一個名為Visual Studio Redistributable package的元件。此軟體包包含 .Net 應用程式在伺服器上構建所需的所有必要檔案。因此，讓我們在構建伺服器上執行以下安裝步驟。

步驟 4 − 雙擊可執行檔案以啟動安裝。

步驟 5 − 在下一步中，同意許可條款，然後單擊安裝。

步驟 6 − 現在執行 MSBuild 時，我們需要確保在呼叫 MSBuild 時包含一個附加引數 –p:VisualStudioversion = 12.0。這確保 MSBuild 引用在前面步驟中下載的檔案。

現在我們可以看到解決方案已正確構建，我們也知道我們的基線專案在伺服器上可以正確構建。

CI - 簽入原始碼

下一個關鍵方面是確保我們的基線程式碼已檢入我們的原始碼儲存庫管理伺服器 Git。為此，我們需要遵循以下步驟。

步驟 1 − 初始化儲存庫，以便可以將其上傳到 Git。這是使用git init 命令完成的。因此，您需要轉到您的專案資料夾併發出git init命令。

步驟 2 − 下一步稱為在 Git 中暫存檔案。這將準備專案資料夾中需要新增到 Git 的所有檔案。您可以使用git add命令執行此操作，如下面的螢幕截圖所示。‘.’ 符號用於表示目錄和子目錄中的所有檔案都應包含在提交中。

步驟 3 − 最後一步是將檔案提交到 Git 儲存庫，以便它現在成為一個完整的 Git 儲存庫。

CI - 在 TeamCity 中建立專案

現在我們的原始碼位於 Git 儲存庫中，並且我們所有的初始程式碼都在構建伺服器上執行，現在是時候在我們的持續整合伺服器中建立一個專案了。這可以透過以下步驟完成：

步驟 1 − 登入到 TeamCity 軟體。轉到持續整合伺服器上的 url −https://:8080/login.html。

輸入管理員憑據並登入到伺服器。

步驟 2 − 登入後，您將看到主螢幕。單擊建立專案以啟動新專案。

步驟 3 − 為專案命名，然後單擊建立以啟動專案。在我們的案例中，我們為專案命名為“Demo”，如下面的螢幕截圖所示。

步驟 4 − 下一步是提及專案中將使用的 Git 儲存庫。請記住，在持續整合環境中，CI 伺服器需要從 Git 啟用的儲存庫中獲取程式碼。我們已經在之前的步驟中啟用了我們的專案資料夾作為 Git 啟用的儲存庫。在 TeamCity 中，您需要建立一個 VCS 根。為此，請單擊專案主螢幕中的VCS 根。

步驟 5 − 在接下來出現的螢幕中，單擊建立 VCS 根，如下面的螢幕截圖所示。

步驟 6 − 在接下來出現的螢幕中，執行以下步驟：

將 VCS 型別提及為 Git。
為 VCS 根命名，這可以是任何友好的名稱。我們將其命名為App。
將 Fetch url 指定為C:\Demo\Simple – 這是我們git啟用的儲存庫。
如果向下滾動螢幕，您將看到一個測試連線按鈕。單擊它以確保您可以成功連線到 Git 啟用的儲存庫。

步驟 7 − 單擊建立，您現在將看到您的儲存庫已註冊，如下面的影像所示。

步驟 8 − 下一步是建立一個構建配置，該配置將用於構建專案。轉到 TeamCity 中的專案螢幕→常規設定。單擊建立構建配置。

步驟 9 − 在以下螢幕中，為構建配置命名。在我們的案例中，我們將其命名為DemoBuild，然後單擊建立。

步驟 10 − 在接下來出現的螢幕中，系統將要求您選擇在前面步驟中建立的VCS 儲存庫。因此，選擇名稱“App”並單擊附加。

步驟 11 − 現在在彈出的下一個螢幕中，我們需要配置構建步驟。因此，單擊“手動配置構建步驟”超連結。

步驟 12 − 在下一個構建螢幕中，我們需要輸入以下詳細資訊：

選擇執行程式型別為 MSBuild。
為步驟名稱提供一個可選名稱。
輸入需要構建的檔名。當我們在前面部分指定 MSbuild 時，通常會看到我們提供了Simple.csproj選項。這裡需要指定相同的內容。
選擇 MSBuild 版本為“Microsoft Build Tools 2013”。
選擇MSBuild ToolsVersion為 12.0。
向下滾動頁面以儲存設定。

步驟 13 − 在下一個螢幕中，單擊執行。

您將看到您的應用程式現在正在構建。

您應該看到一個成功的螢幕，這表明您的解決方案構建正常。

您還可以檢視構建日誌以檢視持續整合伺服器完成的所有步驟，如下面的螢幕截圖所示。

持續整合 - 定義任務

現在我們的基礎程式碼已在 Git 中，並且與持續整合伺服器建立了連結，現在是時候見證持續整合的第一步了。這是透過在持續整合伺服器中定義任務（例如觸發器）來完成的，這使得整個持續整合過程儘可能無縫。讓我們更改 Visual Studio 中的程式碼。

步驟 1 − 轉到 Visual Studio 中的Demo.aspx頁面，並更改頁面的標題。

步驟 2 − 如果我們透過git status命令查詢我們的 Git 儲存庫，您實際上會看到Demo.aspx檔案已被修改。

現在，我們需要確保程式碼中的每次更改都應該觸發持續整合伺服器中的構建。為此，我們需要進行以下更改。

步驟 3 − 轉到您的專案儀表板，單擊觸發器部分，然後單擊新增新的觸發器。

步驟 4 − 在出現的下一個螢幕中，選擇VCS 觸發器，這將用於建立一個觸發器，以便在對儲存庫進行簽入時觸發構建。

步驟 5 − 單擊顯示高階選項，並確保選擇了以下螢幕截圖中顯示的選項。

步驟 6 − 單擊儲存。您現在將看到觸發器已成功註冊，如下面的螢幕截圖所示。

步驟 7 − 現在是時候將我們的程式碼簽入 Git 儲存庫並檢視會發生什麼了。因此，讓我們轉到命令提示符併發出git add命令來暫存我們更改的檔案。

步驟 8 − 現在發出git commit命令，它會將更改推送到 Git 儲存庫。

步驟 9 − 如果您現在轉到“專案概述”螢幕，您將看到一個新的構建已被觸發並執行。

如果您看到更改日誌選項卡，您將看到觸發構建的git 註釋。

讓我們再試一次。讓我們對Demo.aspx檔案進行另一個更改。讓我們執行git add命令和git commit命令，並使用以下提交訊息。

您現在將看到 TeamCity 中的專案儀表板會自動觸發構建。

構建將顯示成功訊息。

您現在將看到“第二次提交”訊息，該訊息在更改提交到git 儲存庫時使用。

我們現在已經成功完成了持續整合過程的第一部分。

CI - 構建失敗通知

構建失敗通知是在構建失敗時觸發的事件。每當構建失敗時，都會向所有關鍵人員傳送通知。在這種情況下，首先要做的重要事情是確保花時間處理失敗的構建以確保構建透過。以下步驟用於確保在 TeamCity 中設定構建通知。

以下是設定 TeamCity 中的電子郵件通知的步驟。

步驟 1 − 在 TeamCity 中，轉到您的專案儀表板，單擊右上角的“管理”。然後，您將在左側看到電子郵件通知程式連結。單擊此連結以調出電子郵件的常規設定。

步驟 2 − 下一步是輸入有效的SMTP 伺服器的詳細資訊。Gmail 提供免費的 SMTP 功能，任何人都可以使用。因此，我們可以在出現的下一個螢幕中輸入這些詳細資訊，如下面的螢幕截圖所示。

SMTP 主機 – smtp.gmail.com
SMTP 埠號 – 465
傳送電子郵件來自和 SMTP 登入 – 這應該是有效的 Gmail ID
SMTP 密碼 – 該 Gmail ID 的有效密碼
安全連線 – 將其設定為 SSL

步驟 3 − 單擊測試連線以確保設定正常工作。然後單擊儲存以儲存設定。

步驟 4 − 下一步是為使用者啟用構建通知。第一個任務是建立一個將接收這些構建通知的使用者。轉到您的專案儀表板並選擇使用者選項。

步驟 5 − 建立一個新使用者。輸入所需的使用者名稱和密碼。然後單擊“建立使用者”按鈕，該按鈕位於螢幕底部。

步驟 6 − 現在使用此新的使用者 ID 和密碼登入 TeamCity 系統。

步驟 7 − 登入後，您將看到使用者的常規設定。在“電子郵件通知程式”部分中，單擊“編輯”。

步驟 8 − 在出現的下一個螢幕中，單擊新增新規則。

步驟 9 − 在“新增新規則”中，選擇以下兩個選項，然後單擊“儲存”。

來自所選專案的構建 – 選擇 Demo 專案。
選中“構建失敗”複選框。

透過啟用這兩個選項，現在每當 Demo 專案的構建失敗時，都會向用戶demouser傳送電子郵件通知。

步驟 10 − 現在讓我們觸發一個錯誤構建以檢視其執行情況。在 Visual Studio 中，轉到demo.aspx.cs檔案並新增錯誤的程式碼行。

步驟 11 − 現在透過執行git add和git commit從 Git 中籤入程式碼。

現在在專案儀表板中，構建將自動觸發，您將看到構建失敗，如下面的螢幕截圖所示。

如果您登入demouser的 Gmail ID，您實際上會在其中看到構建失敗通知，如下面的螢幕截圖所示。

CI - 文件和反饋

持續整合的關鍵方面之一是始終檢視構建的執行情況，收集重要的指標，記錄這些結果並透過持續構建生成持續反饋。

實施這些指標的好處是什麼？

程式碼提交不足 − 如果開發人員不經常將程式碼提交到版本控制儲存庫，原因可能是整合構建速度慢。要開始減少構建持續時間，請對整合構建環境進行高階分析以確定瓶頸。

接下來，分析調查結果並確定最合適的改進方法，然後嘗試更改構建過程以減少構建的持續時間。最後，重新評估構建持續時間以確定是否需要進一步改進。
改進測試效能 − 即使在執行良好的 CI 系統中，整合構建時間的很大一部分也將用於執行自動化測試。評估和改進這些測試的效能可以大大減少構建持續時間。
基礎設施問題 − 您可能會發現整合構建速度慢是因為系統基礎設施。也許網路效能緩慢，或者虛擬專用網路連線效能緩慢。

地理位置分散的系統和不可靠的硬體或軟體也可能導致效能問題。調查並改進任何基礎設施資源以減少構建持續時間。

指標

以下是持續整合伺服器中提供的一些指標。

讓我們看看 TeamCity 提供了什麼：

最簡單的指標形式之一是專案儀表板中提供的指標。這裡的關鍵因素是要注意每次構建的持續時間。如果每次構建的持續時間開始不成比例地增加到正在構建的程式碼，那麼這可能是一個問題。因此，這是一個可以獲取的反饋，其原因可能是 CI 伺服器資源不足，可能需要增加伺服器容量。

TeamCity 具有檢視 CI 伺服器是否確實存在任何基礎設施問題的功能。在 TeamCity 的管理員儀表板中，可以單擊磁碟使用情況以檢視每次構建使用了多少磁碟空間。

如果需要更多詳細資訊，則 TeamCity 具有診斷按鈕，該按鈕可以提供有關 CI 伺服器使用的CPU 和記憶體的更多資訊。

構建指標的詳細檢視

如果要檢視一段時間內特定專案的構建的詳細檢視，則可以在專案構建中使用此功能。在專案構建螢幕中，轉到“統計”螢幕，這將提供關於構建效能的各種統計資料和圖表。

持續整合 - 測試

持續整合的關鍵功能之一是確保持續測試包含 CI 伺服器構建的所有程式碼。CI 伺服器執行構建後，必須確保測試用例到位以對所需的程式碼進行測試。每個 CI 伺服器都能夠在CI 套件中執行單元測試用例。在.Net中，單元測試是內置於.Net 框架中的功能，並且可以將其整合到 CI 伺服器中。

本章將介紹如何在.Net中定義測試用例，然後在構建完成後讓我們的 TeamCity 伺服器執行此測試用例。為此，我們首先需要確保為我們的示例專案定義了單元測試。

為此，我們必須以最大的謹慎遵循以下步驟。

步驟 1 − 讓我們向我們的解決方案新增一個新類，這將在我們的單元測試中使用。此類將具有一個名稱變數，該變數將儲存字串“持續整合”。此字串將顯示在網頁上。右鍵單擊 Simple 專案並選擇選單選項新增→類。

步驟 2 − 為類命名為Tutorial.cs，然後單擊螢幕底部的“新增”按鈕。

步驟 3 − 開啟 Tutorial.cs 檔案並在其中新增以下程式碼。此程式碼只是建立一個名為Name的字串，並在建構函式中將名稱賦值為字串值持續整合。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

步驟 4 − 讓我們更改Demo.aspx.cs檔案以使用此新類。使用以下程式碼更新此檔案中的程式碼。因此，此程式碼現在將建立一個上面建立的類的新的例項。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

步驟 5 − 在我們的demo.aspx檔案中，讓我們現在引用tp.Name變數，該變數是在aspx.cs檔案中建立的。

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

為了確保我們的程式碼在進行這些更改後可以正常工作，您可以在 Visual Studio 中執行程式碼。編譯完成後，您應該獲得以下輸出。

步驟 6 − 現在是時候向專案新增單元測試了。右鍵單擊解決方案，然後選擇選單選項新增→新專案。

步驟 7 − 導航到測試，然後在右側選擇單元測試專案。命名為DemoTest，然後單擊確定。

步驟 8 − 在您的Demo Test 專案中，您需要新增對 Simple 專案和必要的測試程式集的引用。右鍵單擊該專案並選擇選單選項新增引用。

步驟 9 − 在出現的下一個螢幕中，轉到“專案”，選擇Simple 引用，然後單擊“確定”。

步驟 10 − 再次單擊新增引用，轉到“程式集”，然後在搜尋框中鍵入Web。然後新增System.Web的引用。

步驟 11 − 在單元測試檔案中，新增以下程式碼。此程式碼將確保 Tutorial 類具有一個字串型別的 name 變數。它還將斷言 Name 應該等於“持續整合”的值。這將是我們的簡單測試用例。

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

步驟 12 − 現在讓我們在 Visual Studio 中執行測試以確保其正常工作。在 Visual Studio 中，選擇選單選項測試 → 執行 → 所有測試。

執行測試後，您將在 Visual Studio 的左側看到測試成功執行。

在 TeamCity 中啟用持續測試 – 現在所有測試用例都已就位，是時候將它們整合到我們的 Team City 伺服器中了。

步驟 13 − 為此，我們需要在專案配置中建立一個構建步驟。轉到您的專案主頁並單擊“編輯配置設定”。

步驟 14 − 然後轉到“構建步驟”→“MS Build”，然後單擊“新增構建步驟”，如下圖所示。

在出現的下一個螢幕中，新增以下值：

將執行程式型別選擇為 Visual Studio Tests。
輸入可選的測試步驟名稱。
將測試引擎型別選擇為VSTest。
將測試引擎版本選擇為VSTest2013。
在測試檔名稱中，提供位置為DemoTest\bin\Debug\DemoTest.dll – 請記住，DemoTest 是包含單元測試的專案的名稱。DemoTest.dll 將由我們的第一個構建步驟生成。
單擊“儲存”，它位於螢幕的末尾。

現在您的專案將有兩個構建步驟。第一個是構建步驟，它將構建您的應用程式程式碼和測試專案。下一個將用於執行您的測試用例。

步驟 15 − 現在是時候將所有程式碼檢入 Git 了，以便可以觸發整個構建過程。唯一的區別是這次您需要從Demo 父資料夾執行git add 和git commit 命令，如下圖所示。

現在，當構建被觸發時，您將看到一個初始輸出，該輸出將表明測試已透過。

步驟 16 − 如果單擊“測試透過”結果並轉到“測試”選項卡，您現在將看到 UnitTest1 已執行並且已透過。

持續整合 - 程式碼檢查

持續程式碼檢查是在實際測試執行之前對您的程式碼進行自動程式碼審查或檢查的過程。檢查和測試軟體之間存在細微差別。測試是動態的，它執行軟體以測試其功能。檢查根據一組預定義規則分析程式碼。

檢查器（或靜態和動態分析工具）由團隊應遵守的已識別標準（通常是編碼或設計指標）指導。檢查目標的示例包括編碼“語法”標準、架構分層遵守、程式碼重複以及許多其他方面。

持續程式碼檢查縮短了發現問題和修復問題之間的時間。有許多持續程式碼檢查工具可用。在此示例中，我們將使用NCover 3.x，它與 TeamCity 整合。讓我們看看如何進行持續程式碼檢查以及它能為我們做什麼。

下載並安裝 NCover

NCover 是一個單獨的產品，需要下載和安裝。要下載 NCover，請單擊以下連結並下載 32 位安裝程式：http://www.ncover.com/info/download.

執行下載的安裝程式，然後在安裝程式啟動後單擊“下一步”。

接受許可協議，然後單擊“下一步”。

接受預設元件並單擊“下一步”。

單擊“安裝”按鈕開始安裝。

單擊“完成”按鈕完成安裝。

透過轉到C:\Program Files (x86)\NCover\ NCover.Explorer.exe 來首次啟動 NCover 安裝。您只需要首次安裝試用金鑰，這是一個簡單的過程。

配置 TeamCity 中的專案以使用 NCover

步驟 1 − 轉到您的專案主螢幕並單擊“編輯配置設定”。

步驟 2 − 轉到“構建步驟”並單擊TestStep 的“編輯”。持續程式碼檢查需要與已定義的單元測試一起執行。

步驟 3 − 在“.Net 程式碼覆蓋率”部分中，單擊“.Net 程式碼覆蓋率工具”。然後選擇以下設定：

將 .Net 程式碼覆蓋率工具選擇為 NCover(3.x)
平臺為 x86
版本為 v4.0
NCover 的路徑為 C:\Program Files (x86)\NCover
保持其他設定不變

步驟 4 − 單擊“儲存”。

步驟 5 − 現在轉到專案的主螢幕並單擊“執行”。

步驟 6 − 執行構建後，單擊“測試透過”。您現在將看到一個程式碼覆蓋率螢幕，並且您將看到許多指標。

步驟 7 − 您現在可以單擊“程式碼覆蓋率”選項卡以獲取有關程式碼分析的更多資訊。

步驟 8 − 單擊fullcoveragereport.html。您現在將獲得一份關於對.Net 程式碼進行檢查的完整綜合報告。

持續整合 - 資料庫

持續資料庫整合是在對專案的版本控制儲存庫應用更改時重建資料庫和測試資料的過程。

在資料庫整合中，通常所有與資料庫整合相關的工件：

應該位於版本控制系統中。
可以針對嚴格性進行測試並檢查策略合規性。
可以使用構建指令碼生成。

持續資料庫整合中可能涉及的活動可以是以下任何一項：

刪除資料庫 − 刪除資料庫並刪除關聯的資料，以便您可以使用相同的名稱建立一個新資料庫

建立新資料庫 − 使用資料定義語言 (DDL) 建立新資料庫。

插入初始資料 − 插入系統交付時應包含的任何初始資料（例如，查詢表）。

遷移資料庫和資料 − 定期遷移資料庫模式和資料（如果您正在基於現有資料庫建立系統）。

修改列屬性 − 根據需求和重構修改表列屬性和約束。

修改測試資料 − 根據需要更改多個環境的測試資料。

因此，在我們的持續資料庫示例中，我們將執行以下步驟：

我們將建立一個 MS SQL Server 資料庫和相應的表。
我們將從 SQL Server Management Studio 建立一個指令碼。此資料庫指令碼將用於在資料庫中設定我們的表。
我們將在 ASP.Net 專案中編寫程式碼來訪問此資料庫。
我們將在 TeamCity 中的專案中建立一個步驟來執行此指令碼。
我們將指令碼檢入 Git。

在前面部分建立的 AWS 資料庫中執行此操作的步驟。

步驟 1 − 建立一個 MS SQL Server 資料庫和相應的表。讓我們開啟 SQL Server Management Studio 並建立一個簡單的資料庫和表。右鍵單擊資料庫並單擊新建資料庫。

步驟 2 − 將其命名為Demodb 並單擊“確定”。

步驟 3 − 在新資料庫中，右鍵單擊並建立一個新表。

步驟 4 − 您可以向表中新增所需的列。

步驟 5 − 儲存表並將其命名為Demotb。

步驟 6 − 現在右鍵單擊該表並選擇選單選項將表指令碼化到 → 刪除和建立到 → 檔案。

步驟 7 − 將檔案儲存到 demo 專案資料夾中，命名為Sample.sql。

這就是資料庫指令碼的外觀。如果存在，它將首先刪除現有表，然後重新建立表。

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

步驟 8 − 現在讓我們快速更改我們的ASP.Net 程式碼以引用新資料庫。

步驟 9 − 在Demo 專案中的Tutorial.cs 檔案中，新增以下幾行程式碼。這些程式碼行將連線到您的資料庫，獲取伺服器版本並將版本名稱儲存在 Name 變數中。我們可以透過Response.write 命令在我們的Demo.aspx.cs 檔案中顯示此 Name 變數。

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

步驟 10 − 將以下程式碼新增到Demo.aspx.cs 檔案中，以確保它顯示 SQL Server 版本。

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

現在，如果我們執行程式碼，您將在瀏覽器中獲得以下輸出。

步驟 11 − 現在讓我們在 TeamCity 中新增一個步驟，該步驟將呼叫資料庫指令碼。轉到您的專案儀表板並單擊編輯配置設定。

步驟 12 − 轉到“構建步驟”並單擊新增構建步驟。

選擇以下選項（請注意，MS SQL Server 客戶端應安裝在 CI 伺服器上）。

執行程式型別應為命令列。
給出一個可選的步驟名稱。
執行應為帶有引數的可執行檔案。
命令可執行檔案應為C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe
命令引數應為-S WIN-50GP30FGO75 -i Sample.sql。其中 –S 給出 SQL Server 例項的名稱。

步驟 13 − 單擊“儲存”。

現在需要確保構建順序。您必須確保構建順序如下。

步驟 14 − 您可以透過選擇重新排序構建步驟的選項來更改構建順序。

資料庫設定應該排在第一位 – 因此這將用於從頭開始重新建立您的資料庫。
接下來是您的應用程式的構建。
最後是您的測試設定。

步驟 15 − 現在執行git add 和git commit 命令，以便將Sample.sql 檔案檢入 Git。這將自動觸發構建。並且此構建應該透過。

您現在擁有一個完整的構建週期，並在您的週期中也具有持續資料庫整合的方面。在下一節中，讓我們進一步討論並瞭解持續部署。

現在您已經使用本地 SQL Server 完成了此操作，我們可以對前面部分中建立的AWS MS SQL Server 重複相同的步驟。要連線到 Microsoft SQL Server，您需要透過以下約定進行連線。

步驟 16 − 首先檢視在 AWS 中分配給您的資料庫例項的名稱。當您登入到 AWS 時，轉到資料庫部分下的 RDS 部分。

步驟 17 − 在出現的下一個螢幕中，單擊“DB 例項”。

步驟 18 − 單擊您的資料庫並記下端點。在下面的螢幕截圖中，它是demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

步驟 19 − 現在要從SQL Server Management Studio連線到資料庫，您需要指定連線字串為demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433（注意例項名稱和埠號之間使用的逗號）。

以下螢幕截圖顯示了成功連線到資料庫。

然後您可以重複所有相同的步驟。Sqlcmd 命令如下所示：

可以在 TeamCity 的資料庫構建步驟中替換此相同的命令。當您執行sqlcmd 命令時，表將自動在 AWS 中的 SQL Server 資料庫中建立。

持續整合 - 部署

自動化構建和可重複構建。自動化測試和可重複測試。測試類別和測試頻率。持續檢查。持續資料庫整合。建立有效 CI 環境的一系列任務主要帶來一個關鍵好處：能夠在任何時間點、在任何環境中釋出可執行的軟體。

在我們之前的章節中，我們已經完成了以下所有部分：

建立了我們的程式碼。
確保在 TeamCity 中進行了正確的構建。
建立了資料庫整合流程。
進行了成功的測試。

現在唯一剩下的就是執行自動部署，以便完成我們的整個流程。

對於我們的自動部署，我們需要按照以下步驟操作：

在我們的部署伺服器上，確保已安裝 IIS。
確保 IIS 使用者擁有我們資料庫的訪問許可權。
建立一個釋出配置檔案，該檔案將在構建站點時用於釋出站點。
確保我們更改 MSBuild 命令以進行自動部署。
自動化 TeamCity 以進行自動釋出。
執行git commit 以確保所有檔案都在 Git 中。

步驟 1 − 配置本地 IIS 伺服器。如果您有本地或遠端 IIS 伺服器，則可以執行以下配置來部署我們的應用程式。在自動執行之前，手動檢視是否可以進行部署始終是一個好習慣。

步驟 2 − 在 Windows 2012 伺服器上，轉到伺服器管理器並單擊“新增角色和功能”。

步驟 3 − 在出現的下一個螢幕上單擊“下一步”。

步驟 4 − 在下一個螢幕上選擇基於角色或基於功能的安裝，然後單擊“下一步”。

步驟 5 − 選擇預設伺服器，然後單擊“下一步”。

步驟 6 − 選擇 Web 伺服器角色，然後單擊“下一步”。

步驟 7 − 在出現的下一個螢幕上，單擊“下一步”。

步驟 8 − 在出現的下一個螢幕上再次單擊“下一步”。

步驟 9 − 在彈出的下一個螢幕上，單擊“下一步”。

步驟 10 − 在最後一個螢幕上，您可以單擊“安裝”按鈕來安裝 IIS。

安裝 IIS 後，您可以透過開啟 Internet Information Services 來開啟它。

步驟 11 − 單擊“應用程式池”，您將看到一個名為DefaultAppPool的池。下一步需要它訪問 SQL Server。

步驟 12 − 如果我們需要將 ASP.Net 應用程式連線到 MS SQL Server 應用程式，則必須向預設應用程式池授予對 SQL Server 例項的訪問許可權，以便它可以連線到我們的Demodb資料庫。

步驟 13 − 開啟 SQL Server Management Studio。轉到“登入名”，右鍵單擊並選擇選單選項新建登入名。

在下一個螢幕中，更新以下引數並單擊“確定”。

登入名：IIS APPPOOL\DefaultAppPool。
預設資料庫 – 這應該是我們的資料庫，即 demodb。

步驟 14 − 建立釋出配置檔案。釋出配置檔案用於在 Visual Studio 中建立部署包，然後可以使用 MS Build 和任何 CI 伺服器相應地使用它。為此，在 Visual Studio 中，右鍵單擊專案並單擊選單選項“釋出”。

步驟 15 − 在出現的下一個螢幕中，選擇建立新的釋出配置檔案，為其命名 – DemoDeployment。然後單擊“下一步”按鈕。

在隨後出現的螢幕中，新增以下值：

選擇 Web Deploy 作為釋出方法。
將伺服器輸入為 localhost。
將站點名稱輸入為 Default Web Site/Demo。
將目標 URL 設定為https:///Demo

然後單擊“下一步”按鈕。

步驟 16 − 在下一個螢幕中，單擊“下一步”。

步驟 17 − 在出現的最後一個螢幕中，單擊“釋出”按鈕。

現在，如果您轉到專案的C:\Demo\Simple\Properties\PublishProfiles位置，您將看到一個新建立的釋出配置檔案 xml 檔案。此釋出配置檔案將包含將應用程式釋出到本地 IIS 伺服器所需的所有詳細資訊。

步驟 18 − 現在讓我們自定義我們的 MSBuild 命令並使用上述釋出配置檔案，看看會發生什麼。在我們的 MSBuild 命令中，我們指定以下引數：

Deploy on Build 為 true – 這將在成功構建後觸發自動部署。
然後我們提到使用上面步驟中使用的釋出配置檔案。
僅需向 MSBuild 部署功能提及正在使用的 Visual Studio 版本。

執行上述命令後，MSBuild 將觸發構建和部署過程。您會注意到，它正在將其部署到 IIS 伺服器中的預設網站。

現在，如果我們瀏覽到站點 – https:///Demo/Demo.aspx，我們將看到以下輸出，這意味著 MSBuild 成功地將應用程式部署到我們的網站。

步驟 19 − 透過 TeamCity 自動化 – 現在是時候向我們的 TeamCity 伺服器新增一項任務，以便根據上述步驟自動使用 MSBuild 部署我們的應用程式。

步驟 20 − 轉到您的專案儀表板並單擊編輯配置設定。

Project Dashboard Configuration Settings

步驟 21 − 轉到“構建步驟”並單擊“新增構建步驟”。

選擇以下選項：

執行程式型別應為 MSBuild
輸入可選步驟名稱
將構建路徑輸入為 Simple/Simple.csproj
將 MSBuild 版本保留為 Microsoft Build Tools 2013
將 MSBuild Toolsversion 保留為 12.0
將命令列設定為 /p:DeployOnBuild = true /p:PublishProfile = DemoDeployement /p:VisualStudioVersion = 12.0

步驟 22 − 單擊“儲存”。

確保在構建步驟中，部署步驟是鏈中的最後一步。

步驟 23 − 現在讓我們執行最終的git commit，以確保所有檔案都在 Git 中，並且可以被 TeamCity 使用。

恭喜，您已成功為您的應用程式設定了完整的持續集成周期，可以在任何時間點執行。

持續整合 - 最佳實踐

讓我們根據到目前為止我們學到的所有課程，最後回顧一下持續整合的最佳實踐：

維護程式碼庫 − 這是最基本的步驟。在我們所有的示例中，從程式碼庫到釋出配置檔案，再到資料庫指令碼，所有內容都儲存在 Git 儲存庫中。必須始終確保所有內容都儲存在程式碼儲存庫中。
自動化構建 − 我們已經瞭解瞭如何使用 MSBuild 自動化構建以及使用釋出配置檔案。這同樣是持續整合過程中的一個關鍵步驟。
使構建自測試 − 確保您可以透過適當的單元測試用例來測試構建，並且這些測試用例應該能夠由持續整合伺服器執行。
每個人每天都提交到基線 − 這是持續整合的一個關鍵原則。等到整個過程結束再檢視誰破壞了構建是沒有意義的。
每次提交（到基線）都應構建 − 對應用程式的每次提交都需要成功構建。如果構建由於任何原因失敗，則需要更改程式碼以確保構建透過。
保持構建速度 − 如果構建速度很慢，則表明整個持續整合過程中存在問題。確保構建始終限制在一定時間內，最好不要超過 10 分鐘。
每個人都可以看到最新構建的結果 − TeamCity 儀表板使每個人都能檢視所有已透過或失敗的構建。這為參與持續整合過程的所有人員提供了良好的洞察力。

列印頁面