共用方式為

連續建置和部署

  • 發行項

當有許多開發人員共同合作複雜的軟體專案時，將不同部分的程式碼整合在一起的程序會變得漫長而不可測。 不過，如果您不斷在建置和部署專案，就有辦法讓這個程序變得更有效率、更可靠。

連續整合 (CI) 是指盡可能經常將程式碼整合至共用儲存機制的程序。 在程式碼整合期間，只要建置中斷或測試失敗，您就能馬上知道程式碼是有錯誤的。

Martin Fowler 針對連續整合的過程，分析出下列作法：

  • 維護單一來源儲存機制。

  • 自動化組建。

  • 讓您的組建自行維持。

  • 每天至少簽入一次。

  • 在 CI 伺服器上建置每個簽入。

  • 保持組建的速度。

  • 在實際執行環境的複製品中測試。

  • 讓任何人都能輕鬆地取得最新的可執行檔。

  • 永遠要知道最新的動態。

  • 自動化部署。

如需詳細資訊，請參閱 Martin Fowler 個人網站上的下列網頁：連續整合 (英文)。

Visual Studio Application Lifecycle Management (ALM) 可協助您管理端對端的軟體開發程序，並且可支援連續整合的作法。 利用 Visual Studio ALM 的功能，您的專案可以避免未預期的延遲、成本超支和執行風險。

本主題內容

  • 管理相依性

  • Visual Studio 2010 中的連續整合

  • 準備和開始使用

  • 版本控制

  • 組建

  • 測試和部署

  • 專案整合和通訊

管理相依性

程式碼之間有相依性，因此整合程式碼會是一個複雜的程序。 例如，在畫面上繪製圓形的程式庫會相依於系統數學程式庫的 Sqrt() 方法。 如果 Sqrt() 方法變更，您就必須據以更新程式庫。 硬體和作業系統的變更頻率遠低於 Team 專案。 但不論是什麼情況，置變更於不理都可能會導致災難性的結果。 您可以盡早整合程式碼，以檢查程式碼是否根據有效的假設，以及是否按照所規劃的方式運作。

程式碼的變更對相依性的影響可能會不同。 下圖顯示兩種情況。 左側的範例顯示相當隔離的變更。 但右側的範例則顯示較可能造成影響的變更，因為上面有許多相依性。

建置和部署程式碼圖表

下圖顯示如果您不連續整合和升級程式碼，經常發生的變更會如何造成深遠的影響。

連續建置和部署程式碼時間表

在步驟 1 中，您變更程式碼區塊 h，而這項變更可能會影響所有相依的程式碼區塊 a、b、d、e 和 f。 在步驟 2 中，您變更程式碼區塊 a 和 b。 如果小組未完成步驟 1 與 2 之間的整合，則區段 a 和 b 可能會不再有效。 在步驟 3 中，您變更程式碼區塊 f。 假設小組未完成步驟 2 與 3 之間的整合，則到目前為止，程式碼區段 b 已受到影響、變更，然後再次受到影響。 這時候要修正程式碼區塊 b，可能就會變成一項困難的挑戰。

Visual Studio 2010 中的連續整合

Visual Studio ALM 提供整合式工具集來支援連續整合。如下圖所示，這些工具包括版本控制、組建、測試、部署至實驗室環境、工作項目追蹤和資料倉儲功能。

連續建置和部署中的 TFS

首先，您可以使用 Team Foundation 版本控制來管理分支、變更集和其間的整合。 每個小組成員都可以使用工作區來獨立作業。 如需詳細資訊，請參閱分支及合併和建立工作區以使用 Team 專案。

第二，您可以使用 Team Foundation Build 在自動化和分散式系統中編譯、測試及部署您的軟體。 如上圖所示，Team Foundation Build 有兩種組建。 一種會使用連續組建類型來建置開發分支。另一種則會使用閘道簽入組建類型來建置主分支。 Visual Studio Team Foundation Server 支援五種類型的組建：手動、連續 (由每個簽入觸發)、正在復原 (累積簽入，直到前一次組建完成)、閘道簽入和排程。 如需詳細資訊，請參閱建立基本組建定義、認識 Team Foundation Build 系統和簽入由閘道簽入組建所控制的暫止變更。

