上一篇文章鏈接：Windows管理員不可錯過的那些卓越DevOps工具（上）

【51CTO.com快譯】毫無疑問，沒有自動化機制的配合，DevOps將無從談起。雖然不同企業實現DevOps的實際流程大相徑庭，但基本分歧點往往始于操作系統。各類DevOps工具在Windows與Linux上的表現區別明顯，特別是在可用選項方面。

[[179440]]

在本系列文章的上一部分中，我們已經探討了Windows陣營下的IDE與源碼控制類方案。而在今天的文章里，我們將繼續討論，且主要著眼于構建與發布、配置管理和測試框架三個方面。

一、構建與發布

DevOps的前提在于以快節奏方式為用戶交付高質量軟件服務。為了實現這一目標，企業必須擁有一套標準化、可預測且反應迅速的方法，用以定義如何向用戶交付開發完成的代碼——很明顯，也就是建立起一套發布管道。

1.微軟Team Foundation Server (簡稱TFS)。在Windows環境下，大家可能希望使用微軟官方的產品作為發布管道，而TFS正是Windows DevOps的核心平臺。它能夠構建起管理流程及發布管理功能，這使它成為各類廣泛擁有微軟資產的企業值得認真考量的重要解決方案。

2.Jenkins。Jenkins是另一款在DevOps實踐者當中相當流行的產品。該開源項目通過一套構建流程將軟件由開發者處交付至用戶手中。它采用一套插件式架構，且能夠接入您能夠想到的幾乎一切插件選項。盡管并非專門用于Windows平臺，但Jenkins可作為服務安裝在Windows當中——這要歸功于它由Java開發而成的天性。

在Windows系統中使用Jenkins時，請確保安裝它的PowerShell插件；大家可能需要使用Jenkins以交付各類PowerShell腳本。

3.Team City。與Jenkins類似，TeamCity同樣由Java語言開發而成，且并非單純面向微軟系統環境。不過與Jenkins的區別在于，TeamCity并非免費產品——盡管它提供免費許可。Jenkins與TeamCity都可經過設置作為Windows服務加以運行。由于二者都基于Java語言，因此它相關服務器構建與運行的方式與TFS同樣簡單直觀。

二、配置管理

如果環境未能得到正確配置，那么它交付的代碼自然也無法正常執行。配置管理工具能夠幫助大家更為輕松地搞定各類自動化任務，并在企業的DevOps活動當中扮演著重要角色。除了理想狀態配置(簡稱DSC)之外，大多數Windows類企業也需要配合很多并非基于Windows的配置管理工具。盡管其中一部分工具也能夠支持Windows系統，但很明顯相當比例的方案主要專注于Linux社區。

1.Desired State Configuration (即理想狀態配置，簡稱DSC)。微軟將DSC作為DevOps領域的***配置管理平臺，它能夠管理環境當中相當廣泛的因素與方面。DSC的語法類似于PowerShell，且它能夠以無縫化方式執行PowerShell代碼。然而，DSC絕不局限于PowerShell，它的設計目標在于明確管理各配置條目。

DSC屬于Windows系統的組成部分，且常被其他配置管理工具所使用。盡管DSC本身常被視為其他配置管理工具的競爭對手，但微軟方面明確表示它的定位并非如此。相反，DSC的作用在于以平臺方式立足Windows基礎并供其他工具加以利用。

無論作為獨立工具還是其他配置管理工具的運行平臺，DSC都是Windows DevOps企業不容忽視的重要解決方案和助力。

2.Chef。Chef是一款自動化產品，能夠執行配置管理、合規性以及構建與發布流程等多種不同任務類型。盡管Chef Server必須安裝在Linux系統之上，但Chef本身也可通過多種Chef cookbook以及Chef資源支持Windows節點。

Chef能夠在節點之上執行任意PowerShell腳本，交付DSC腳本配置或者直接通過dsc_resource調用DSC資源。在Windows節點之上，管理員需要投入大量時間編寫DSC資源以供Chef客戶端進行調用。

3.Puppet。Puppet是另一款類似于Chef的配置管理產品。不過與Chef一樣，Puppet的主服務器也必須運行Linux系統，同時支持Windows節點。盡管加入Windows DSC陣營的時間不長，但Puppet目前已經擁有這一支持能力——不過必須承認，在支持Windows特別是DSC方面，Chef要比Puppet更為出色。

Puppet擁有Windows專用模塊，能夠管理大多數常見Windows任務。不過與Chef一樣，管理員同樣需要花費大量時間構建DSC資源或者PowerShell腳本以供Puppet執行。

4.Ansible。Ansible這款產品在定位上與Chef及Puppet略有不同。Ansible的優勢在于它擁有一套易于使用的無代理架構，但遺憾的是，它并不支持Windows系統。與其他工具一樣，Ansible同樣提供能夠在一定程度上支持Windows的執行模塊。目前，尚無任何可供企業使用的DSC模塊，而只有部分社區模型可供選擇。

與其他工具一樣，Ansible也要求運行在Linux服務器之上，但并不需要使用任何代理。Ansible能夠通過PowerShell遠程機制(WinRM)與Windows節點進行通信，從而以遠程方式執行命令。

三、測試框架

企業要實現DevOps成功，自動化代碼測試方案同樣不可或缺。在整個軟件開發生命周期當中，構建單元、集成與驗收測試對于交付可靠代碼而言非常重要。在Windows DevOps團隊中，大家往往可以選擇C#、PowerShell或者將二者相結合。

1.Pester。在為PowerShell代碼編寫測試時，Pester能夠幫上大忙。Pester是一套單元測試框架，由PowerShell編寫而成并允許管理員利用它編寫單元測試甚至是基礎設施測試，從而驗證各類環境性配置條目。Pester只能用于測試PowerShell代碼，尚無法測試其他語言類型。

Pester目前屬于一套單純面向PowerShell的測試框架，因此它的選項相對有限，但只要能夠接受這一限制，那么它的實際表現堪稱出色。盡管屬于開源產品，但Pester內置于Windows當中，因此大家應該盡可能利用它作為PowerShell代碼的***測試框架。

2.nUnit。如果需要測試C#代碼，那么最為流行的測試框架選項無疑是nUnit。這款開源單元測試框架專門面向.Net。大多數現代構建與發布工具都可通過構建任務直接支持nUnit。由于nUnit本身由C#語言編寫，因此它能夠在Windows DevOps類企業當中發揮理想的測試效果。

nUnit屬于社區項目且可供大家免費使用。事實上，Pester能夠輸出nUnit特定格式XML，因此像TFS、Jenkins、TeamCity等多種工具都能夠原生顯示Pester的測試結果。

總結

Windows領域的DevOps努力仍處于起步階段，但它已經逐漸煥發出燎原之勢。技術社區與工具生態系統在支持性方面雖然尚無法與Linux相比肩，但我們仍然高興地看到，微軟自身正開始積極發布更多Windows所支持的DevOps工具。相信在不久的未來，對Windows的兼容將成為DevOps的一種常態。

如大家所見，目前Windows陣營中的DevOps相關工具及服務已經相當豐富。最終，每款工具都需要以這樣或者那樣的方式與Windows系統進行對接，而最理想的實現途徑無疑是通過PowerShell與DSC。作為一名Windows管理員，我們應當率先了解這些技術。在將它們掌握之后，您會發現DevOps相關工作將變得更加得心應手。

原文標題： Must-have devops tools for Windows admins，作者： Adam Bertram

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】