Windows平台的DevOps工具详解

1、 Windows平台的DevOps工具详解毫无疑问，没有自动化机制的配合，DevOps将无从谈起。虽然不同企业实现DevOps的实际流程大相径庭，但基本分歧点往往始于操作系统。各类DevOps工具在Windows与Linux上的表现区别明显，特别是在可用选项方面。因此,在今天的文章中，我们将着眼于Windows阵营下的核心DevOps工具，希望能够帮助大家立足这一主流平台快速拥抱DevOps。一、代码IDEDevOps自动化并非通过GUI管理环境实现;代码才是实现自动化的核心所在。开发者与DevOps工程师需要一套能够轻松编辑自动化脚本并支持所熟悉语言的开发环境，而这正是IDE的最大价值所在。

2、1.Visual Studio。Visual Studio是Windows平台上的编码王者，且它的影响力正逐步延伸至其他平台。Visual Studio原生支持C、C+、VB.Net、C#以及F#。其他更多语言则可通过对应语言服务得到支持。Visual Studio价格昂贵，如果单独购买价格在500美元到1200美元之间。它提供广泛的服务集成点，包括Azure、AWS以及Hyper-V等等，这一切对DevOps工程师来说相当重要。不过，Visual Studio是一款非常复杂的产品，因此IDE只是它功能的一部分。对于很多专业DevOps人员而言，这种复杂性可能会带来干扰。2.Visual St

3、udio Code。Visual Studio Code是一款出色的IDE。它相较于Visual Studio拥有轻量化且简单等优势，同时支持数十种主流语言。Visual Studio Code适用于MacOS、Windows以及Linux等平台，提供大量Visual Studio既有功能，包括插件支持、剪切以及源控制集成等。Visual Studio Code为免费开源方案，这意味着团队能够随时将其纳入产品开发流程。由于Visual Studio Code是一款新型IDE方案，因此其中可能缺少某些大家习以为常的成熟IDE特性。不过该项目仍在快速发展，且更新速度极快。如果大家需要一款直奔主题的

4、轻量化、跨平台IDE，那么Visual Studio Code绝对是个理想的选项。3.Sapien的PowerShell Studio。在Windows与DevOps领域，我们永远无法回避一个关键词PowerShell。PowerShell存在于任何一款新型Windows操作系统当中，且在Windows DevOps领域拥有不可替代的地位。因此，很多朋友希望能够拥有一款纯PowerShell型IDE。Sapien推出的PowerShell Studio正是一款单纯面向Windows的成熟IDE。它可作为面向PowerShell开发者的Visual Studio。通过丰富的功能集与对PowerS

5、hell的高度关注，这套IDE方案显然吃透了PowerShell语言的特性以及相关开发者的实际需求。不过遗憾的是，它并不提供Visual Studio Code这样的免费产品。大家需要花上几百美元才能加以使用。虽然成本不菲，但如果您所在的企业正在广泛利用PowerShell处理各类DevOps任务，同时需要一套成熟且经过时间检验的IDE，那么Sapien的PowerShell Studio绝对是最理想的选择没有之一。二、源码控制在敏捷环境当中，代码的变更可谓相当频繁，且必须被快速交付至客户手中。这些变更必须由一套中央存储库或者源码控制机制进行捕捉，从而审查相关变更并在出现问题后及时进行代码回滚

6、。随着您所在的企业逐步深入DevOps提出的基础设施即代码原则，源码控制将成为实现目标的关键所在。1.微软Team Foundation Server (简称TFS)。TFS是微软公司提供的DevOps解决方案，核心功能之一正是源码控制。TFS的源码控制机制能够与Visual Studio实现紧密结合。尽管在技术层面上并非必需，但仍然建议大家将TFS与Visual Studio配合使用。除了强大的专有源码管理库之外，TFS目前还支持使用Git存储库，这意味着技术团队也能够利用Git实现代码变更协作。微软还将TFS发布在云端。它的云版本定名为Visual Studio Team Services

7、(简称VSTS)，这项云解决方案似乎已经成为微软公司的当前工作重心。VSTS目前仅提供云版本，但已经有计划稍后推出内部运行版本。VSTS可免费支持5名用户，如果需要支持更多用户则需要支付费用。为了能够与其他现有微软产品及技术紧密集成，将管理Windows服务作为核心诉求的企业在推进DevOps工作时应当考虑选择TFS这不仅是为了利用它的源码控制功能，更是为了实现工作项目追踪并发挥其构建与发布管理功能。2.Git/GitHub。Git是目前最受欢迎的源码控制存储库选项之一。作为一套独立的存储库方案，GitHub对Git的服务进行了广泛扩展，允许用户立足于分布式环境实现彼此间的顺畅协作。Git与G

8、itHub提供Windows版本客户端，且各项服务都可在此平台上实现良好运作。大家甚至能够利用开源Posh-Git项目实现PowerShell对Git的支持。Git可供大家免费下载与使用。GitHub的公共库不收取费用，但大家可以根据实际需求使用专有库或者企业版等付费方案。到这里，我们已经探讨了Windows阵营中DevOps领域的IDE与源码控制领域的相关工具选项。在本系列的下一篇文章中，我们将继续讨论，且主要着眼于构建与发布、配置管理以及测试框架三个方面。毫无疑问，没有自动化机制的配合，DevOps将无从谈起。虽然不同企业实现DevOps的实际流程大相径庭，但基本分歧点往往始于操作系统。各

