毫无疑问，没有自动化机制的配合，DevOps将无从谈起。虽然不同企业实现DevOps的实际流程大相径庭，但基本分歧点往往始于操作系统。各类DevOps工具在Windows与Linux上的表现区别明显，特别是在可用选项方面。
在本系列文章的上一部分中，我们已经探讨了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相关工作将变得更加得心应手。
