2017 年 1 月

第 32 卷,第 1 期

本文章是由機器翻譯。

行動 DevOps - 透過發行管理將複雜的部署自動化

Kraig Brockschmidt |2017 年 1 月

快樂的片語,「 出貨後 」 會宣告您要產生,例如行動應用程式和與其相關聯的後端服務的任何軟體已準備好進行部署的客戶或,因為它說 」 到實際執行環境。 」 不過,完全,沒有軟體到該點嗎? 我在這一系列的最後一篇文章中 (msdn.com/magazine/mt742871),我探討了如何建置會產生送入發行管線的成品。該配套的成品,稱為 「 發行 」,就是什麼再經歷任何數目的測試以及其他處理序中所示**[圖 1**,在實際執行其之旅。DevOps 活動大量事實上,涉及到任意數目的環境中某些測試會有執行,然後沿著該版本,管線的下一個階段以及領導版本的部署。

管理發行組建與公用部署之間發生
[圖 1 管理發行會在建置和部署公用之間發生

發行程序可能涉及大量的不同的測試,不一定同時執行,以及它可能也需要不同的電腦和裝置。它也可能包含直接由人類吃午餐並離開辦公桌晚上和週末的核准。如此一來,透過完整管線取得發行所需的時間可能很輕易地幾天。同時,開發小組會繼續運作的後續版本中,程式碼認可至來源儲存機制,因此觸發產生成品饋送至適當的管線的多個組建其待處理項目。

管理多個管線完成所有這些成品的流程很容易就成為複雜又吃力的工作,因此發行管理工具在 Visual Studio Team Services (VSTS) 和 Team Foundation Server (TFS) 是 Microsoft 運堆疊中不可或缺的一部分。

表面上,發行管理系統管理支援,大部分看起來,並因此可能不會做為 Microsoft 運堆疊的其他組件有趣的技術。但在 DevOps 中其他項目,例如發行管理基本上是當做要驗證您可以手動執行,在此情況下的步驟清單開始從建置/CI 階段成品已經準備好部署至後續的環境的作法。清楚地定義這些步驟後,一旦 — 時將成品部署到特定的環境,測試執行並將成品移到下一個階段的準則,您接著可以使用工具,以累加方式自動執行這些步驟。

在許多方面,管理發行很像自動化組建,設定不同之處在於發行管理的輸出是正確的人員可以取得它們的地方的組建成品的部署。最終,部署就是如何在原始程式碼中所包含的值實際上正在傳遞給客戶,這當然是軟體開發程序的重點 !

環境、 管線和管理的複雜度

雖然圖中的**[圖 1**顯示只有兩個 QA 階段 — 一個內部使用,一個外部 — 可以真的有任何數目的階段。這是因為不同形式的測試需要部署到特定的環境,這些測試可以實行。環境是只是特定組態的硬體、 軟體和適用於想要的測試或使用案例的資料。以下是一些常所討論的開發作業的內容︰

  • 執行單元測試、 整合測試和 UI 測試的電腦通常是自動化的測試環境,通常使用模擬 (mock) 資料、 測試服務和設定不同的負載和壓力測試伺服器的一部分。
  • 類似設定的手動測試環境通常是在專用的測試小組完成其工作。
  • 預備環境會用來部署應用程式和服務 (例如升級的測試)、 完整生產前測試,並包含 alpha 和 beta 版測試客戶的部署。這個環境可能會以唯讀方式,運用即時資料和服務,或使用預備版本完全模擬即時活動。這也是您可以在此測試您的當機和報告系統的遙測,並確定它們要產生您想要的資料。
  • 公用的生產環境,最後,使用公用的即時資料和服務,當然,是,您最後會摘要的即時遙測資料收集到後續版本。

您當然可以定義您想要根據驗證需求的任何環境。無論如何,如何建置成品旅行,透過這些階段和環境 — 並套用哪些測試位置 — 一次所定義的發行管線,而且您可以針對不同用途的作業中任意數目的不同路由。行動應用程式和後端服務,您必須 all along 方法的多個部署目標,不同的模擬器或裝置的伺服器陣列,臨時伺服器,依此類推。您也可能透過唯一的只是基於測試目的管線部分的版本。公開發行,Google Play 的 「 首展追蹤 」 功能 (bit.ly/2b7lh8j) 也可讓您發行新版應用程式的客戶限制百分比 — 即基本上是另一個實際執行環境,因此,您可能必須針對該追蹤的個別的發行管線。

版本的功能?

「 發行管理 」 一詞清楚表示 「 釋放 」,以某種方式管理。版本是您想要瀏覽一連串的驗證,以及部署至一個或多個環境的組建成品的特定組合。這些成品 (包括其他資訊和中繼資料) 永遠通過管線做為一個單位,無論任何後續變更原始程式碼儲存機制以及組建可能會觸發這些事件,因為每個集合的組建成品是唯一且蓋的完整版本號碼,例如 1.2.8.12,其中最後一個數字是組建。這類版本控制可讓您完成端對端稽核,回正確的組建,進而確實的原始碼儲存機制中的變更集,會在發行管線內發生追蹤的所有項目可以。

在 DevOps 中用語中,然後 「 啟動版本 」 表示送入發行管線可敬的組建成品的單位。[圖 2說明程序可能如下所示︰ 使用專案待處理項目進行通訊,小組適用於一系列的驗證檢查,不論自動化,拒絕發行,或讓它繼續進行下一個階段,最後到生產環境。

組建成品的單位流經出爐到生產環境的各種專案關係人
[圖 2 單元的組建成品流經出爐到生產環境的各種專案關係人

如之前所述,您當然可以有任意數目的測試和預備環境和多個實際執行環境 (正如使用 Google 首展功能)。發行程序可能需要相當長的時間,您可以選擇僅一次一週或每月一次部署到生產環境。在此同時,仍然要透過管線的某些部分來執行其他版本可能部署至 beta 版測試人員每週取得每個月的實際執行版本的意見反應。您或許也想来移至測試管理員],並可能經過一系列的快速、 自動化的測試,以提供持續的意見反應給開發小組的每個組建的每日組建。您隨時向上和向下圖中,發行前版本的頻率可以簡單地說,變更**[圖 2**。

因此,發行管理是指可以簡單開始,並從該處成長。這個練習中,最簡單形式其實是您可能已經完成︰ 您建置應用程式封裝、 將它部署至裝置 (臨時) 及播放與該應用程式,以確定其如預期般運作。接著,您將封裝上傳至儲存區,然後按 [發佈],並利用 ! 您剛才所完成的手動發行程序,將您的應用程式放入生產環境。

與文化特性的連續部署

如我在此系列中,第一篇文章所述 (msdn.com/magazine/mt767694),所有 DevOps 處理程序都開頭所完全清楚知道要在發行管線,或不自動沿著每個階段。您應該能夠描述所有您在簡單的文件中的程序,可以手動執行每個步驟。然後,您已準備好套用自動化,以降低成本、 改善可靠性與一致性,以及增加測試和部署的頻率。

在 DevOps 中的主要目標是讓應用程式或服務的最新的版本 — 包括只有次要變更的版本 — 流程儘快從來源儲存機制的客戶。全面自動化的流程稱為下移中緊密的連續部署 (CD),藉由持續整合 (CI): 每個認可至儲存機制時觸發新的 CI 組建,以及每次成功建置,這會產生新的成品的特定版本號碼的組合 — 新自動化的觸發程序發行程序。該發行程序接著執行所有必要的驗證該組合部署到生產環境之前。CD、 簡單地說,表示持續提供價值給您的客戶在最低的成本,具有最少 (如果有的話) 以及發行管線的人為介入。

不過,了解,雖然 CD 最佳化組建/CI 階段和部署至生產環境之間的發行管線,但它仍需要警覺的投入時間的人,讓它運作︰

  • 您的小組需要強式的程式碼檢閱程序,以避免不佳的程式碼一開始認可至儲存機制。
  • 您的小組必須具有自動化測試的高信心 — 建立哪些人 — 會攔截大部分的缺失,並防止聯絡客戶。
  • 因為沒有套件的測試很完美,一些缺失會到生產環境,因此當機報告、 遙測和生產環境中的客戶直接回應,必須主動監視您的小組。
  • 您的小組必須認可到快速分類和排列優先順序的問題和餵送開發待處理項目以便更正快速進入後續版本。
  • 問題也找出您的程式碼檢閱程序中的間距和測試涵蓋範圍,因此在開車增強功能。

簡單地說,CD 不是只需自動化發行管線︰ CD 是使用不斷改善您要如何傳遞值給客戶的意見反應的文化特性。

例如,Microsoft Azure 的文件中尋得azure.microsoft.com/documentation,管理在 GitHub 上的開放原始碼儲存機制內github.com/Azure/azure-content。沒有完整的 CI/CD 系統可使任何快速接受放入提取要求到儲存機制的變更一定要記得到生產環境。提取要求,不過,會仔細檢查 Azure 內容團隊在 Microsoft,以防止不正確或不當編輯完全放在儲存機制。接受變更,然後透過自動化的 CI/CD 管線適用於各種不同的驗證測試 (例如擷取不正確的格式和中斷的連結),並接著將內容發佈到即時網站。小組接著監視從 Application Insights 的遙測報告,連同客戶意見,並使用該資訊來改善內容、 改善驗證測試,並改善檢閱程序本身。

VSTS 中的發行管理

在最後一篇文章中,我會探討設定自動化組建利用 VSTS,取得已知的建置程序,從它建立組建定義並填入該定義是能夠執行必要的工作,以產生之成品的特定版本號碼為套組的組建代理程式。

VSTS 中的發行管理是類似的程序︰ 您建立發行定義指定如何部署至不同的環境的測試和驗證所要套用至它該組合。發行定義再送到版本的代理程式 — 適當地設定的機器,進行處理 (release 代理程式在相同的方式與組建代理程式管理,請參閱bit.ly/2coBQxx)。話雖如此,有一些重大差異組建,然後發行定義︰

  • 組建定義會產生可供測試和部署的成品。發行定義引導實際部署到環境以及執行測試。
  • 永遠的組建定義的運作方式與單一來源儲存機制。發行定義可以繪製從任意數目的組建定義,以收集發行成品。
  • 您通常可以設定全自動的建置在幾個小時。全面自動化的發行管線是一段時間,因為花費更多心力來建立基礎的自動化的測試和核准和登出的詳細資料。
  • 標準的建置完成會在幾分鐘的時間。完整版的程序,具有多個環境及核准手動步驟,將會花更長時間。如此一來,您將會監視並稽核發行您的管線中,在不同階段。
  • 發行定義支援前置和後置部署核准者,您將插入用手動控制在任一端的 [發行] 步驟中,以及明確的手動操作工作。一個簡單的範例使用一或多個預先部署核准者移到生產環境之前。VSTS 也可讓您使用群組為核准者,因此只有該群組中的一個人需要登出。一般情況下,您指派核准者的隨時想讓人所參與發行程序,也會導致保留的稽核記錄。

例如,假設我的 Xamarin 應用程式,在 VSTS,搭配四個 Git 儲存機制中的後端程式碼組建定義產生的後端成品和 ios、 Android 和 Windows 應用程式套件。簡單的發行程序 — 回應中所示的階段**[圖 2**— 可能如下,其中在管線中的任何時間點失敗將會取消發行︰

  1. 在建置成功執行單元和整合測試。
  2. 測試環境
    • 將應用程式部署到實體裝置上執行測試的 Xamarin 測試定域機組。
    • 將後端部署至本機的負載測試。
  3. 預備環境
    • 將應用程式部署至使用 HockeyApp 的 beta 版測試人員。
    • 將後端部署至開發用伺服器 (使用 beta 版測試人員) 在 Azure App Service 上執行。
  4. 需要由核准者檢閱 beta 測試人員提供的意見反應,並評估版的完備性。
  5. 生產環境
    • 將應用程式部署至 Google Play、 Apple App Store 和 Windows 市集。
    • 將後端部署至實際執行 Azure 應用程式服務。

請注意,再一次,此程序隻字未提自動化 — 它只是描述進行發行所需的步驟。因此,我可以開始建置利用簡單的步驟,例如部署和核准者登出發行定義。然後,當我放在一起的各種測試,我以累加方式加入提高自動化的步驟。(此外,此程序是基本上是什麼 MyDriving 專案設定 [aka.ms/iotsampleapp],但因為散發應用程式只能透過 HockeyApp 結束在步驟 3。)

就技術上來說,您可以包含測試和部署步驟,直接在 VSTS 中的組建定義。這已足以用來部署及測試在單一環境中時。當涉及多個環境,核准者,以及其他特定版本的步驟時,不過,您將需要更精細地控制 Release Management。

逐步解說︰ 將部署到後續的 Azure 環境

現在我要使用 Release Management,我已建立的 Xamarin 應用程式和 Node.js 服務從 Visual Studio 中的範本的主要處理序的逐步解說。Vsts,我建立了名為 MSDN Magazine Dec 2016 的 Team 專案,並加入其來源儲存機制中的專案。即使這些成品不做任何有趣的動作產生適當的成品,我可以遵循的發行管線,透過設定四個組建定義。(若要建立不同的後端專案類型的組建定義,請參閱 「 建置您的應用程式"[bit.ly/2cGbq7W] VSTS 文件,以確保您建立 Azure 部署的成品,並示範如何部署工作的組建定義。)

因為我有四個不同的套組的成品移至不同的目標,我最後需要四個版本的定義,但這裡開始就在後端。在 Team Services 入口網站中,我瀏覽至 Team 專案中,選取 [發行] 索引標籤,並按一下 [+ 新的定義。使用 Team Foundation Build,這時會出現的對話方塊 (撰寫本文時),只需幾個 Azure 相關的發行範本,針對 Azure 以外的任何目的地,包括應用程式存放區,只是開頭空白的定義。如我的後端,我可以使用 Azure 網站部署範本,然後按 [下一步]。這會顯示我選取我的後端的組建定義的成品 (您也可以使用 Jenkins 做為來源) 的來源設定對話方塊。我也選取代理程式佇列,並設定選項的連續部署,稍後再返回。

VSTS 然後顯示在編輯器中開啟發行定義**[圖 3** (依預設會有只在單一環境)。組織編輯器] 中,從左至右、 環境、 工作和工作詳細資料。首先,建立環境,並接著填入適當的工作環境是一般的工作流程。環境通常會有類似的步驟,因為您可以建立一個環境的工作,然後複製該環境以節省時間。+ 新增環境] 按鈕會提供這個選項。(您也可以建立中繼工作,您群組工作一起以建立新的單一工作,以變數,可用於建置和發行定義參數化的序列。如需完整的逐步解說中,請參閱在 VSTS 文件bit.ly/2c1X3fP。)

編輯版本定義於 Visual Studio Team Services
[圖 3 編輯發行定義 Visual studio Team Services

與組建定義,任何需要注意] 索引標籤會反白顯示為紅色 — 在**[圖 3**,我需要識別部署的目標 Azure 應用程式服務。在我的 Azure 帳戶,然後,我建立名為 kraigb MSDN1216 測試、 預備 MSDN1216 kraigb 環境和生產 MSDN1216 kraigb 環境的應用程式服務執行個體。我再回到 VSTS,並按一下右手邊 Azure 訂閱 (傳統),我便會在 Team 專案的控制台中的 [服務] 索引標籤旁邊的 [管理] 連結。我選取 + 的新服務端點,選取 [Azure 傳統出現的對話方塊,讓我輸入連接資訊。最簡單的方法與這個工作是在對話方塊中,前往 Azure 入口網站,並產生文字檔案,供下載,從中您可以複製-貼上值到 VSTS 選取發行設定檔連結。

需要建立這個連線,我回到發行定義中,會重新整理訂閱清單,然後選取 [我的新連線。我可以從該處重新整理的 Web 應用程式的位置和 Web 應用程式名稱控制項以選取 [我想要的應用程式服務執行個體。

因為我的測試環境的連接資訊的大部分相同我預備和生產環境中,我可以複製兩次的測試,並重新命名。當我用於生產環境進行複製時,不過我也自行設定為預先部署核准者和核取方塊,以便在等候發行時收到電子郵件。如此一來,我已插入的預備和生產環境之間的暫停時間。

開始發行

我現在有三個環境之間的基本部署管線︰ 測試、 預備及實際執行環境,其中前兩個部署會自動發生,而第三個受限於手動核准。若要手動方式啟動發行,我會按一下 + 發行版本定義和選取建立的版本中。這與在對話方塊提示**[圖 4**我選取組建 (從任何建置成功仍在 VSTS),使用中,我也可以控制環境之間的部署鏈結。請注意,測試環境中,部署會自動建立的版本,也就是當我按一下 [建立] 按鈕時。預備和生產環境中,同樣地,必須根據先前的環境中,自動部署因,當然,(例如測試),這些環境中的任何其他發行步驟成功以及任何必要的核准。

選取組建,並將設定部署手動啟動新的版本
[圖 4 所選取組建,以及設定部署手動啟動新的版本

我已經點按建立並發行開始,我可以瀏覽到要檢查其進度,該版本中所示**[圖 5**。

檢查進行中發行的狀態
[圖 5 檢查進行中發行的狀態

當我第一次建立此發行管線,使用 Node.js 後端時,我的組建定義未建立任何實際的成品,而發行失敗,因此,我將共用的。我檢查瀏覽至 [我的最新組建,然後按一下 [摘要] 頁面的 [成品] 索引標籤。一旦我加入必要 Gulp 工作上的快速入門指示產生輸出,一些真實bit.ly/2c1XhTY,這些成品都已準備就緒。

在我簡單發行管線中,我還沒有設定任何自動化的測試因此測試和預備環境的部署會很快連續,我可以移至這些網站,然後查看結果。任何項目部署到生產環境之前,不過,發行告訴我,「 預先部署核准處於暫止狀態為 「 生產 」 環境。核准或拒絕,「 您所見的**[圖 6**。我也會收到電子郵件提醒我的核准,VSTS 的相同版本網頁的連結。那里我按一下 [核准或拒絕的連結,以指出我決策、 加入註解、 延後至稍後部署或重新指派給其他人核准。在此情況下我按一下 [核准發行完成時,,我可以去看部署生產 1216 kraigb 環境的應用程式服務執行個體上。

核准或拒絕手動核准步驟
[圖 6 核准或拒絕手動核准步驟

[圖 6,為您所見,顯示單一版本的狀態。藉由按一下右上角的發行定義的名稱,我可以看到仍保留在 VSTS 中的所有版本的狀態摘要頁面。這是您以視覺化方式可以讓這個定義,管線中監視每個版本的進度和類似的檢視,就可以使用入口網站 (未顯示) 的左側瀏覽樹狀目錄中,按一下 [所有版本的定義位置。

持續部署

設定連續部署表示自動使用該組建所產生的成品建置成功後啟動發行。若要這樣做,我編輯發行定義,然後按一下 [觸發程序] 索引標籤,其中有選項可手動、 連續部署,並釋放排程。當我按一下連續部署時,我的來源成品,也就是我的組建定義的後端,然後在儲存發行定義。

現在我可以一直出 Visual Studio 中,以進行變更後端程式碼,並認可至儲存機制。因為我核取 [連續整合] 方塊中的後端的組建定義,這樣就會觸發新的組建,在 VSTS。該 「 建置成功後,它會自動觸發新的版本,因為我已經在發行定義簽入的連續部署。因此,具有 CI 及 CD 選項,我已設定完整的版本之間的管線的程式碼變更並部署至生產環境中,我指定生產環境中發行定義手動預先部署核准主體。

雖然此管線很簡單,我現在有穩固的基礎我可以擴建額外的步驟,例如執行任意數目的測試,只要將更多的工作加入至適當的環境中發行定義,並設定任何必要部署前後的核准。我也可以加入新的環境,將管線分成更多個階段。但不論多少工作或您加入的環境,基本程序將會相同如這裡,您所見。

逐步解說︰ 發行應用程式

後端版本中進行定義,我就可以建立三個版本的定義 iOS、 Android 和 Windows 建置的 Xamarin 應用程式。處理程序是非常就如同是在後端,只不過我開頭空白的發行範本和選取的平台特定組建定義。在發行定義編輯器中,我就依預設,沒有任何工作,所以我設定完畢後我想 (例如測試、 預先啟動並啟動,以顯示您可以使用任何您想要的名稱) 的環境,我上按一下 [+ 新增工作,然後從出現的對話方塊中選取一個。

Android 應用程式中,我的部署來說,如下所示︰

  • 測試人員: 使用建置工作編譯任何測試程式碼,然後使用 Xamarin 測試定域機組工作部署在內的.apk 檔和測試程式碼,我已選取的裝置上自動執行這些測試。(當然,測試定域機組帳戶是使用服務所需)。
  • 預先啟動︰ 使用 HockeyApp 工作 VSTS 商場我第一次安裝讓它出現在 [新增工作] 對話方塊。我可以也 HockeyApp 建立帳戶與用於其服務設定的預先啟動客戶清單。
  • 啟動︰ 若是 Android,我從 Marketplace 安裝 Google Play 工作,然後從 (這裡您會看到發行、 升級和增加導入的工作分開) 的新增工作對話方塊進行選取。這表示,當然,我已設定自行向 Google 開發人員。

我的 iOS 和 Windows 發行定義,我仍然可以使用 Xamarin 測試定域機組和 HockeyApp,但這些平台不提供可自動部署至其個別的存放區。在這些情況下,我啟動環境沒有任何工作。相反地,我只是已預先部署核准者指派給該環境。該人員會負責評估前測試人員的意見,並可以接著外移到適當的入口網站來上傳的實際執行應用程式。

預先啟動使用 HockeyApp 分佈

HockeyApp (hockeyapp.net) 是功能強大的 DevOps 服務 iOS、 Android 和 Windows 應用程式之前和之後啟動。後續的啟動 HockeyApp 提供損毀的問題回報,使用量資料和使用者意見反應,將更新的文件中討論。預先啟動時,HockeyApp 提供這些相同的服務,且能夠快速且輕鬆地測試應用程式部署到任何數目的測試人員,無論他們使用的哪些裝置和 where 不論它們是在世界。它也可讓您組織及管理您的測試人員在有許多種,因此,您可以輕鬆地控制哪些群組取得哪一個版本中,以及何時。

預先啟動 [發佈 (bit.ly/2cxruZ8) 透過在其裝置安裝的軟體測試人員 HockeyApp 用戶端的運作方式。當您準備發行新的測試時,您將它上傳是手動或透過部署中的步驟 VSTS HockeyApp 入口網站。您的測試人員則會收到電子郵件說出新的版本可用,且 HockeyApp 用戶端會顯示可用的版本,您可以使用各種行動平台的側載功能安裝。

展望未來

在這一系列文章,我現在已經討論過原始檔控制、 組建和發行管理,讓您可以建立完整發行管線跨任意數目的可容納任何其他測試的環境,您可能需要的核准步驟。如此即完成您的程式碼與客戶之間的所有核心連接。現在,還保留,是了解如何透過應用程式和後端服務監視這些客戶接聽,然後若要深入了解各種測試選項您可以採用,包括 Xamarin 測試定域機組。

CodePush

因為部署程序很簡單,只要適當的伺服器上傳新成品的連續部署是最常用來與 Web 應用程式和服務。行動應用程式,自動部署是只能用於應用程式發行至 Google Play 商店,而不是在 iOS 和 Windows 的存在,因為兩者都需要某些手動步驟。此外,核准的應用程式更新可能需要長達兩週,這很難甚至是簡單、 多層比較不重要 bug 修正取出給客戶。幸運的是,使用 Apache Cordova 及原生回應所建置的應用程式可以利用 Microsoft CodePush 服務 (在撰寫本文時的預覽) 的捷徑的程序。CodePush 可讓開發人員會自動將 HTML、 CSS、 JavaScript 和靜態的成品,如映像部署到客戶裝置的直接。服務運作方式是讓應用程式查詢 CodePush 便會套用至執行中應用程式,因此不需要透過應用程式的更新儲存的核准程序。(這種做法被允許的應用程式存放區原則,提供應用程式的原始目的並不會變更)。 如需詳細microsoft.github.io/code-push


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

由於閱本篇文章的下列技術專家︰ Alex Homer
Alex 這本書是 Microsoft 的技術製作者具有 eschewed 從家中正點 Derbyshire Dales 英國 Redmond 的樂趣。他的文章中的其他字元都是他的兩個貓的參與。