9、类DevOps工具在Windows与Linux上的表现区别明显，特别是在可用选项方面。在本系列文章的上一部分中，我们已经探讨了Windows阵营下的IDE与源码控制类方案。而在今天的文章里，我们将继续讨论，且主要着眼于构建与发布、配置管理和测试框架三个方面。一、构建与发布DevOps的前提在于以快节奏方式为用户交付高质量软件服务。为了实现这一目标，企业必须拥有一套标准化、可预测且反应迅速的方法，用以定义如何向用户交付开发完成的代码很明显，也就是建立起一套发布管道。1.微软Team Foundation Server (简称TFS)。在Windows环境下，大家可能希望使用微软官方的产品作为发布

10、管道，而TFS正是Windows DevOps的核心平台。它能够构建起管理流程及发布管理功能，这使它成为各类广泛拥有微软资产的企业值得认真考量的重要解决方案。2.Jenkins。Jenkins是另一款在DevOps实践者当中相当流行的产品。该开源项目通过一套构建流程将软件由开发者处交付至用户手中。它采用一套插件式架构，且能够接入您能够想到的几乎一切插件选项。尽管并非专门用于Windows平台，但Jenkins可作为服务安装在Windows当中这要归功于它由Java开发而成的天性。在Windows系统中使用Jenkins时，请确保安装它的PowerShell插件；大家可能需要使用Jenkins以

11、交付各类PowerShell脚本。3.Team City。与Jenkins类似，TeamCity同样由Java语言开发而成，且并非单纯面向微软系统环境。不过与Jenkins的区别在于，TeamCity并非免费产品尽管它提供免费许可。Jenkins与TeamCity都可经过设置作为Windows服务加以运行。由于二者都基于Java语言，因此它相关服务器构建与运行的方式与TFS同样简单直观。二、配置管理如果环境未能得到正确配置，那么它交付的代码自然也无法正常执行。配置管理工具能够帮助大家更为轻松地搞定各类自动化任务，并在企业的DevOps活动当中扮演着重要角色。除了理想状态配置(简称DSC)之外，

12、大多数Windows类企业也需要配合很多并非基于Windows的配置管理工具。尽管其中一部分工具也能够支持Windows系统，但很明显相当比例的方案主要专注于Linux社区。1.Desired State Configuration (即理想状态配置，简称DSC)。微软将DSC作为DevOps领域的首选配置管理平台，它能够管理环境当中相当广泛的因素与方面。DSC的语法类似于PowerShell，且它能够以无缝化方式执行PowerShell代码。然而，DSC绝不局限于PowerShell，它的设计目标在于明确管理各配置条目。DSC属于Windows系统的组成部分，且常被其他配置管理工具所使用。尽

13、管DSC本身常被视为其他配置管理工具的竞争对手，但微软方面明确表示它的定位并非如此。相反，DSC的作用在于以平台方式立足Windows基础并供其他工具加以利用。无论作为独立工具还是其他配置管理工具的运行平台，DSC都是Windows DevOps企业不容忽视的重要解决方案和助力。2.Chef。Chef是一款自动化产品，能够执行配置管理、合规性以及构建与发布流程等多种不同任务类型。尽管Chef Server必须安装在Linux系统之上，但Chef本身也可通过多种Chef cookbook以及Chef资源支持Windows节点。Chef能够在节点之上执行任意PowerShell脚本，交付DSC脚本

14、配置或者直接通过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一样，管理员同样需要花费大量

15、时间构建DSC资源或者PowerShell脚本以供Puppet执行。4.Ansible。Ansible这款产品在定位上与Chef及Puppet略有不同。Ansible的优势在于它拥有一套易于使用的无代理架构，但遗憾的是，它并不支持Windows系统。与其他工具一样，Ansible同样提供能够在一定程度上支持Windows的执行模块。目前，尚无任何可供企业使用的DSC模块，而只有部分社区模型可供选择。与其他工具一样，Ansible也要求运行在Linux服务器之上，但并不需要使用任何代理。Ansible能够通过PowerShell远程机制(WinRM)与Windows节点进行通信，从而以远程方式执

16、行命令。三、测试框架企业要实现DevOps成功，自动化代码测试方案同样不可或缺。在整个软件开发生命周期当中，构建单元、集成与验收测试对于交付可靠代码而言非常重要。在Windows DevOps团队中，大家往往可以选择C#、PowerShell或者将二者相结合。1.Pester。在为PowerShell代码编写测试时，Pester能够帮上大忙。Pester是一套单元测试框架，由PowerShell编写而成并允许管理员利用它编写单元测试甚至是基础设施测试，从而验证各类环境性配置条目。Pester只能用于测试PowerShell代码，尚无法测试其他语言类型。Pester目前属于一套单纯面向Power

17、Shell的测试框架，因此它的选项相对有限，但只要能够接受这一限制，那么它的实际表现堪称出色。尽管属于开源产品，但Pester内置于Windows当中，因此大家应该尽可能利用它作为PowerShell代码的首选测试框架。2.nUnit。如果需要测试C#代码，那么最为流行的测试框架选项无疑是nUnit。这款开源单元测试框架专门面向.Net。大多数现代构建与发布工具都可通过构建任务直接支持nUnit。由于nUnit本身由C#语言编写，因此它能够在Windows DevOps类企业当中发挥理想的测试效果。nUnit属于社区项目且可供大家免费使用。事实上，Pester能够输出nUnit特定格式XML，因此像TFS、Jenkins、TeamCity等多种工具都能够原生显示Pester的测试结果。总结Windows领域的DevOps努力仍处于起步阶段，但它已经逐渐焕发出燎原之势。技术