• 發行項

2016 年 8 月

第 31 卷，第 8 期

本文章是由機器翻譯。

行動 DevOps-從客戶的程式碼︰ 探索行動 DevOps

由 Kraig Brockschmidt |2016 年 8 月

歷程記錄的標準，來撰寫程式碼很簡單。今天我們喜歡大幅增長功能強大的工具，例如 IntelliSense、 自動完成語法標色、 反白顯示錯誤和透過像堆疊溢位的社群支援。我們也喜歡從不斷成長的儲存機制格外有用的程式庫和工具，其中許多免費。但有大的間隔 — 一的差距，您可能會說 — 之間只做撰寫程式碼和開發行動應用程式，為客戶提供最高值的使用，且在您的企業成本最低的值。

根本就是當運基本上都是總稱為各種作法可協助您橋接的差距。我說 「 各種作法 」，因為有許多方式來建置該橋接器。有不同的方式定義的程序本身，並有許多不同的工具，可協助您進行通訊和管理這些程序與相關的所有人員 — 包括學習直接從您的客戶。這麼一來，整個運空間有時候看起來很混亂，使用太多選擇和太少的清晰度。

幸運的是，我將探討在這一系列的文章中，Microsoft 現在提供解答︰ 完整端對端堆疊可運用於行動應用程式和其相關聯的後端。此顯示的堆疊 [圖 1, ，Visual Studio、 Visual Studio Team Services，以及 Team Foundation Server，以及 Xamarin 測試定域機組、 HockeyApp、 Application Insights 和 CodePush 組成。

[圖 1 的 Microsoft 運堆疊行動應用程式與後端服務的主要元件

工具或服務 運與用途
Visual Studio (bit.ly/25EVbAw) 應用程式、 服務和測試程式碼，以及診斷和原始檔控制與整合的中央開發工具。
Visual Studio Team Services (bit.ly/1srWnp9) 雲端裝載敏捷式軟體開發規劃工具，原始檔控制、 建置測試服務和發行管理的服務。（請注意，計劃工具不會涵蓋在本系列）。

Team Foundation Server

(bit.ly/1TZZo9o)

 內部功能相當於 Visual Studio Team Services，可完全自訂的伺服器以及這些實體機器的完整控制權。

Xamarin Test Cloud

(xamarin.com/測試-雲端)

 自動和手動測試 （包括不會寫入與 Xamarin） 的所有行動裝置應用程式的數千個可透過入口網站存取實際的實體裝置上。

HockeyApp

(hockeyapp.net)

 預先啟動應用程式散發至裝置的直接測試客戶 （不包含平台應用程式存放區）。也預先啟動和實際執行監視與自訂遙測、 當機分析和報告使用者意見反應。
Application Insights (bit.ly/1Zk9Qd3) 遙測、 診斷和後端服務的監視。

CodePush

(bit.ly/28XO7Eb)

 部署應用程式的更新 Cordova 和反應原生應用程式直接與使用者裝置不透過應用程式存放區。

此堆疊是適用於所有類型的行動應用程式︰ 撰寫單一的行動平台，撰寫使用 Apache Cordova 的混合式應用程式的原生應用程式和撰寫回應原生或 Xamarin 的跨平台應用程式。儘管如此，更 DevOps 不是孤注一擲的承諾。相反地，它牽涉到系統的鬆散結合的活動和作法，您可以建置以累加方式，加入您的企業製作行動應用程式的實際值。您也可使用新的專案，建置整個運管線撰寫一行程式碼之前。

我將在這一系列的方法是將焦點放在不同階段的 「 發行管線 」，並查看運堆疊的哪些部分派上用場。在此我的文章中，不過，我必須先建立某些必要的背景。首先我要說明什麼是發行管線，然後再識別涉及的活動，討論整體需要開發和工具和自動化的角色。接下來，我將探討 MyDriving 專案做為開發作業中動作的範例 （及您可以在本期文章 「 採行運時建置 Visual Studio Team 服務擴充功能 」 中找到另一個範例）。最後，將介紹 Visual Studio Team Services （Team Foundation Server） 中扮演重要的整體運本文中，設定為後續的發行項重要的角色。

發行管線

管線的概念是，針對任何特定版本的應用程式或其後端服務，其程式碼和其他成品必須以某種方式從流動專案的原始程式碼儲存機制至客戶的裝置和客戶存取伺服器。第一次上這些裝置和伺服器，執行階段問題 （當機），深入了解遙測和直接客戶的意見反應必須所有為所獲得的經驗，會釋放後續的磁碟機。

當然，這些動作不會發生魔術一樣。它會透過一系列不同階段認可至儲存機制，程式碼之後所示 [圖 2。這些階段包括︰

  • 建置/CI: 建置應用程式，並執行單元測試。連續整合 (CI) 表示認可至儲存機制觸發建置和執行這些程序自動化的測試。
  • 內部 QA: 執行任意數目的其他測試，並取得核准者登出。
  • 外部或預先啟動 QA: 讓應用程式的真實的客戶之前公開發行之後，應用程式和服務在真實世界的情況下測試和收集意見反應。此階段也可能需要額外的核准者登出。
  • 監視和學習，實際執行環境︰ 不論多少測試這麼做，客戶十之八九都會發現的問題建立公用應用程式之後 （也就是 「 發行至生產環境 」）。客戶會提供反應有效方式並不是什麼，並顯示其使用模式的遙測。

與相關聯的 DevOps 活動的典型的發行管線的階段
[圖 2] 的相關聯的 DevOps 活動的典型的發行管線階段

您會注意到在 [圖 2 ，我已標示為大部分的 DevOps 活動為某種形式的測試。事實上，它並不是什麼想成是測試每個活動的自動縮放。比方說，執行組建、 測試儲存機制，以及所有其他成品是否一定要的結構。執行診斷工具是一種探勘測試。收集和分析遙測方式來測試您的假設有關客戶如何實際使用應用程式。和核准者登出，如果不是直接的核取的一切都是正確的人會有哪些？

效能持續驗證

為不同形式的測試，之下 DevOps 的所有活動都存在驗證品質、 可靠性和應用程式所提供的值。另一方面，活動被設計成攔截或識別缺失，這表示任何會導致應用程式以滿足客戶的期望與不符合的項目。幾乎不用說，接下來，您採用的 DevOps 活動的頻率愈高，— 連續的話 — 您有尋找問題的先前版本的更好的機會。

DevOps 活動的設計也可以攔截缺失盡早在管線中最低的維修成本時 (在藍線說明 [圖 2)。很明顯地，成本移高得多，一旦發行應用程式及缺失是出在開啟，此時成本可能包括流失的客戶，損毀評價，甚至是非法 ！

將所有這放在一起，應用程式，為客戶提供最高值和最低成本這樣做，是因為什麼它們最終為企業帶來最好"藝術家 」。卓越的應用程式，只要說過，是很棒的藝術家。基於這個理由，我要開發作業視為連續的字詞的最大的意義上的效能驗證。哪些訓練、 作法、 rehearsals，DevOps 是軟體開發，而後續效能檢閱即將專業音樂家、 的運動員，以及其對應的欄位中的其他藝術家。它是如何知道與信任和監視什麼您要交付、 客戶和企業的完整值。

處理第一個，然後工具和自動化

在一系列有關 Microsoft 行動 「 開發維運工具堆疊，您可能認為接下來是以直接跳到這些工具，並啟動 「 執行 」 DevOps。但運與工具，或甚至自動化的任何項目才會開始。正在清除相關的程序和原則，定義如何應用程式和服務移動從您的開發人員的您的客戶落入開發作業的基礎。它是這麼簡單。很簡單，事實上，您當然可以定義整個發行管線在紙張上書寫下所需的步驟，以手動方式執行每個。

有時，這是最困難的部分的開始有效的 DevOps 之旅。在小組環境中，尤其是正嘗試移動快速，年輕的小組的發行管線可能包含的一大堆演變臨機操作的步驟，個別團隊成員 「 只要記住 」 來執行。這裡列出一些範例：

  • 執行組建
  • 執行一些測試
  • 右非程式碼成品都有各自的核取
  • 測試使用者收集意見反應
  • 張貼至適當的存放區的應用程式套件
  • 將服務程式碼部署到適當的伺服器 （開發、 暫存、 生產等等）
  • 從開發人員的 API 金鑰變更至生產環境
  • 推文的可用性
  • 更新您的網站上的產品頁面

短暫的開發反覆項目，與所有這些活動可以輕鬆地成為因此 enmeshed 小組的人發現就是都不實際寫入下任何地方的日常常式中，直到，不用說，有人外出渡假時，取得病假或離開公司 ！ 不僅如此，如果您所有的發行程序和原則只存在於人員心中，很難持續進行套用。它們不會改變取得密不可分的幾百個其他不相關而重要的工作。這太清楚危險，尤其是在單一監督可以是極大的災難的環境。

寶貴的時間來清楚識別所需的所有步驟，您可以定義可預測、 可重複且可稽核的處理程序。讓所有它的所有人都能存取的位置也很容易處理程序檢閱並修改，因為所有的相依性會顯示。這反而是套用工具及自動化的基礎。否則，就會像是在設立一大堆工業機器而不需要知道它您嘗試實際建置在第一時間建立 widget。

讓我們是很清楚。自動化並不是實際要件中任何發行管線，視每個步驟也可以手動執行。這包括更簡單，但是耗時的事情要傳送通知電子郵件。但是，手動程序是調整，容易發生人為錯誤，通常有冗長，因此讓人有點無聊，並將每個步驟放風險的競用的所有其他工作人力員工注意耗費資源。電腦，相反地，是非常適合在不斷重複和 mindlessly 瑣碎的工作，而不取得無聊或粗心。此外，也加入一些更多的機器，則在需求增加，以及當要求下，合格的人員雇用 （並引發） 比解除委任更簡單。

然後，自動化的目的是要同時降低成本並增加的頻率和程序的品質，因為它們定義，分隔開來的工具。也就是當您的處理程序和原則都有各自，然後以累加方式自動化不同的組件、 使用工具來強制執行原則，及透明及可稽核的形式進入的所有項目。當您這樣做，您釋出人力員工能夠專注於的區域並不容易處理的電腦，例如檢視和解譯使用者的意見反應，設計遙測層級，決定最有效的測試，並持續改善品質都有各自的 DevOps 活動的形式。

MyDriving 專案的範例︰

我們現在來看如何搭配 Microsoft 行動運堆疊來看看名為 MyDriving 已經工作專案，這樣所有的處理 (aka.ms/iotsampleapp)、 Scott Guthrie 在 Microsoft 建置 2016年所導入。MyDriving 是完整的系統收集和處理物聯網 (IoT) 資料透過複雜的 Azure 後結束，並提供透過 Microsoft Power BI 和寫入與 Xamarin 行動應用程式之結果的視覺效果。它建立成類似 IoT 專案的起始點，並包含完整的原始程式碼、 Azure 資源管理員部署指令碼和完整的參考指南電子書。

我的需求，MyDriving 發行管線特別感興趣。我會使用複數這裡的因為有四個︰ 一個用於部署至 Azure App Service，後端程式碼，各有一個在 iOS、 Android 和 Windows 的 Xamarin 應用程式。

以下是管線流程，包括目前未實作某些活動的概觀︰

  • 管理 GitHub 儲存機制中的原始程式碼 (bit.ly/28YFFWg)。
  • 執行組建的儲存機制，包括下列子步驟中使用程式碼︰
    • 語彙基元取代成必要的金鑰，視目標環境 （開發、 測試、 生產） 而定。
    • 還原必要的 NuGet 封裝和 Xamarin 元件。
    • 更新版本的名稱和編號。
    • 執行組建 （使用 iOS 的 MacinCloud 服務）。
    • （僅限應用程式）建立並簽署應用程式套件所需的行動平台。
    • （未實作）建置任何可用的單元測試專案。
    • （未實作）在測試專案中，任何測試失敗時失敗的組建執行測試。
  • 服務程式碼︰
    • 將已順利測試的組建輸出複製到開發用伺服器。
    • 從臨時伺服器部署至測試伺服器，並執行測試。
    • 如果成功，將部署到實際執行伺服器，重複執行的測試。
    • 監視服務，並取得使用 Application Insights 的診斷報告。
  • 所有平台上的行動應用程式︰
    • 將應用程式部署至 Xamarin 測試定域機組，並執行 UI 測試、 任何 UI 測試失敗時失敗的組建。
    • 如果組建和 UI 測試都成功，請將應用程式套件複製到開發用伺服器。
    • 部署應用程式從開發用伺服器以透過 HockeyApp alpha 測試人員。
    • （未實作）根據核准者登出，將部署到透過 HockeyApp beta 版測試人員的應用程式。
    • （未實作）在額外的核准者登出，請將應用程式推送至適當的應用程式存放區。
    • 監視與遙測和當機報告 HockeyApp 透過應用程式。

如您所見，這是簡單的功能需要在每個版本的清單。但請特別注意它描述需要發生的情況和識別的部分服務，但未指定人員實際執行的步驟。這是很重要，，因為沒有人會一律坐下來清單並手動執行每個步驟。事實上，這正是在早期的 MyDriving 發生什麼事 — 我們所做的手動組建等等，我們無法立即測試應用程式的人未授權者手。但是，同時與開發小組的程式碼撰寫工作，其他人著重於以累加方式自動化不同的步驟，直到整個自動化發行管線，已經建立。

類似的故事是告訴另一個發行項在本期 「 軟體開發專案來套用運 」。 請注意，特別是 < 建置和發行延伸模組 > 一節會完全什麼我討論過這裡︰ 它會寫出一份在發行程序中的確切步驟。本文其餘部分接著說明，作者就 「 我們邁向自動化的建置和發行管線。 」

Visual Studio Team Services/Team Foundation Server 的重要的角色

在 MyDriving 專案中，Visual Studio Team Services （簡稱為小組服務） 是用於管理和自動化發行管線與各種服務互動的中心 (請參閱 [圖 3)。因為 MyDriving 中所建立的開放原始碼專案，從一開始，使用雲端裝載的服務，例如 Team Services 並不是問題。如需其他案例中，組織可能不知道如何，或允許使用定域機組，案例 Team Foundation Server (TFS) 提供您自己的內部部署伺服器與相同的功能。在我的系列中，我將主要 Team Services 內容中運作，但是了解，則所有項目也適用於 TFS。

Visual Studio Team Services 儀表板 MyDriving
[圖 3 Visual Studio 小組的 MyDriving 服務儀表板

此處會列出這些核心功能 (請參閱 [圖 4 小組服務 UI 中的位置):

  • 原始檔控制︰ 裝載無限制的私人和公用來源儲存機制使用 Git 或 Team Foundation 版本控制 (TFVC)，或在 GitHub 上輕鬆地使用儲存機制。
  • Agile 計劃︰ 追蹤工作項目、 使用者劇本和報告等的看板上的共同作業等等。（請一次規劃方面並不涵蓋在本系列）。
  • 建置︰ 使用各種可用的工作，包括建置和執行測試專案 （適用於連續整合），並部署至 Xamarin 測試定域機組 (XTC) 所建立的服務程式碼和行動應用程式 (iOS、 Android 和 Windows) 的組建定義。
  • 版本管理︰ 定義具有選擇性手動核准的任意序列之間發生的任何工作建置及發行 「 環境 」，例如部署到 HockeyApp、 Azure 或應用程式存放區。發行管理會置中您要在任何環境定義，例如預備、 alpha、 測試和生產環境。

在 Visual Studio Team Services 功能的位置

[圖 4 的功能在 Visual Studio Team Services 中的位置

來說 Team Services 管線結尾是的點的應用程式傳送到其最終的指派環境 (請參閱 [圖 5)。之後，DevOps 主要著重於主動監視這些環境中的應用程式。這其中 HockeyApp 和 Application Insights 進入播放，以及任何其他機制您建立用來取得額外的使用者意見反應 (也顯示在 [圖 5)。

完成 MyDriving 專案，其中的程式碼儲存機制是在 GitHub 的 DevOps 流程
[圖 5 完成 MyDriving 專案，其中的程式碼儲存機制是在 GitHub 上的 DevOps 流程

展望未來

在本文一開始我說過的各種活動和做法稱為 DevOps 都是橋接撰寫程式碼，並將值傳遞到最低的成本，您的企業客戶之間的差距。您現在可以看到 Microsoft 堆疊行動 「 開發維運提供管理品質、 降低成本，經由自動化，取得應用程式和服務的客戶、 監視進行中的健全狀況和作業，以及收集使用者意見所需的一切所有的摘要回後續版本的待處理項目。這是開發作業週期，從程式碼認可至待處理項目 —，我將在未來的幾個月中瀏覽詳細。

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

衷心感謝以下技術專家對本文的審閱: Donovan 棕色 Jonathan Carter、 Glenn Gailey 和 Karl Krukow