第三，Visual Studio ALM 的實驗室管理功能有助於定義和部署組建至實體和虛擬實驗室環境。 若要在特定環境中的執行階段攔截整合錯誤，您可以將組建部署至實驗室環境，然後在這個組建上執行測試套件。 如需詳細資訊，請參閱在應用程式生命週期中使用虛擬實驗室。

此外，Visual Studio ALM 中的測試功能可在小組成員的電腦上、組建電腦上以及實驗室環境內部使用。 首先，在開發人員的電腦上執行測試套件會攔截最近變更或建立之程式碼的問題。第二，在組建電腦上執行測試會攔截與其他程式碼之整合有關的問題。 第三，在實驗室中執行測試會攔截與小組所設定之特定環境有關的問題。 如需詳細資訊，請參閱 HOW TO：在建置應用程式之後設定和執行已排程的測試。

注意事項注意事項

執行測試可以產生程式碼涵蓋範圍度量，您可用這個度量來了解測試案例可以涵蓋多少程式碼。 但是，您無法使用程式碼涵蓋範圍來測量測試完整性或品質。 如需詳細資訊，請參閱 HOW TO：使用自動化測試的測試設定進行程式碼涵蓋範圍的設定。

第四，Visual Studio Team Foundation Server 是儲存工作項目的儲存機制。 您可以建立、管理和追蹤指派給小組成員的工作項目 (例如 Bug 或工作)。 如果在程式碼整合期間有組建中斷，您的小組就必須盡快修正問題。 您可以將 Team Foundation Server 設定為針對組建中斷建立工作項目。 如需詳細資訊，請參閱追蹤 Bug、工作和其他工作項目。

最後，Team Foundation Server 和 SQL Server Analysis Services 的倉儲資料庫會將 Team Foundation Server 中的子系統所提供的所有資料彙總，並建立資料之間的關聯性。 這些子系統包括版本控制、組建、測試、部署和工作項目追蹤。 因此，您的小組可以將連續整合的端對端程序視覺化。如需詳細資訊，請參閱 使用 Visual Studio ALM 的關聯式倉儲資料庫建立報表。

準備和開始使用

您的小組可以依照下列進展，開始使用連續整合和 Team Foundation Server：

  1. 使用 Team Foundation 版本控制將程式碼整合至單一程式碼基底。

  2. 在 Team Foundation Build 中建立手動組建類型。

  3. 執行自動化測試案例，以確認組建的品質。 如果您沒有適當的測試套件，請建立預留位置測試套件，並匯入少數自動化測試案例。 這個套件可以當做未來測試的預留位置。

  4. 確定您將組建所產生的二進位檔傳遞至共用位置。 這個策略有助於診斷測試期間出現的問題。

  5. 使用 Microsoft 測試管理員，在特定環境中的執行階段攔截整合錯誤。

版本控制

版本控制系統會將共用儲存機制提供給程式碼。 小型小組可以使用單一分支。 但是，因為您通常必須開發多個版本的程式碼，並於不同的里程碑釋出專案，所以使用兩個以上的分支較為可行。 如需如何建立與合併程式碼分支的詳細資訊，請參閱 CodePlex 網站上的下列網頁：Team Foundation Server Branching Guide 2.0 (英文)。

建置

在連續整合中，組建系統會產生可供測試和部署的可執行元件。 組建系統也會以編譯錯誤和警告的形式提供回應。 這些錯誤是由引入至專案來源中的變更所造成。

Team Foundation Build 會提供下列組建類型：

  • 手動 - 組建是由小組成員排入佇列。

  • 連續 - 組建是由版本控制分支的簽入排入佇列。

  • 正在復原 - 組建累積，直到前一次組建完成為止。

  • 閘道簽入 - 只有在順利合併並建置提交的變更時，才接受簽入。

  • 排程 - 組建依照定義的排程進行。

如需詳細資訊，請參閱建立基本組建定義。

若要成功實作連續整合，小組成員必須進行哪些作業？

您的小組成員必須組織其來源，讓它們以最多 10 分鐘的時間建置。 對於大型專案而言，可能無法使用這個頻率。 您的小組可以使用 Team Foundation Server 來設定各種組建定義，以便建置不同的程式碼基底子集。 如果組建花費的時間很長，您可以使用正在復原的組建類型，針對未變更的程式碼連續產生二進位檔。

