上一篇文章链接：Windows管理员不应错过的出色DevOps工具（第1部分）[.comExpress翻译]毫无疑问，没有自动化机制可以合作，DevOps将无从谈起。尽管不同企业实施DevOps的实际过程大不相同，但基本的分歧往往是从操作系统开始的。各种DevOps工具在Windows和Linux上的行为不同，尤其是在可用选项方面。在本系列文章的前一部分，我们讨论了Windows阵营的IDE和源代码控制解决方案。在今天的文章中，我们将继续探讨，主要围绕构建与发布、配置管理与测试框架三个方面展开。1、构建和发布DevOps的前提是以快节奏的方式向用户交付高质量的软件服务。为了实现这个目标，企业必须有一个标准化的、可预测的和响应式的方法来定义如何将开发的代码交付给用户——很明显，就是建立一个发布管道。1.MicrosoftTeamFoundationServer（简称TFS）。在Windows环境下，你可能希望使用微软的官方产品作为发布管道，而TFS是WindowsDevOps的核心平台。它构建管理流程和发布管理功能的能力使其成为具有广泛Microsoft属性的组织的重要解决方案。2.詹金斯。Jenkins是另一个非常受DevOps从业者欢迎的产品。该开源项目通过构建过程将软件从开发人员交付给用户。它使用插件架构，几乎可以访问您能想到的任何插件选项。虽然不是特定于Windows平台，但Jenkins可以作为服务安装在Windows上——这要归功于其Java开发的特性。在Windows上使用Jenkins时，请确保安装其PowerShell插件；您可能需要使用Jenkins来交付各种PowerShell脚本。3.团队城市。与Jenkins类似，TeamCity也是由Java语言开发的，并非纯粹针对微软系统环境。然而，与Jenkins不同的是，TeamCity不是免费产品——尽管它提供免费许可证。Jenkins和TeamCity都可以配置为作为Windows服务运行。由于两者均基于Java语言，其相关服务器的构建和运行方式与TFS一样简单直观。2、配置管理如果环境配置不当，那么它下发的代码自然不会正常执行。配置管理工具可以帮助您更轻松地自动执行各种任务，并在企业DevOps活动中发挥重要作用。除了理想状态配置（简称DSC），大多数基于Windows的企业还需要配合很多非基于Windows的配置管理工具。尽管其中一些工具也支持Windows系统，但很明显，相当一部分解决方案主要集中在Linux社区。1.DesiredStateConfiguration（即理想状态配置，简称DSC）。微软将DSC视为DevOps领域领先的配置管理平台，可以管理环境中广泛的因素和方面。DSC的语法类似于PowerShell，可以无缝执行PowerShell代码。但是，DSC绝不仅限于PowerShell，它旨在明确管理各个配置条目。DSC是Windows系统不可或缺的一部分，经常被其他配置管理工具使用。虽然DSC本身经常被视为其他配置管理工具的竞争对手，但Microsoft明确表示它不是这样定位的。相反，DSC的作用是以其他工具可以利用的平台方式在Windows基础上构建。无论作为独立工具使用，还是作为其他配置管理工具的运行平台，DSC都是WindowsDevOps企业不可忽视的重要解决方案和支撑。2.厨师。Chef是一种自动化产品，可以执行许多不同的任务类型，例如配置管理、合规性以及构建和发布流程。虽然ChefServer必须安装在Linux系统上，但Chef本身也可以通过各种Chefcookbook和Chef资源来支持Windows节点。Chef可以在节点上执行任意PowerShell脚本，下发DSC脚本配置或者直接通过dsc_resource调用DSC资源。在Windows节点上，管理员需要花费大量时间编写DSC资源以供Chef客户端调用。3.木偶。Puppet是另一个类似于Chef的配置管理产品。但是，与Chef一样，Puppet的主服务器也必须运行Linux系统，同时支持Windows节点。虽然加入WindowsDSC阵营时间不长，但Puppet目前已经具备了这种支持能力——但必须承认，Chef在对Windows的支持方面比Puppet要好，尤其是DSC。Puppet具有特定于Windows的模块，能够管理最常见的Windows任务。但与Chef一样，管理员也花费大量时间构建DSC资源或PowerShell脚本供Puppet执行。4.可靠。Ansible是一款在定位上与Chef和Puppet略有不同的产品。Ansible的优势在于它具有易于使用的无代理架构，但不幸的是，它不支持Windows系统。与其他工具一样，Ansible也提供了一定程度上支持Windows的执行模块。目前，没有任何可供企业使用的DSC模块，只有一些社区模型可用。与其他工具一样，Ansible也需要运行在Linux服务器上，但不需要使用任何代理。Ansible能够通过PowerShell远程处理机制(WinRM)与Windows节点通信，以远程执行命令。3.测试框架自动化代码测试解决方案对于企业实现DevOps的成功也是不可或缺的。在整个软件开发生命周期中，构建单元、集成和验收测试对于交付可靠的代码至关重要。在WindowsDevOps团队中，您通常可以选择C#、PowerShell或两者的组合。1.纠缠。在为PowerShell代码编写测试时，Pester可以提供很大的帮助。Pester是一个用PowerShell编写的单元测试框架，允许管理员编写单元测试甚至基础设施测试来验证各种环境配置项。Pester只能用于测试PowerShell代码，还不能测试其他语言类型。Pester目前是一个纯PowerShell的测试框架，所以它的选择比较有限，但只要你能接受这个限制，它的实际表现还是很优秀的。尽管是开源产品，Pester内置于Windows中，因此您应该尽可能将其用作PowerShell代码的渗透测试框架。2.nUnit。如果您需要测试C#代码，最流行的测试框架选项无疑是nUnit。这个开源单元测试框架专门针对.Net。大多数现代构建和发布工具直接通过构建任务支持nUnit。由于nUnit本身是用C#语言编写的，因此可以在WindowsDevOps企业中发挥理想的测试效果。nUnit是一个社区项目，每个人都可以免费使用。事实上，Pester可以输出nUnit特定格式的XML，因此TFS、Jenkins、TeamCity等工具可以原生显示Pester测试结果。总结Windows领域中的DevOps工作仍处于起步阶段，但它已经获得了发展势头。虽然技术社区和工具生态在支持方面还不能与Linux相提并论，但我们还是很高兴看到微软自己也在积极开始发布更多Windows支持的DevOps工具。相信在不久的将来，兼容Windows将成为DevOps的常态。可以看到，Windows阵营中与DevOps相关的工具和服务相当多。最终，每个工具都需要以某种方式与Windows交互，而理想的方式无疑是通过PowerShell和DSC。作为Windows管理员，我们应该是第一个了解这些技术的人。掌握了它们之后，你会发现DevOps相关的工作会变得得心应手。原标题：Windows管理员必备的devops工具，作者：AdamBertram
