2016 年 10 月

第 31 卷,第 10 期

本文章是由機器翻譯。

行動 DevOps - 使用 TFBuild 將原始程式碼轉換為可部署的成品

Kraig Brockschmidt |2016 年 10 月

在最後一篇文章中,「 事實來源︰ 在 DevOps 中角色機制 」 (bit.ly/2bKeC2T),我討論過整體的發行管線,所示的原始檔控制扮演重要角色 [圖 1。我已發行管線稱為將原始程式碼儲存機制中的程式碼轉換成可供客戶的應用程式和服務的處理序集合,並傳遞至客戶的裝置和客戶存取伺服器。發行管線,也是直接的必要版本,會發生此問題,無論自動化的步驟清單。DevOps 做法因此開始了解哪些步驟和程序牽涉到之後,您可以再以累加方式自動化這些程序來降低成本並提高品質的版本。

轉換原始程式碼建立發行管線的其餘部分所需的成品
[圖 1 的組建會將原始程式碼轉換成發行管線的其餘部分所需的成品

本文著重於行動應用程式的建置/連續整合 (CI) 階段管線的 (述 [圖 1)。位於其所在,我認為組建的這種方式︰ 組建是何種轉換原始碼,到可供測試和部署的成品視發行管線的其餘部分。也就是建置的輸出有管線的其餘階段的工作,或採取行動的組建成品的輸入。例如,所有形式的測試都操作的可執行的應用程式和服務程式碼,而不是原始的原始程式碼。而且不用說,您必須擁有適當的二進位碼檔案部署至應用程式存放區和 Web 伺服器。在原始程式檔更移透過管線或小於未經修改 (如許多 JavaScript、 HTML 和 CSS 檔案中 Apache Cordova 應用程式執行個體) 的情況下,即使在建置仍然扮演的角色建立適當的封裝,結合檔案、 套用前置處理器和 minifiers,依此類推。

將組建視為相關實體的結構一樣。一大堆建置教材,例如木材、 實體和 rebar、 指甲、 螺絲、 windows、 管道、 網路、 屋頂、 隔離、 設備等,都包含一棟房子,可能,但是堆將不會自動開啟本身到這種結構。這種情況發生只能由人知的方式放在一起,逐步解說,取得所有這些項目。這就是 「 進行建置 」 是怎麼回事。在行動應用程式的領域,特別是,它可能甚至可說是有多個線段來源資料,其中有些目標平台之間共用,而其中有些則是唯一。

當然,軟體很大的好處是執行組建不會消耗處理序中的來源資料。您可以視需要,每次您的需要和如果自動化程序,在極少的成本通常執行組建。連續整合要依賴這些特性。您可以建立多個獨立的成品,從相同來源的程式碼中,每一個都有個別的發行管線。這通常是行動應用程式的情況。在專案中 MyDriving (aka.ms/iotsampleapp)、 範例我已經已參考此系列中,有不同的組建 iOS、 Android 和 Windows,以及部署至 Azure App Service 中的程式碼中所示 [圖 2。(請注意,您可以使用組建/CI 不一定送入的發行管線開發小組的進行中測試)。

MyDriving 專案有四個組建,以及四個發行管線
[圖 2 MyDriving 專案有四個組建,以及四個發行管線

也知道,Visual Studio Team Services 可以繪製從 Team 專案,可讓您管理專屬部分保存私用公用、 開放原始碼儲存機制中的應用程式的特定程式庫以外的其他儲存機制。任何指定之組建定義可以繪製從僅有單一的儲存機制,但 Team 專案可以使用任何數目的組建定義。

在 DevOps 中建置的角色

內專業建構本場房屋和其他建築物運作,有人一律會檢查所有必要的資料是否手邊供至少幾天的工作。此連續驗證提升效率和產能的團隊,也就是說,其效能,並且是不可或缺的時間和預算內提供結果。組建完成同樣的工作,在軟體中。如我之前說過 「 從客戶的程式碼︰ 瀏覽行動運 」 (bit.ly/2ayD9Zw),所有 DevOps 活動和做法都的方式來持續驗證您的應用程式和服務的效能。(同樣地,「 效能 」 表示最低的成本,您的企業客戶提供最大值)。 因此,建置基本上是方法來驗證內容來源的程式碼儲存機制,因為您預期會就地使用的所有項目。

組建 (不含其他可能執行的測試) 通常有兩個結果的其中之一︰ 成功或失敗。成功表示原始程式碼儲存機制中包含的需要,可建置的檔案,以產生可供測試和部署的成品。失敗表示一個或多個檔案都故障 (它們有語法錯誤),或已設定的項目中遺漏之方式的儲存機制組建。(該設定可能是本身故障,當然)。

在理想情況下,您想要知道儘快 「 中斷組建 」 的缺失引入儲存機制。這是其中組建自動化程序變得龐大的優勢,因為您可以執行組建,並取得立即驗證至儲存機制的變更時。這稱為連續整合。

持續整合

在過去,組建工作往往是複雜又冗長乏味的程序,對大型專案通常需要一或多個專用全職員工。基於這個理由,執行它們常,根據這段需要數百或甚至數千個變更可能已認可至儲存機制。因為任何數目的任意組合,這些變更,可能會導致建置失敗,可能是真正的夢魘,取得每個人的變更整合到可運作的組建。我還記得少數野心勃勃專案 microsoft 取消只是因為它們無法實際建置。

避免這類惡夢落實 CI。以下是如何我把它︰

  1. 因為組建驗證您的儲存機制,自然想盡早並經常執行組建。
  2. 您可以自動化組建,如果您讓程序高重複極少的成本。
  3. 如果來源儲存機制的變更時,可以自動觸發的組建,您已達到 CI。

CI,簡單地說,驗證每個來源存放庫中的時間來變更本身,接近變更,立即通知適當的開發人員如果建置失敗。閘道簽入 (使用 Team Foundation 版本控制) 或使用 Git (PR) 產生器也會觸發組建,以使用新的程式碼之前已簽入或合併,以便在建置結果成功時,才變更儲存機制提取要求等功能。無論如何,CI 快速偵測程式碼 (包括程式碼失敗的自動引動的測試,但這是更新的發行項的主體) 的儲存機制中。

所有這就是為什麼與 CI 組建自動化是其中一個最常見的 DevOps 做法。事實上,即使您手動執行發行管線中的其他功能,您會發現在原始檔控制與自動化的組建和 CI 初期投資是值得,同時,特別是專案變得更加複雜。

組建的剖析

最小值,在建置需要三個元件︰ 原始程式碼、 組建代理程式和組建定義,也就是說︰ 您想要建置; 的程式碼電腦上的必要工具和 Sdk 來產生成品從該程式碼。以及一組告訴電腦如何了其中的指示。基本的關聯性如下所示 [圖 3。(同樣地,很可能有多個儲存機制、 組建定義和組建代理程式,建議在 [圖 2。)

基本來源儲存機制、 組建定義、 組建代理程式和產生的組建成品之間的關聯性
[圖 3 基本來源儲存機制、 組建定義、 組建代理程式和產生的組建成品之間的關聯性

即使詞彙 「 組建代理程式 」 和 「 組建定義 」 似乎很新,您實際上開始使用它們自最典型的"Hello,World !"程式碼撰寫您第一天︰

  1. 根據您的電腦上安裝某些程式的工具,您必須組建代理程式開啟它。
  2. 撰寫一個簡短的程式,並將其儲存在檔案中,您可以建立第一筆原始程式碼。
  3. 輸入命令,以編譯並連結該程式碼,您可以建立組建定義並執行組建、 可執行的可執行檔中產生。(現代 JIT 工具,像是 Microsoft.NET Core 通常編譯並執行程式在一起。)

當然,只要您有一個可體驗的神奇的程式碼撰寫您開始撰寫更多程式碼,該程式碼分解成多個檔案,並建立更複雜的專案。此時,一再輸入命令變成繁複,所以您的組建定義可能取得批次檔或其他指令碼的格式。最後您也有不想等候每當您執行組建,因此,探索到的 makefile 和專案檔案,例如 NMAKE 和 MSBuild 系統的優點,以及分別組建定義當做重新編譯所有項目。這些系統可讓您定義在檔案間的相互關係,如此您重新編譯只會有需要,可大幅縮短編輯建置測試開發人員迴圈。

所有這些都是說,隨著軟體開發持續發展,也會增加您手上有建置工具的複雜度。最近,讓這些工具可做為可擴充的雲端服務 — 我們所謂 Team Foundation Build 或 TFBuild — 已經打造新一代。

伺服器、 佇列、 代理程式和集區

當自己使用,您將逐漸安裝更多的工具和 Sdk 在開發電腦,讓它更豐富、 更有能力的代理程式。長時間之前,必須建立一個或多個專用組建的伺服器您可以完全管理的軟體環境。這是與團隊,尤其重要,因為就不需要保留每個開發人員機器需要的工具與同步處理。這類管理組建伺服器,以及其他共同作業的工作,例如原始檔控制、 工作追蹤及測試時,負責推動 Microsoft Team Foundation Server (TFS) 和建立 TFBuild 超過十年前。

TFBuild,尤其是使用 CI,重要的是它能夠管理和協調多個佇列的組建要求。如果您有許多開發人員認可一天當中的程式碼,另一個組建正在進行中時,將無疑會發生許多認可。但您不想要取消該組建,因為 CI 與您想要與特定認可產生關聯的每個成功/失敗組建報告。在此同時,更多的要求在佇列中,取得堆疊較長的開發人員必須等到建置結果。

此時您需要調整系統,這表示組建代理程式會變成不同的電腦。就技術上來說,組建代理程式是一項服務︰ 多個代理程式可以執行的相同實體伺服器上,可讓您利用多核心機器平行執行的組建。當該伺服器已超量時,您可以輕鬆地與其他代理程式加入一個或多部機器。

這會建立了稱為代理程式集區時,指的是所有代理程式,不論它們如何分散在實體電腦的組合的強大功能的抽象概念。TFBuild,事實上,適用於代理程式集區,而不是電腦。當組建佇列的最上層,TFBuild 會將其委派至下一個可用的代理程式集區中。代理程式集區也可以共用不同的 Team 專案,在 「 管理您建置和部署系統 」 頁面上所述 bit.ly/2b0UwAg

行動裝置應用程式專案,特別是,您通常需要一種以上的代理程式因為每個目標系統有一組唯一的平台特定的工具和 Sdk。所幸,Microsoft 提供免費代理程式用於 Windows、 OS X 及 Linux 中所示 [圖 4。在本文稍後我將示範建置 iOS 的 Mac 代理程式設定。

他們可以建置的 Windows、 Mac 和 Linux 代理程式和專案類型
[圖 4 Windows、 Mac 和 Linux 代理程式和專案類型可以建置

建置雲端中的伺服器

瞭解如何調整任何交談自然會啟動可能會移轉到雲端,讓原則和法規的運算能力。使用雲端架構的伺服器,您不需要管理的實體機器,或甚至軟體環境。雲端運算也會隨收隨付定價、 簡單又符合成本效益來視需要變更您的容量,讓它在中央位置。這是透過 Visual Studio Team Services 提供的哪些。

小組服務提供 「 裝載 」 組建代理程式。這些是使用各種工具和 Sdk,預先設定的 Windows 電腦上所列 bit.ly/2aNFKis。撰寫本文時,可以建立裝載代理程式幾乎可以使用 Visual Studio 和 Java 工具包括 Windows 和 Android 的應用程式寫入與 Xamarin、 Apache Cordova 或原生工具鏈來建置。您可以設定任何數目的裝載代理程式集區,並視需要將它們組織成不同的定價層級。

因為裝載代理程式在 Windows 上執行,不過,它們無法建立 iOS 應用程式或.NET Core/ASP.NET 核心應用程式適用於 Mac 或 Linux。這些您需要在適當的電腦上安裝 OS X 或 Linux 代理程式連接至 Team Services,其中您可以再將它們組織成集區的這些代理程式。同樣地,您可以在您自己自訂的機器,其中包含未包含裝載代理程式上的軟體安裝的 Windows 代理程式。「 電腦 」 這裡包含虛擬機器,以及從之類的服務和 MacinCloud.com。總而言之,Team Services 真正可讓您使用任何組合的雲端與內部部署上的代理程式。

自動化建置與 Visual Studio Team Services

讓我們現在設定自動化 TFBuild 與 Xamarin 應用程式的連續整合 (大約遵循 「 建置 Xamarin 應用程式 」 在 bit.ly/2aiy48y)。若要開始,請 Xamarin 建置名為 2016 年 10 月的 Visual Studio 中建立新的 Xamarin.Forms 專案。接下來,建立其新的 Team 專案小組的服務帳戶稱為 MSDN Magazine Oct 2016 使用 Git 進行原始檔控制中。然後將程式碼發行至 Team 專案從 Visual Studio Team Explorer 中。這會導致 Team Services 入口網站上的 Team 專案程式碼] 索引標籤中,您可以使用的程式碼。

現在設定組建定義適用於 Android 依序按一下 [建置] 索引標籤,在 Team 專案,然後按一下 [+ 新增]。這會顯示對話方塊,其中具有一長串的簡單易懂的專案類型,包括原生和跨平台行動應用程式的各種不同的組建定義範本。(請注意,Apache Cordova 專案需要擴充功能小組服務商場; 請參閱 bit.ly/2atxNgp 如需詳細資訊。) 您也可以開頭空白的定義,並逐步建立它。

本逐步解說中,選取 [Xamarin.Android] 範本、 按一下 [下一步] 以顯示設定] 對話方塊中,以及來源儲存機制、 CI 使用,請與代理程式佇列 (所有這些之後可以變更),然後提供初始設定。然後按一下 [建立],Team Services 開啟組建定義編輯器中顯示 [圖 5。紅色文字表示的其他資訊需要,您可以看到 [建置] 索引標籤。

之前,先建立步驟中所示 [圖 5, ,我要彙總 [其他] 索引標籤上 (您可以找到完整的文件,網址 bit.ly/2ayghJh):

  • 儲存機制是連接到儲存機制之外 Team 專案,例如 GitHub、 Subversion 或任何其他 Git 伺服器。
  • 觸發程序時使用下列選項的 CI,組建發生設定閘道簽入和排程的組建 (通常用於每晚執行)。請注意,您可以一律組建排入佇列以手動方式從 Team Services,或是從 Visual Studio Team Explorer。
  • 選項 |建立工作失敗的項目,是您將工作項目指派至任何一個要求的組建時,就會失敗。CI 搭配使用時,要求者一定會的開發人員認可觸發組建的程式碼,因此程式碼認可、 組建和失敗的立即通知之間的緊密迴圈。(另外還有擴充 Team Services 市場傳送其他類型的通知。)
  • 變數可讓您選擇性地加密值,您可以在其他地方使用中的組建定義,例如認證相關聯的語彙基元。無法複製加密的值以外的組建定義。
  • 記錄可讓您變更記錄檔之組建定義。這是很重要,因為組建定義不是您的來源儲存機制的一部分,或尚未定義的變更可能會中斷組建。

新的 Xamarin.Android 組建定義初始檢視
[圖 5 之新的 Xamarin.Android 組建定義的初始檢視

回到 [圖 5, ,請記住,組建是關於原始程式碼轉換的發行管線,這表示將特定工具套用至獨立的步驟透過原始程式碼其餘部分所需的成品。如您所見,Xamarin.Android 範本的第一個步驟是 NuGet 還原,因為通常不會將此類封裝加入原始檔控制。當組建代理程式會擷取該組建的程式碼時,然後,它必須還原這些封裝。

接下來,此範本包含 (撰寫本文時) 來啟用和停用 Xamarin 授權,這就不再需要 Xamarin 現在是免費的步驟。它是安全地刪除這些步驟,因為它們將會從範本移除還是得夠快。

建置 Xamarin.Android 專案的步驟是什麼 Android 專案方案中執行 MSBuild。按一下該步驟,即可顯示的選項中 [圖 5, ,其中最下方的 [更多資訊] 連結會對您詳細的文件的步驟。請注意變數,例如 $(BuildConfiguration),在 [變數] 索引標籤設定為 「 發行 」 的 $ () 參考。此外,輸出目錄是組建定義放置以供其他建置步驟和甚至其他發行管線的組件及其成品。

下面兩個步驟建置包含名稱"test"則會建置應用程式部署至 Xamarin 測試定域機組和執行適用於測試的方案中的任何專案。這點,以及透過新增其他測試步驟 + 新增建置步驟] 命令,是如何您在 CI 中包含測試回合。因為沒有任何測試專案中我的解決方案在此時,我只停用下列步驟清除其控制選項 |已啟用] 核取方塊。這種方式步驟保持其定義,但將不會執行。

最後兩個步驟,如您所見,簽署 Android 應用程式套件,然後發行至其他位置,成品,如有需要。在後者的情況下,稍早的 MSBuild 步驟已將其結果儲存在 Team Services 資料夾,但這僅適用於 Team 專案的權限的人。(在加入新步驟...有許多選項) 發佈或檔案複製步驟是您將成品複製至 Team 專案以外的位置。

執行組建

完成並儲存您的組建定義之後,按一下 [佇列建置...開始執行程序。這會顯示一個對話方塊,選取代理程式佇列和 Git 分支 (如果適用),而且即使設定其他變數,只是這個組建的要求。不能變更這些參數可讓您輕鬆地透過不同的代理程式集區執行組建,而不需要編輯組建定義。比方說,如果您正在從內部部署代理程式移轉至裝載代理程式,您要手動繼續本機代理程式上執行 CI 觸發組建時,佇列是建置到裝載的佇列。當您準備切換,您接著編輯組建定義來重新導向 CI 組建,以裝載代理程式改用。

在我的案例中,我不需要變更任何項目,因此我開始建置。這會切換至 UI,可讓我查看哪些步驟完成後,執行哪些步驟和組建代理程式直接的主控台輸出。我必須承認,有趣的是一定要監看組建執行時,我相信您已經完成的次數 ! 並在建置完成之後如有需要您可以下載進一步分析輸出。

最後組建會順利完成或發生失敗。無論如何,您會看到最後的報表,就會顯示在已完成組建定義,清單中的左半部顯示 [圖 6。這是其中您可以返回並檢閱許多組建而保留在您的 Team 專案中,當然,佇列新組建。在 Visual Studio Team 總管] 窗格中,會顯示此相同的清單右側所示 [圖 6。從這裡您也可以新組建排入佇列,並建立新的組建定義。

TFBuild 造成 Team Services (左) 和 Visual Studio (右)
[圖 6 TFBuild 造成 Team Services (左) 和 Visual Studio (右)

建議您玩一下自己在使用 Visual Studio 中的範本所建立的新專案。特別是嘗試檢查連續整合中定義的觸發程序] 索引標籤,然後在原始程式碼檔案中進行一些小小的變更和認可/推入它的儲存機制。您會看到新組建排入佇列,會出現在 Visual Studio Team Explorer 和 Team Services 中定義的已排入佇列清單。

其他 TFBuild 步驟

組建定義範本是明顯只是起點,而且您也可以輕鬆地開頭空白的定義並個別加入每個步驟。無論如何,您會想要完全瞭解所有可用的步驟開啟任何組建定義,並按一下 [Add build step...命令。從出現的新增工作對話方塊,您可以建置各種不同的自訂組建定義。以下是可用的概觀 (目前清單永遠是在 bit.ly/2biafxz):

  • 建置工作︰ Android (包括簽章),Ant、 CMake、 Gradle、 Grunt、 Gulp 佇列 Maven,MSBuild,MSBuild、 Visual Studio 建置、 Xamarin.Android、 Xamarin.iOS、 Xcode (建置和封裝) 的 SonarQube 分析 Jenkis 伺服器上的工作。
  • 測試工作︰ 雲端式負載測試與 Apache JMeter 或 Visual Studio Team Services;以雲端為基礎的效能測試。發行程式碼涵蓋範圍] 和 [測試結果。執行功能測試 (CodedUI 或 Selenium);Visual Studio 測試 (包括部署代理程式)。Xamarin 測試定域機組。
  • 封裝 」 工作︰ 執行工作 NuGet、 npm、 還原 Xamarin 元件、 安裝 Podfile。
  • 部署工作︰ 部署至 Azure 雲端服務,blob,VM,SQL 資料庫,WebApp。執行 PowerShell 指令碼。在目標電腦,執行 PowerShell 或 SSH 的指令碼管理 Azure 資源群組。部署 Azure Service Fabric 應用程式。將檔案複製到遠端電腦。
  • 公用程式的工作︰ 管理 zip 檔案,複製/解密/刪除檔案。執行批次檔或命令列工具 (包括 bash 和 PowerShell);上傳檔案,與 curl 搭配;並複製檔案。

另外還有其他工作,才能在選擇從狀況良好 marketplace bit.ly/2aiRnPh, ,您會看到延伸模組 Azure DevTest 實驗室,發佈至 Google Play、 Bower、 Docker、 HockeyApp、 CodePush、 FTP、 ReactNative、 Apache Cordova 及更多。同樣地,花點時間熟悉功能可供使用。它是特別有趣,來查看工作 Google Play 服務商場 Docker、 HockeyApp 及 CodePush,等等。內建的部署工作,以及示範可輕鬆地將工作部署至其他環境,包括測試、 預備和甚至是實際執行的結果將組建定義的結尾。

MyDriving 專案提供一些其他的真實世界建置定義範例。Xamarin.android,它會在前面範例中所述,會使用所有相同的步驟,並新增幾個取代語彙基元,更新的版本名稱和數字,使用 cURL 下載金鑰存放區,並部署至 Xamarin 測試定域機組。通用 Windows 平台和 iOS 的組建定義都一樣,只要的稍有不同的步驟,以管理像是簽署憑證的詳細資料。和後端的 ASP.NET 程式碼,MyDriving 有簡單的定義,以執行 NuGet 還原、 叫用 MSBuild,以及發行到伺服器的成品。您可以找到的所有這些在組建定義中的 《 MyDriving 參考指南 》 第 10 章逐步分析 aka.ms/mydrivingdocs

部署代理程式

特殊任何定義的一部分是它的 「 要求 」,您可以找到在 [一般] 索引標籤的清單。要求的概念是,如果您嘗試在不符合這些需求的代理程式的組建排入佇列,小組可以提供您立即錯誤,而嘗試 hopeless 建置並讓您挑選透過組建輸出中的錯誤。因此,Xamarin.Android 定義會列出要求,就像 Xamarin.Android 和 Android SDK。相反地,iOS 的組建定義會列出要求,例如 Xcode 或 Xamarin.iOS。

如之前所述,Team Services 中的裝載代理程式 Windows 電腦,但只有 Mac 可以符合適用於 iOS 的要求。如何執行,然後取得這類的機器上執行的組建代理程式? 一種方法是使用 macincloud,服務是用於 MyDriving。沒有 Visual Studio ALM 部落格上的絕佳文章 (bit.ly/2ajHtIz),提供有關設定此功能的所有詳細資料。

另一個選項是您自己的 mac 上安裝代理程式「 部署代理程式在 OS X 」 上找到詳細的指示 (bit.ly/2azm136),但是讓我分享一些坐在桌謙虛 5 年 MacBook 在此處使用經驗。在該電腦上,我下載 OS X 代理程式並啟動組態。這會提示我輸入我的小組服務帳戶,後面接著從我的設定檔中的小組服務入口網站取得的個人存取權杖的 URL。權杖的 Mac 上的代理程式如何識別本身的 Mac 否則並不知道我的 Microsoft 帳戶。

一旦連接到 Team Services,我收到提示,以加入代理程式集區。例如,我剛剛 Team Services 與建立 「 內部 Mac 」 的代理程式集區一節中所示 [圖 7。一段時間後有我提交給代理程式在 Mac 上,此名稱代理程式會出現在小組服務,內凹中所示。

建立新的代理程式集區和新的代理程式連接 (插入) 之後的顯示方式
[圖 7 建立新的代理程式集區和新的代理程式的顯示方式連接之後 (嵌入)

連接代理程式,我做,請務必執行在 Mac 中,我可以互動方式或作為服務執行。先前所述的 「 部署代理程式在 OS X 」 頁面會描述這些。我再 Team Services 中建立 Xamarin.iOS 組建定義,並選取 [我的 Mac 型代理程式佇列的組建 (我也選擇此組建定義的一般 |預設代理程式佇列設定)。最後,我排入佇列組建,以透過 Team Services 和 — 就是這麼簡單 — 我看我 MacBook 上執行,如同裝載代理程式會看到 Team Services 直接組建輸出。

幾個秘訣和注意事項

  • 請記住,大部分的專案必須封裝還原步驟早期的組建定義,例如 Xamarin 和.NET 專案的 NuGet 安裝程式步驟和 npm 步驟 Apache Cordova 專案中。建置錯誤會提醒您這個情況 !
  • 根據預設,您將加入至組建定義每個步驟會有其控制選項 |發生錯誤時繼續,並永遠執行未核取的方塊。正在檢查的第一個方法,此步驟不是實際的重要後續步驟中,並不應該使整個組建失敗。第二個表示不論其他步驟會發生什麼事應該一律執行此步驟。例如,您可能需要複製任何成品所建置,即使部分並未取得內建,定義結尾的步驟,或您可能會永遠執行特定的清除工作。
  • 當您管理您自己的組建代理程式時,它負責保持最新防毒軟體。建置錯誤通常會告訴您是否有某處顯示版本不相符。
  • 請務必檢查選項 |若要將 bug 指派給任何已認可觸發失敗的 CI 組建的程式碼的組建定義中的 [失敗] 方塊上建立工作項目。您也可以用來自訂您的程序,如果您不想只依賴工作項目 Team Services 市場中找到其他通知-和電子郵件相關的工作。
  • 有了解您自己的建置擴充功能? 簽出的文件 bit.ly/2avgl97

展望未來

正如本文稍早所述,組建是何種轉換原始碼,到發行管線 (即使只用於測試) 的其餘部分所需的成品。本系列文章將探討如何定義,並可能自動執行任何其他步驟,所必須執行之間的組建和客戶取得您的應用程式和服務時,這是 Visual Studio Team Services,發行管理功能。幸運的是,大部分的了解有關組建定義也適用於發行定義,因為後者會也設定成使用獨立的步驟。這會帶您曾經接近全自動化的發行管線。


Kraig Brockschmidt 擔任 Microsoft 的資深內容開發人員,並著重於運用於行動應用程式。 他寫過的 「 使用 HTML、 CSS 和 JavaScript 程式設計 Windows 市集應用程式 」 (兩個版本) 上的部落格與 Microsoft Press kraigbrockschmidt.com

由於閱本篇文章的下列技術專家︰ Andy Lewis
Andy Lewis 寫入做為 Microsoft 的資深內容開發人員涵蓋區域,包含 Visual Studio Team Services、 TFS 和組建。他是熱衷於透過設計與內容整合的 web 應用程式中建立功能強大且滿足使用者經驗。