如果組建中斷，您的小組就必須立即修正組建。 假設主分支沒有受到錯誤的反向整合所影響，大部分組建中斷就是來自工作分支的錯誤簽入或主線分支的正向整合。 將修正組建中斷的工作指派給某位小組成員一段時間，然後在小組成員之間輪流這項指派，是很好的作法。

每天應該執行多少個組建？

當您連續整合程式碼時，可以針對出現在每個分支中的每個簽入執行一個連續的組建。 您也可以執行與新簽入程式碼無關的正在復原的組建。 如需詳細資訊，請參閱建立基本組建定義和監視執行中組建的進度。

Team Foundation Server 如何協助加快程式碼組建？

設定組建定義來執行累加建置將有助於加快組建的速度。 您可以使用組建記錄來識別組建的慢速部分，進而產生改善的機會。 如需詳細資訊，請參閱針對累加建置設定 Team Foundation Build。

Team Foundation Build 如何協助調整連續整合？

組建控制器和組建代理程式有助於調整連續整合循環。

如需詳細資訊，請參閱認識 Team Foundation Build 系統。

測試和部署

如何將測試和部署納入連續整合中？

下圖顯示 Visual Studio ALM 中的測試和部署功能如何能配合連續整合。

讓測試配合連續整合

首先，當您連續整合程式碼時，可以從組建本身尋找程式碼的問題。 根據您所使用的編譯器，組建會編譯成功或失敗。 您可以產生組建報告以列出來自編譯器的錯誤和警告訊息。 在 Visual Studio ALM 中，組建報告也會提供一些資訊，例如這個組建修正了哪些 Bug、這個組建包含哪些變更集，以及是否在建置期間執行程式碼分析。 您可以使用 Visual Studio ALM，確認程式碼的設計是否遵循小組所定義的規則。 如需詳細資訊，請參閱 HOW TO：針對圖層圖表驗證 .NET 程式碼。

其次，您可以執行單元測試，來尋找程式碼的問題。 這些測試會以和編譯器不同的方式來診斷問題。 編譯器的規則會檢查程式碼語法和語言建構的問題。 反之，單元測試 (可在組建完成之後針對組建執行) 可以驗證程式碼的任何功能層面。 這些單元測試也可以提供度量，例如在給定一組單元測試的情況下，組建的程式碼涵蓋範圍。 如需詳細資訊，請參閱 HOW TO：使用自動化測試的測試設定進行程式碼涵蓋範圍的設定。

您可以使用 Microsoft 測試管理員來設定可在其中執行測試的特定環境。 隔離的單元測試可以提供某種程度的功能驗證。 不過，就環境而言，有下列重要層面必須考量：

  • 不同的環境可能會影響程式碼的運作方式。 例如，如果沒有實驗室管理環境，可能會難以測試網路設定和拓撲。

  • 將在特定環境中部署程式碼的程序自動化，有助於小組減少部署時間，並增加部署反覆項目的數目。

如需詳細資訊，請參閱 How to: Create an Environment from Virtual Machine Templates和設定測試電腦以便執行測試或收集資料。

我該如何組織測試套件來啟用連續整合？

您可以先執行對於連續組建而言最重要的測試套件，這是因為太多測試可能會耽誤組建完成。 請務必針對目前的反覆項目執行這些測試。

在夜間或排程的組建循環中，您也可以執行先前組建的測試，以及在先前期程 (Sprint) 中驗證功能的完整測試。

連續整合對於測試小組有何影響？

連續整合有助於識別包含錯誤的組建，避免測試小組浪費時間來處理和安裝錯誤的組建。

專案整合和通訊

實作連續整合的工作可能會很繁重，端視您專案的大小而定。 您的小組必須在專案的第一次期程中定義和排程連續整合的工作。

如果您想要採取分階段的連續整合，可以從實作自動化組建開始。 然後，您就可以修改組建以加入執行單元測試。 最後，您可以加入將測試過的組建部署至實驗室環境的功能，然後，您就可以在此環境內部執行測試，以便驗證不同的環境是否會影響程式碼。