干货：Windows管理员值得收藏的卓越DevOps工具

　　欢迎各位阅读本篇文章，本篇文章讲述了关于Windows管理员值得收藏的卓越DevOps工具，课课家教育平台温馨想提醒：本篇文章纯干货，因此大家一定要认真阅读本篇文章哦~

　　知识分享:evOps:简介

　　evOps: Development和Operations的组合：

　　可以把DevOps看作 开发( 软件工程)、技术运营和质量保障(QA)三者的交集

　　传统的 软件组织将 开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的 开发方法(例如 敏捷软件开发)，这是一个重要的课题：按照从前的工作方式，开发和 部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门 协作。然而DevOps考虑的还不止是 软件 部署。它是一套针对这几个部门间 沟通与 协作问题的流程和方法。

　　需要频繁交付的企业可能更需要对DevOps有一个大致的了解。 Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天 部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与 精益创业方法联系起来。 从2009年起，相关的 工作组、专业组织和 博客快速涌现。

　　DevOps的引入能对产品交付、 测试、功能 开发和 维护(包括──曾经罕见但如今已屡见不鲜的──“ 热补丁”)起到意义深远的影响。在缺乏DevOps能力的组织中， 开发与 运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望 基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

　　以下几方面因素可能促使一个组织引入DevOps：

　　使用敏捷或其他软件开发过程与方法

　　业务 负责人要求加快产品交付的速率

　　虚拟化和 云计算 基础设施(可能来自内部或外部供应商)日益普遍

　　数据中心 自动化技术和 配置管理工具的普及

　　有一种观点认为，占主导地位的“传统”美国式管理风格(“ 斯隆模型 vs 丰田模型”)会导致“烟囱式 自动化”，从而造成 开发与 运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

　　DevOps经常被描述为“ 开发团队与 运营团队之间更具 协作性、更高效的关系”。由于团队间 协作关系的改善，整个组织的 效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

　　DevOps对应用程序发布的影响

　　在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：

　　与传统 开发方法那种大规模的、不频繁的发布(通常以“季度”或“年”为单位)相比，敏捷方法大大提升了发布频率(通常以“天”或“周”为单位)

　　减少变更范围与传统的 瀑布式开发模型相比，采用敏捷或 迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于 部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。加强发布协调靠强有力的发布协调人来弥合 开发与 运营之间的技能鸿沟和 沟通鸿沟;采用电子数据表、 电话会议、即时消息、企业门户(wiki、sharepoint)等 协作工具来确保所有相关人员理解变更的内容并全力合作。 自动化强大的 部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

　　毫无疑问，没有自动化机制的配合，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相关工作将变得更加得心应手。

　　小结：说到底，其实大家私下还得多多练习与自学，如果大家想要更深层的了解相关方面的内容的话呢，可以关注课课家教育平台，在这里，你肯定会学到很多很多的知识的!课课家教育平台欢迎大家!