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

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

[[179440]]

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

一、構(gòu)建與發(fā)布

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

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

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

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

3.Team City。與Jenkins類似，TeamCity同樣由Java語言開發(fā)而成，且并非單純面向微軟系統(tǒng)環(huán)境。不過與Jenkins的區(qū)別在于，TeamCity并非免費產(chǎn)品——盡管它提供免費許可。Jenkins與TeamCity都可經(jīng)過設(shè)置作為Windows服務(wù)加以運行。由于二者都基于Java語言，因此它相關(guān)服務(wù)器構(gòu)建與運行的方式與TFS同樣簡單直觀。

二、配置管理

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

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

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

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

2.Chef。Chef是一款自動化產(chǎn)品，能夠執(zhí)行配置管理、合規(guī)性以及構(gòu)建與發(fā)布流程等多種不同任務(wù)類型。盡管Chef Server必須安裝在Linux系統(tǒng)之上，但Chef本身也可通過多種Chef cookbook以及Chef資源支持Windows節(jié)點。

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

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

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

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

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

三、測試框架

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

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

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

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

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

總結(jié)

Windows領(lǐng)域的DevOps努力仍處于起步階段，但它已經(jīng)逐漸煥發(fā)出燎原之勢。技術(shù)社區(qū)與工具生態(tài)系統(tǒng)在支持性方面雖然尚無法與Linux相比肩，但我們?nèi)匀桓吲d地看到，微軟自身正開始積極發(fā)布更多Windows所支持的DevOps工具。相信在不久的未來，對Windows的兼容將成為DevOps的一種常態(tài)。

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

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

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