• 發行項

2015 年 9 月

第 30 卷，第 9 期

本文章是由機器翻譯。

DevOps - 在 Microsoft Stack 上啟用 DevOps

由 Michael Learned | 2015 年 9 月

目前沒有一堆傳聞 DevOps 周圍。組織的自訂軟體是重要的商務使用者提供豐富的經驗和有用的資料。快速交付高品質的軟體不再選項、 它是需求。已經是天數的冗長的規劃工作階段和開發反覆項目。例如 Microsoft Azure 的雲端平台有移除傳統瓶頸並幫助 commoditize 基礎結構。軟體 reigns 中每個商務的關鍵區別和業務績效的因素。沒有組織、 開發人員或 IT 工作者可以或應該避免 DevOps 移動。

DevOps 定義從許多觀點的智者，但通常是指移除兩者文化和開發和作業之間的技術障礙小組讓軟體可以將盡可能有效率地移到實際執行環境。一旦您必須確保您可以擷取豐富的使用量資料和摘要資料回開發團隊和決策者的生產環境中執行軟體。

有許多技術及工具都有助於 DevOps。這些工具和程序支援快速發行週期與資料集合上實際執行應用程式。Microsoft 堆疊上的等來快速、 可預測的版本與 Application Insights 說明擷取豐富的應用程式使用資料驅動的 Release Management 工具。本文將探索並釐一些重要的工具和技術用於 DevOps，以及 DevOps 的各個層面 (如所示 [圖 1)。

DevOps 各個層面
[圖 1 DevOps 的各個層面

DevOps 的角色

大部分的組織想要改善下列區域中的其 DevOps 故事：

  • 自動化發行管線中可以可靠地測試和發行在更短的週期。
  • 一旦應用程式在生產環境中執行時，您必須要能夠快速回應變更要求和缺失。
  • 您必須擷取遙測和使用資料執行實際執行應用程式並運用的資料導向的決策與"水晶球"決策。

定址接收器是否有封鎖的 DevOps 這些方面您組織中? 這些 silo 存在於許多形式，例如不同的工具、 指令碼語言、 政治和部門界限。他們想提供責任分隔並保留在生產環境中的安全性控制和穩定性。

儘管他們自己的意願這些 silo 可能有時會嚴重妨礙組織實現許多 DevOps 目標，例如快速、 可靠的版本並處理回應生產缺失。在許多情況下，這個定址接收器結構會產生浪費驚人的數量。開發人員和營運工作者傳統不同團隊與不同的目標。這些小組花循環修正造成較著重於推動業務的時間和由這些阻礙的問題。

企業決策者需要全新看看各種界限來評估 true ROI 或這些 silo 想要提供的優點。它會變得清楚多就可以移除這些障礙、 愈容易實作 DevOps 解決方案並減少浪費。

它是一項挑戰維護適當的安全性、 控制項、 符合性等等時平衡靈活度的需求。企業安全性小組必須確保資料會保持安全和私用。安全性是與任何其他組織沒有可說是一樣重要。

不過，還有您建置每個安全性界限的相關的成本。如果您的小組浪費和磨擦造成安全性界限，這些界限值得以確保它們產生 ROI 一個全新的外觀。可以是最安全的組織在世界裡，但如果您不能在時間上發行軟體就會喪失競爭優勢。

平衡這些優先順序不是新的挑戰，但是該是時候全新和真誠看各種程序和您的組織已建置的定址接收器。小組應該所有會著重於商業價值透過個別的目標。

發行管線

發行管線是與版本控制、 出生您的程式碼時則是透過各種環境和最終發行至實際執行環境。在此過程中執行自動化的建置和測試。管線應該在其中移動至生產環境的變更是透明、 可重複、 可靠且快速的狀態。這當然會牽涉到自動化。發行管線還可能包含佈建應用程式主機環境。

如果這些因素有可能尚未最佳化發行管線：

  • 工具和程序不相符，藉此將每個環境中有不同的工具和程序。(例如，開發小組使用的一種工具部署和 ops 部署與另一個)。
  • 手動步驟可以放入錯誤，所以請避免。
  • 重新建置只為了部署至下一個環境。
  • 您沒有可追蹤性和有問題了解已發行的版本。
  • 發行週期是冗長、 甚至的 hotfix。

佈建

佈建容器是有時會被視為發行管線的選擇性部分。傳統的內部部署案例通常存在環境已經執行在裝載 Web 應用程式。IIS Web 伺服器或其他主機和後端 SQL Server 已透過許多反覆項目已經執行。快速發行到這些環境部署只有應用程式程式碼和後續 SQL 結構描述和資料所需變更移適當的更新層級。在此情況下，您不全新的基礎結構 (包括 IIS 和 SQL) 來裝載應用程式佈建。您使用發行管線會忽略佈建並著重在應用程式程式碼本身。

還有其他您可能想要變更各種容器組態設定的狀況。您可能需要調整 IIS 中的某些應用程式集區設定。您可以實作它作為發行管線的一部分或以手動方式處理。然後您可以選擇性地追蹤這些變更在某個類型的基礎結構做為碼 (IaC) 策略的版本控制系統。

情況有好幾種其他您想要佈建自動化的發行管線的一部分。例如，在開發週期的早期可能會想要卸除並重建新的 SQL 資料庫到每一個版本完全和自動測試環境。

例如，Azure 可讓您只需支付您所需要雲端運算平台。使用自動化的安裝程式並終止前可以符合成本效益。透過自動化佈建和環境的變更，您可以避免錯誤和控制整個應用程式環境。這類案例更令人讚嘆包含佈建一個全面性的發行管理系統的一部分。

有許多選項和技術包括佈建發行管線的一部分。這些不同根據應用程式裝載和您裝載它們的類型。傳統的 ASP.NET Web 應用程式與 Azure Web 應用程式或 Azure 雲端服務等其他平台做為-服務 (PaaS) 應用程式裝載其中一個範例。這些應用程式的容器不同且需要不同的工具技術來支援佈建步驟。

程式碼的基礎結構

受歡迎的佈建技術是 IaC。應用程式是編譯的程式碼、 指令碼等結合作業的環境可以是可執行檔。您會發現這種環境會產生許多好處。

Microsoft 最近必須進行的 IaC 影響研究研究 Forrester Research Inc.(請參閱 bit.ly/1IiGRk1)。研究顯示 IaC 是重要的 DevOp 元件。它也示範了佈建和組態都是主要的傳遞軟體團隊的人事點。您必須利用自動化和 IaC 技術如果您想要完全滿足您的 DevOps 目標。

傳統的營運挑戰之一是自動化的能力提供適當的環境中執行應用程式和服務，並保持那些環境中已知的良好狀態。虛擬化與其他自動化技術很有幫助，但仍有問題保留節點保持同步和管理組態改變。作業與開發團隊繼續與不同的工具組、 專業知識和程序就會很吃力。

IaC 根據我們應該能夠描述、 版本、 執行內部部署和測試我們的基礎結構程式碼經由自動化的發行管線。比方說，您可以輕鬆建立 Windows 虛擬機器 (VM) 搭配使用簡單的 Windows PowerShell 指令碼的 IIS 設定。作業應該能夠使用相同的 ALM 工具來編寫指令碼版本和測試基礎結構。

其他好處包括能夠運轉上線並卸除已知版本的環境需求。您可以避免麻煩問題因為環境開發和生產環境之間的差異。您可以 express 中的程式碼的應用程式環境特定相依性並執行這些沿著版本控制中。簡單地說，您可以排除手動處理流程並確保在測試過應用程式可靠性的自動化的環境容器。開發和作業可以使用常見的指令碼語言和工具並達成這些效率。

應用程式類型和預期的主控件的位置會規定涉及執行基礎結構程式碼工具。有數個工具獲得支援這些技術包括 Desired State Configuration (DSC)、 傀儡、 廚師和更多的熱門程度。每個可協助您達成類似手邊的案例為基礎的目標。

IaC 的程式碼片段可能是其中幾件事。它可能只是佈建資源的 Windows PowerShell 指令碼。同樣地，應用程式類型和裝載環境將會要求您的選擇。

適用於 Azure，您可以使用利用 Azure 資源管理 Api 來建立和管理 Azure 資源群組的雲端部署專案。這可讓您描述您的環境使用 JSON。Azure 資源 Goups 也可讓您在一起，例如網站和 SQL 資料庫管理群組相關的資源。雲端部署專案，您可以在版本控制中儲存您佈建的需求並執行 Azure 佈建自動化的發行管線的一部分。以下是範本的佈建的基本結構所組成的章節：

{
  "$schema": "http://schema.management.azure.com/schemas2015-01-01/
    deploymentTemplate.json#",
  "contentVersion": "",
  "parameters" { },
  "variables": { },
  "resources": [ ],
  "outputs": { }
}

如需有關範本的詳細資訊，請移至 bit.ly/1RQ3gvg, ，如需定域機組部署專案的詳細資訊，請參閱 bit.ly/1flDH3m。

指令碼語言和工具是只有部分成功採用 IaC 策略所需的變更。開發和作業團隊必須相互合作來整合一組常用的目標向其工作資料流。這不件易事因為過去作業團隊的焦點是保持穩定的環境和開發團隊更著重在這些環境中引入新功能。複雜的技術新興的但是成功 IaC 實作的基礎將取決於有效地共同作業的作業和開發團隊的能力。

版本協調流程

Release Management 是 Visual Studio ALM 堆疊中的技術。它實際上不是讓您可以協調各種物件和包含軟體的工作發行的概念。這些成品的一些包含裝載或封裝所產生的建置系統的自動化測試剛好也發行管線、 核准工作流程、 通知和安全性監管以控制環境更接近到生產環境的一部分。

您可以使用技術如 DSC、 Windows PowerShell 指令碼，Azure 資源管理員] 廚師，等等來管理環境的狀態並將軟體和相依性安裝到執行環境。Visual Studio ALM 所提供的工具，以將 Release management 視為包裝任何技術和工具，您需要執行部署的服務。發行管理可能會利用簡單的命令列或 Windows PowerShell 指令碼、 使用 DSC，或甚至執行您自己的自訂工具。您的目標應該使用最簡單的解決方案可能執行您的版本。

它也是很好的作法因為它是無所不在依賴 Windows PowerShell。例如，您可以使用 Windows PowerShell 指令碼做為發行管線的一部分來部署 Azure 雲端服務。有許多與 Release Management 的方塊外工具 (請參閱 [圖 2)，但您也可以建立您自己的彈性。

工具和發行管理可用的選項
[圖 2 工具和發行管理可用的選項

發行管理可協助您優雅地建立自動化的發行管線並產生可靠的自動化應用程式版本。您也可以選擇包括佈建。工具與 Visual Studio 和 Team Foundation Server 版本的管理可以協助您到整體版本交易協調這些成品。它也提供豐富的儀表板樣式檢視到您目前和歷程記錄的狀態。另外還有豐富的整合與 Team Foundation Server 和 Visual Studio Online。

其中沒有 DSC 調整?

有很多關於 DSC 最近。DSC 不是，不過，某些全方位工具可以處理所有項目。您將使用做為其中一個工具的 DSC DevOps 結構，不是唯一的工具中。

您可以使用 DSC 中提取或推入模式。然後您可以使用 「 讓它能夠"的階段來控制伺服器狀態。控制該狀態可以確保檔案或目錄存在，或是修改登錄、 停止或啟動服務、 或執行指令碼來部署應用程式等更複雜這麼簡單。您可以重複不會發生錯誤。您也可以定義您自己 DSC 的資源或利用大量的內建的資源。

DSC 會實作為本機組態管理員 (LCM)、 目標節點上執行接受管理物件檔案 (MOF) 組態檔並使用將設定套用至節點本身。所以沒有硬碟結合工具。您甚至不必使用 Windows PowerShell 來產生 MOF。

若要開始使用 DSC，只是產生的 MOF 檔案。最後會描述的各種資源來執行時，它最後會撰寫大部分是在 Windows PowerShell。在 Windows Server 為基礎的系統上 DSC 大優點之一是 LCM 是原生作業系統、 提供內建的代理程式 」 的概念。也有與 Linux 的運用 DSC 的案例。請參閱 [圖 3 分開 DSC 指令碼的組態資料的範例。

[圖 3 DC 指令碼內的個別的組態資料

Configuration InstallWebSite
{
  Node $AllNodes.NodeName
  {
    WindowsFeature InstallIIS
    {
      Ensure = "Present"
      Name = "Web-Server"
    }
  }
}
InstallWebSite –ConfigurationData .\config.ps1
Where config.ps1 contains
$ConfigData = @{
  AllNodes = @(
  @{
    NodeName = “localhost”
  })
}

DSC 可以是一項重要的發行管線有資源可幫助支援您的部署。在內部部署或 IaaS 應用程式，DSC 是很好的選擇來協助控制環境設定和支援您的部署案例。

仍然 DSC 並非要用於每一種情況。若要讓這在內容中，如果您要部署 Azure PaaS 資源，建議您使用 Azure 資源管理員取得 Vm 啟動和設定網路。其實不只針對 DSC。一旦 Vm 都在執行中，您可以使用 DSC 取得本機組態設定您要它的方式確保不會變更您關心的組態項目。

使用 Application Insights 的監視器

一旦應用程式和環境在生產環境中，務必來收集資料和監視的作業健全狀況。您也必須了解使用模式。此資料是關鍵管理狀況良好的服務。收集和監視這項資料是一項重要的 DevOps。例如，Microsoft 已用於實際執行資料改善 Visual Studio Online 小組。此豐富的資料可協助確保服務可用性的 Visual Studio Online 小組、 示範這些開發人員如何使用服務和通知功能優先處理的決策。您可以閱讀更多有關 Microsoft DevOps 走在 bit.ly/1AzDL9V。

Visual Studio Application Insights SDK 加入您的應用程式並將遙測傳送至 Azure 入口網站。它支援許多不同平台和語言，包括 iOS、 Android、 ASP.NET 和 Java。您可以擷取效能資料、 應用程式執行時間和各種使用方式分析。您可以顯示這些豐富資料決策者和專案關係人來協助更佳的決策、 偵測問題並持續改善您的應用程式。您可以閱讀更多有關在 Application Insights bit.ly/1IbRnrF。

[圖 4 和 [圖 5 顯示 Application Insights 所收集的資料類型的範例。

Application Insights 可以提供資料的使用者和頁面檢視
[圖 4 Application Insights 可以提供資料的使用者和頁面檢視

Application Insights 監視也 Web 測試
[圖 5 Application Insights 監視也 Web 測試

總結

DevOps 會幫助團隊向連續傳遞和運用資料的磁碟機執行應用程式以幫助訂定更佳的決策。這篇文章已檢查各種顯著的 Microsoft 技術可用來達成這些目標:

  • 發行管理可讓您使用的磁碟機部署任何技術。這些技術包括簡單的 Windows PowerShell 指令碼、 DSC 組態或甚至是協力廠商工具傀儡等。
  • 基礎結構做為程式碼的策略可協助開發和作業團隊有效率地在一起。
  • Visual Studio Application Insights 會提供機制來擷取中執行應用程式共同協助專案關係人了解應用程式健全狀況及檢驗使用模式來驅動明智的決策的豐富資料。

這些技術可協助您大幅提升您的 DevOps 成熟度。您也需要 blend 幾組適當的技術同時努力克服文化特性的障礙。

其他資源

  • 若要深入了解程式碼的基礎結構，聆聽 Channel 9 上的 Brian Keller 討論 bit.ly/1IiNqmr。
  • 若要深入了解 Azure 資源群組部署專案，請參閱 bit.ly/1flDH3m。
  • 若要深入了解 TFS 規劃、 損毀預防和修復性和 Azure IaaS 上的 TFS，請參閱指南 》， vsarplanningguide.codeplex.com。
  • 若要深入了解組態程式碼的 DevOps 和 ALM 從業人員，請參閱 vsardevops.codeplex.com。

Michael Learned 是目前致力於 DevOps 及 Microsoft Azure 的 Visual Studio ALM Ranger。他曾在 Microsoft 內外的許多軟體專案 15 年以上。他住在中央伊利諾並專用於協助社群、 以及放寬他女兒、 與兩個兒子太太的空閒時間。在 Twitter 上達到他 twitter.com/mlhoop。

衷心感謝以下技術專家對本文的審閱: Donovan Brown (Microsoft)、 Wouter de Kort (獨立開發人員)、 Marcus Fernandez (Microsoft)、 Richard Hundhausen (Accentient)、 Willy-peter Schaub (Microsoft) 和 Giulio 透過 (獨立開發人員)