Windows管理员不能忽略的优秀DevOps工具

　　"DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。本次课课家为大家带来Windows管理员不能忽略的优秀DevOps工具，大家一定要认真阅读!

　　毫无疑问，没有自动化机制的配合，DevOps将无从谈起。虽然不同企业实现DevOps的实际流程大相径庭，但基本分歧点往往始于操作系统。各类DevOps工具在Windows与Linux上的表现区别明显，特别是在可用选项方面。

　　因此,在今天的文章中，我们将着眼于Windows阵营下的核心DevOps工具，希望能够帮助大家立足这一主流平台快速拥抱DevOps。

　　一、代码IDE：

　　DevOps自动化并非通过GUI管理环境实现;代码才是实现自动化的核心所在。开发者与DevOps工程师需要一套能够轻松编辑自动化脚本并支持所熟悉语言的开发环境，而这正是IDE的最大价值所在。

　　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 Studio Code。Visual Studio Code是一款出色的IDE。它相较于Visual Studio拥有轻量化且简单等优势，同时支持数十种主流语言。Visual Studio Code适用于MacOS、Windows以及Linux等平台，提供大量Visual Studio既有功能，包括插件支持、剪切以及源控制集成等。

　　Visual Studio Code为免费开源方案，这意味着团队能够随时将其纳入产品开发流程。

　　由于Visual Studio Code是一款新型IDE方案，因此其中可能缺少某些大家习以为常的成熟IDE特性。不过该项目仍在快速发展，且更新速度极快。如果大家需要一款直奔主题的轻量化、跨平台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。通过丰富的功能集与对PowerShell的高度关注，这套IDE方案显然吃透了PowerShell语言的特性以及相关开发者的实际需求。不过遗憾的是，它并不提供Visual Studio Code这样的免费产品。大家需要花上几百美元才能加以使用。

　　虽然成本不菲，但如果您所在的企业正在广泛利用PowerShell处理各类DevOps任务，同时需要一套成熟且经过时间检验的IDE，那么Sapien的PowerShell Studio绝对是最理想的选择——没有之一。

　　二、源码控制：

　　在敏捷环境当中，代码的变更可谓相当频繁，且必须被快速交付至客户手中。这些变更必须由一套中央存储库或者源码控制机制进行捕捉，从而审查相关变更并在出现问题后及时进行代码回滚。随着您所在的企业逐步深入DevOps提出的基础设施即代码原则，源码控制将成为实现目标的关键所在。

　　1.微软Team Foundation Server (简称TFS)。TFS是微软公司提供的DevOps解决方案，核心功能之一正是源码控制。TFS的源码控制机制能够与Visual Studio实现紧密结合。尽管在技术层面上并非必需，但仍然建议大家将TFS与Visual Studio配合使用。除了强大的专有源码管理库之外，TFS目前还支持使用Git存储库，这意味着技术团队也能够利用Git实现代码变更协作。

　　微软还将TFS发布在云端。它的云版本定名为Visual Studio Team Services(简称VSTS)，这项云解决方案似乎已经成为微软公司的当前工作重心。VSTS目前仅提供云版本，但已经有计划稍后推出内部运行版本。VSTS可免费支持5名用户，如果需要支持更多用户则需要支付费用。

　　为了能够与其他现有微软产品及技术紧密集成，将管理Windows服务作为核心诉求的企业在推进DevOps工作时应当考虑选择TFS——这不仅是为了利用它的源码控制功能，更是为了实现工作项目追踪并发挥其构建与发布管理功能。

　　2.Git/GitHub。Git是目前最受欢迎的源码控制存储库选项之一。作为一套独立的存储库方案，GitHub对Git的服务进行了广泛扩展，允许用户立足于分布式环境实现彼此间的顺畅协作。

　　Git与GitHub提供Windows版本客户端，且各项服务都可在此平台上实现良好运作。大家甚至能够利用开源Posh-Git项目实现PowerShell对Git的支持。

　　Git可供大家免费下载与使用。GitHub的公共库不收取费用，但大家可以根据实际需求使用专有库或者企业版等付费方案。

　　到这里，我们已经探讨了Windows阵营中DevOps领域的IDE与源码控制领域的相关工具选项。

　　知识分享：DevOps现状

　　很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。

　　开发人员经常不考虑自己写的代码会对运营造成什么影响。他们在交付代码之前，并不邀请运营人员参与架构决策或代码评审。

　　开发人员对配置或环境进行修改之后，经常没有及时与运营人员沟通，导致新的代码不能运行。开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。

　　想找到必要的配置参数，通常需要尝试很多不同的参数;在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。

　　开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与运营人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。

　　由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行服务器操作系统上。在开发过程中，系统在开发者的本地机器上运行。在运营过程中，系统经常分布在多台服务器上，例如web服务器、应用服务器、数据库服务器等等。开发是由功能性需求(通常与业务需求直接相关)驱动的。

　　运营是由非功能性需求(例如可获得性、可靠性、性能等)驱动的。运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大变更规模越大，风险也越大，因为其中涉及的区域越多由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。

　　小结：相信最后大家阅读完毕本篇文章后，一定学到了不少知识吧?当然如果大家还想了解更多这些干货，不妨关注课课家教育平台，在这里，你肯定会有意想不到的收获的!