• 發行項

2016 年 8 月

第 31 卷，第 8 期

本文章是由機器翻譯。

DevOps - 將 DevOps 套用至軟體開發專案

由 Willy-peter Schaub, ，Wouter de Kort , ，Mattias Sköld |2016 年 8 月

「 DevOps 是值的聯集的人員、 流程和產品連續傳遞給我們的使用者 」。— Donovan Brown 活頁簿，「 DevOps 上 Microsoft 堆疊 」 (Wouter de Kort，2016年)。

每個 DevOps 之旅開始了解您想要轉換為基礎的學習且連續提供值的文化特性的解決方案。本文的目的是共用的經驗，我們實作我們開發自動的發行管線的探勘期間所蒐集使用者接受度測試和生產環境。我們將引導您透過自動化的發行管線，您可以採用 「 現況 」 或發展出對您的需求。

那麼我們為何決定利用 DevOps？ 當我們開始掌 「 原因 」 （目標），「 什麼 」 （功能） 和 「 如何 」 （技術、 程式碼） 建置擴充功能，我們所需的文化特性，以及可讓我們建置、 測試、 發行和監視的延伸模組的快速發展及成長系列的環境。DevOps 的承諾，我們鼓勵我們瀏覽，以及採納的程序和 Visual Studio Team Services (簡稱 Team Services) 所提供的工具。我們自我組織及獨立的小組已獲得授權，以形成文化特性與管線，以發行週期的時間從減少混亂，出錯且牽涉大量手動操作天分鐘的時間。類似的故事和說明管線被告知這一期的另一個發行項 (「 程式碼中的客戶︰ 瀏覽行動運 」）。

如果您熟悉 Ranger，我們會在內部和外部的工程師使用產品小組提供專業的指引、 實務經驗和填滿間距解決方案開發人員社群的社群。它是後者，間距 — 讓我們興奮和認可至延伸模組。

擴充功能提供您的擴充性與整合的體驗 Team Services 和 Team Foundation Server (TFS)。擴充點包含工作項目表單、 建置和發行工作、 儀表板 widget、 功能表、 Agile 和其他的中心。這可讓您提供的填滿間距解決方案，到混色和增強產品、 UX 和產能。

典型的延伸組成一組 JavaScript、 HTML 和 CSS 檔案中所示 2015年部落格這 P Schaub，由 「 延伸 101-嘗試以視覺化方式檢視主要處理流程 」 (bit.ly/28Yfj7A)。一或多個 JSON 資訊清單檔案會描述基本資訊、 包含的檔案和延伸模組所提供的貢獻。開放原始碼資料夾管理延伸模組範例，可讓您快速從 Web 您 Team Services 來源儲存機制中建立資料夾，而不需要複製儲存機制在本機或安裝額外的工具，請參閱。

JSON 型資訊清單中，預設情況下呼叫 vss extension.json，說明每個延伸模組。為求一致，我們已經選擇来根據所有未來的擴充 Team Services 專案範本和 TypeScript 我們 JavaScript 程式碼。節點封裝管理員 (NPM) 可用來下載外部相依性，例如 TypeScript IntelliSense 所需的類型程式庫。我們運用 NPM 能夠定義一組基本的指令碼來初始化開發環境。其他的一致性可確保該小組成員可以輕鬆地在小組之間移動，可以調查和更容易解決問題。它可讓週期較短的時間 ！

手動發行延伸模組

如果資料夾管理儲存機制複製到本機開發電腦上時，可以快速地封裝，並手動發佈到您的 marketplace 帳戶的擴充功能。方法如下：

  • 使用 NPM 指令碼工作執行程式 (bit.ly/28Qmktu) 或是從命令列執行的命令。
  • 開啟方案並執行安裝程式工作︰ npm 執行安裝程式。這會下載 NPM 套件、 初始化所需的 TypeScript 類型，並放到正確的位置中的外部相依性。
  • 使用 Visual Studio 來編譯 TypeScript 檔案並產生輸出 JavaScript。
  • 執行封裝的 NPM 工作，以建立專案中的資訊清單為基礎的輸出 VSIX 檔。
  • 將產生的 VSIX 上傳至服務商場或執行執行的 npm 發行至自動封裝和發行您的擴充功能。

但首先，有些背景。Team Services 組成隔離的帳戶。服務商場是全域和組成的發行者，並建立和管理組件庫發行者 （您）。副檔名是發行為私用，且明確地分享小組的服務帳戶。或者，延伸可以發行成公用一旦經過驗證，讓每個人都可以看到該。我們強烈建議您永遠不會發行這個或其他的範例擴充功能，為公用以避免令人困惑，可能不正確的 ux。

若要發佈您的擴充功能，請確定資訊清單中的 [發行者] 欄位符合您的服務商場發行者的名稱。如果您的發行者不由 Microsoft 驗證，您可以只發行為私用擴充功能。若要發佈您的擴充功能，從命令列或 NPM 工作執行程式，您還必須授與權限來管理您的服務商場發行者的個人的存取權杖。請參閱文件，而 [發行擴充至應用程式] (bit.ly/28SDsOM)，如需詳細資訊。

自動化的建置及發行管線

擴充功能和修訂的系列增加時，這些看似簡單的手動步驟將迅速成為個費力且容易出錯。因此，我們會啟動工作自動化的管線，使用指令碼及建置工作自動化的手動步驟。

您可以使用 Windows PowerShell 及命令列建置封裝的延伸模組資訊清單，然後修訂版本號碼，如所示的工作 [圖 1。這會更完整說明文章中的 「 我們第一個步驟的採行運時建置 Visual Studio Team 服務延伸模組 」 (aka.ms/t0wfh6) — 簡單且有效 ！

[圖 1 Windows PowerShell 建置工作 （頂端） 和命令建立工作 （下方）

工具 Windows PowerShell
Arguments cha-命令"(Get-Content vss-extension.json).replace('0.0.1', ('%BUILD_BUILDNUMBER%').replace ('SampleData'，")) |Set-content vss extension.json"rt
 
工具 tfx
Arguments 擴充功能發行 – 語彙基元 $(PublishExtToken) – 覆寫-檔案 $(ManifestOverrideFile) – 共用-與 $(SharedAccounts)

或者，您可以使用組建和發行延伸模組的工作來微調您建置發行的程序。本文的其餘部分根據此延伸模組。

讓我們探索我們如何使用擴充功能的組建和發行工作和實作的所有其他延伸模組專案藍圖。每個延伸模組中的擴充功能部署的第一個階段的隔離 Team Services 帳戶啟動其之旅。發行管理會將這些階段稱為環境。因此，我們要呼叫它的開發 (DEV) 環境。然後會在執行一系列的設計、 撰寫程式碼，在不同的使用者與產品擁有者接受 (BETA) 環境中的功能、 UX 和效能驗證。類似於開發環境，這是隔離的團隊服務帳戶，並擴充功能部署的第二個階段。一旦副檔名符合我們的定義完成 (bit.ly/28PLYyi)，它會部署至 Marketplace，以供其他人。您可以辨識的開發人員 → beta 版 → PROD 階段發行管線逐漸成形。

若要準備擴充功能專案自動化的管線，我們建議下列變更延伸模組資訊清單中所示 [圖 2:

  • 設定您的版本 0.0.0 和您的發行者為空字串 ("")
  • 標示為私用擴充功能 (公用︰ false)
  • 移除 galleryFlags 屬性

[圖 2 資訊清單檔案擷取

{  "manifestVersion": 1,
  "id": "FolderManagement",
  "version": "0.0.0",
  "publisher": "",
  "name": "Folder Management",
  "description": "Quickly create a folder in your Visual Studio Team
    Services source repositories from the web. No need to clone the
    repository locally or install extra tools.",
  "public": false,
  "icons": {
    "default": "images/VSO-Folder-196x.png"
  },
  "categories": [
    "Code"
  ],
  snipped rest of manifest file ...
}

這些值就會更新發行部署期間，擴充功能不部署或不小心公開，可確保預設值。

 採用一致的命名慣例，將可簡化各種環境可追蹤性。比方說，您後置詞識別碼與您的環境版本期間，如果 FolderManagementBeta 會在測試環境中執行的資料夾管理擴充功能。

連續整合 (CI) 是可讓您在原始檔控制儲存機制中擁有最新的程式碼的實際執行組建的作法 (bit.ly/28OtZ8K)。這由自動化建置和測試每個認可上執行。

我們擴充功能專案通常會儲存在 Team Services 託管 Git 儲存機制，或在 GitHub 上的開放原始碼專案，例如資料夾管理延伸模組。管線的開頭使用每個認可對儲存機制，觸發的組建定義，然後再建置 VSIX 擴充功能套件，將它部署至開發、 測試和生產環境的環境的發行定義觸發程序。

中所示 [圖 3, ，請確定您啟用連續整合和 （選擇性） 若要減少執行組建的批次變更。

組建觸發程序
[圖 3 組建觸發程序

精明的讀者可能已經注意到，我們 CI 組建輸出 VSIX 套件，並不會複製原始程式檔副檔名。執行此作業的原因是傳送管線的基本主體之一︰ 建置一次，一次。不需要編譯和封裝延伸模組檔案，在每個部署步驟，我們封裝一次使用不同的組態，每個環境管線的開頭。我們要肯定我們將完全相同的延伸模組部署到每個不同的環境。 

版本控制您建置和擴充功能的工作很重要。在 Team Services 中，最新版本為準。如果您安裝一個公用和相同的擴充功能的 beta 版本 Team Services 帳戶時，它必須清楚哪一個版本將會啟動。

版本控制有哪些選項？ 小組開發人員工具可讓您使用任何三個部分的版本號碼做為您的擴充功能。是，為了簡化和清除追蹤能力，我們決定使用 Build.BuildNumber 做為我們的版本號碼，如所示 [圖 4。

組建編號格式
[圖 4 組建編號格式

或者，您可以使用查詢延伸模組版本工作中，能讓您從 marketplace 取得目前的版本，並遞增每次發行時的擴充功能的特定組件發行的版本號碼的進一步控制。同時也降低服務商場版本與 Team Services 中的成品之間可追蹤性，它提供更簡潔連續編號朝您市場的客戶。

該如何自我測試？ CI 組建也是不錯的起點，以執行單元測試等項目。資料夾管理延伸模組不使用任何單元測試，因為所有的邏輯將小組服務 REST Api 的呼叫。其他擴充功能，例如倒數小工具 (bit.ly/28PTCag)，包括單元測試驗證邏輯來計算的時間差異。這些單元測試會執行組建的一部分。我們想要在未來新增其他自動化的測試的 Selenium Web 測試。這可不只是執行的單元測試，但也將 UI 測試自動化。

[圖 5 顯示組建步驟。NPM 相依性安裝到使用 npm 安裝 (1)，安裝指令碼處理 npm exec 工作。或者，您可以使用 NuGet 和 NuGet 還原活動。Visual Studio 建置工作 (2) 然後建置方案，後面接著封裝延伸模組工作 (3) 而產生的 VSIX 擴充功能封裝。

組建定義
[圖 5 組建定義

（選擇性） 您可以設定 「 發行者 」 和延伸模組的識別碼、 標籤與名稱覆寫的資訊清單的值。管線只會設定版本號碼 (4) 組建的一部分，將它設定為要確定，管線的每個執行個體可以唯一識別和追蹤的組建編號。

什麼是 PowerShell 指令碼工作？ 在撰寫本文時，需要下列指令碼來擷取版本資訊 (未來版本的延伸模組開發人員工具，建置工作 [bit.ly/28R0oMh] 會讓指令碼已過時):

$bldVerD =("$env:BUILD_BUILDNUMBER").replace("$env:BUILD_DEFINITIONNAME","").Trim();
Write-Verbose "Extracted buildVersion $bldVer";
Write-Host "##vso[task.setvariable variable=ExtensionVersion;]$bldVer"

連續傳遞是能夠使用 CI 的輸出，以建置並自動將新良好的組建部署至一個或多個環境 (bit.ly/28PWsfk)。沒有連續傳遞與連續的部署之間的些微差異。後者是在單一環境。小型小組可能只會實作連續部署，因為每項變更將直接移至生產環境。連續傳遞移動程式碼透過數個環境中，最後在實際執行環境，其中可能包含自動化 UI、 負載和效能測試和核准一路冒。

開發環境的部署完全自動化，並經常發生。這表示每個成功的 CI 組建部署到開發人員，而不需要手動步驟。中所示 [圖 6, ，開發人員成功之後，部署到測試環境之前要求核准前。這個階段是由專案負責人或專案經理核准。最後，還有公用發行至生產環境前的核准步驟。這需要專案組長和專案經理核准。為了簡單起見，我們選擇使用只有核准前步驟自動化後的核准步驟，因為沒有理由讓我們來核准部署後步驟，並不將部署到下一個環境。

釋放觸發程序
[圖 6 釋放觸發程序

[圖 7 顯示發行定義中，將 VSIX 擴充功能封裝部署到三個環境。第一個環境中，開發人員 (1)、 擁有和管理小組建置擴充功能。延伸模組會部署為私用和共用開發沙箱帳戶。

發行定義
[圖 7 發行定義

一旦發行測試和核准，第二個環境，也就是 beta 版會繼續進行部署 (2)。做為私用和共用的使用者接受度沙箱帳戶仍將部署延伸模組。

一旦使用者接受度測試已完成並認可，變更 「 發行者 」、 將可見性設定為公用，並部署至 marketplace 的延伸模組會繼續進行部署 (3)。

發行延伸模組工作 (4) 是部署程序的核心和管線的推手。此工作會更新 VSIX 檔案解壓縮內容、 更新的設定值，以及壓縮所有檔案。工作然後將其部署到已設定的服務商場發行者帳戶，例如 alm ranger 發行者設定測試環境中，如所示。

延伸模組識別碼標記 (5)，而且名稱會覆寫以確保我們在每個環境中，開發人員和 beta 版的延伸模組會自動共用開發和使用者接受度測試小組的服務帳戶與執行的擴充功能的唯一執行個體，而且開發人員和 BETA 版本都是私用。

您需要的個人存取權杖 (6) 來發行延伸模組使用發行延伸模組的工作或命令列。安全地儲存權杖，您可以建立服務商場的團隊服務連接。連接會定義為索引鍵/值組，其中的重點是您連線的名稱和值是存取權杖。

您應該探索的其他工作包括︰

  • 查詢延伸模組版本︰ 檢查已發行的延伸模組的版本號碼的市場。版本可以儲存在變數中，管線用來建立新的版本中，例如遞增的主要、 次要或修補程式版本號碼。
  • 安裝擴充功能︰ 部署至 Marketplace 的延伸模組，而不需要安裝列入考量。
  • 共用延伸模組︰ 共用指定之帳戶的私用擴充功能。

此時，管線一致地建置、 套件，並更新擴充功能，更重要的是，保護環境免於來自常見的錯誤。建置失敗的範例是 TypeScript 程式碼中有錯誤時，或者如果有遺失的檔案。VSIX 無效，如果環境的存取會受到限制，或其中一個核准者會拒絕發行時，部署將會失敗。

總結

有自動化的建置發行管線之後，您可以加速開發程序、 減少人為介入，所導入了，更重要的錯誤、 發展您的解決方案，以及測量和學習，持續改善透過連續的反映。

不過，這是另一天的主題。

自動化的 CI 組建和 CD 管線已分鐘的時間，以降低天的手動和容易發生錯誤的延伸模組建置發行程序。它是 invigorating 的經驗，並可讓開發團隊將重點放在真正重要的時間與精力。

如下所示的 DevOps 做法可以套用至您的專案，以及。Team Services 可讓任何語言的目標平台，包括內部、 雲端、 混合式雲端和行動 DevOps。功能可讓您規劃、 版本、 建置、 部署和監視您的應用程式，Team Services 具有您將了解變成使用一種軟體所需的一切。有了這項資訊之後，我們很高興看到社群建立，用來增強小組的功能，因為在開始冗長的 DevOps 之旅的擴充功能。

DevOps 資源

 

Willy-peter Schaub 是 Visual Studio ALM Ranger 在 Microsoft 加拿大卓越中心的資深專案經理。 他的部落格位於 blogs.msdn.microsoft.com/willy-peter_schaub, ，，您也可以關注他的 Twitter: @wpschaub。

Wouter de Kort 是 Microsoft 在荷蘭他能協助公司在 Ordina 停留在軟體開發的技術最前線的主要顧問。 在他的部落格 wouterdekort.com。您也可以關注他的 Twitter: @wouterdekort。

Mattias Sköld 是在 Sogeti 瑞典 DevOps/ALM 教練協助客戶提升他們的軟體作法，以及推動採用內部 ALM/DevOps Sogeti 最佳作法。 在他的部落格 mskold.blogspot.com ，您可以關注他的 Twitter: @mattiasskold。

感謝以下的微軟技術專家對本文的審閱: Donovan Brown、 Jess Houwing 和精神史密斯