# 开发运营 - 为 Microsoft 堆栈启用开发运营 作者：[Michael Learned](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Michael+Learned) | September 2015 现在，对于开发运营有很多讨论。对于向组织的业务用户提供丰富的体验和有用的数据来说，组织的自定义软件至关重要。快速交付高质量的软件不再是一种选择，而是一项要求。耗时较长的规划会议和开发迭代的情形已经一去不复返了。Microsoft Azure 等云平台已经摒弃了传统瓶颈，并且有助于基础结构的商品化。软件作为业务成果的关键分水岭和因素，盛行于各行各业。任何组织、开发人员或 IT 工作人员都无法避免，而且也不应该避免开发运营的趋势。 虽然对开发运营进行了各种定义，但通常大部分定义都涉及到移除开发和运营团队之间的文化和技术障碍，从而使软件尽可能高效地投入生产。软件在生产环境中运行之后，需要确保可以捕获丰富的使用情况数据，并向开发团队和决策制定者反馈该数据。 有很多技术和工具可为开发运营提供帮助。这些工具和流程支持对生产应用程序实施快速发布周期和数据收集。对于 Microsoft 堆栈，有推动快速可预测发布的 Release Management 工具，以及有助于捕获丰富的应用使用情况数据的 Application Insights 工具。本文将探索并介绍开发运营中使用的重要工具和技术以及开发运营的各个方面（如图 1 中所示）。   图 1 开发运营的各个方面 ## 开发运营的角色 大多数组织希望在以下几个方面提高他们的开发运营能力： * 自动执行发布管道（您可以在更短的周期内执行可靠的测试和发布操作）。 * 应用程序在生产环境中运行之后，您需要能够快速响应以更改请求和修复缺陷。 * 您必须从运行的生产应用程序中捕获遥测和使用情况数据，并利用这些数据做出数据驱动的决策与“水晶球”决策。 您组织中是否存在阻止开发运营的这些方面的真空区？ 这些真空区以多种形式存在，例如不同的工具、脚本语言、政治和部门界限。他们想要提供职责分离，并在生产中保持安全控制和稳定性。 不管他们的意图是什么，这些真空区有时会妨碍组织实现很多开发运营目标，如快速可靠的发布和处理，以及对生产缺陷的响应。在很多情况下，此类真空区结构会造成大量浪费。开发人员和运营工作人员一直以来都在不同的团队为不同的目标而奋斗。这些团队花费多个周期来解决这些障碍造成的问题，而专注于推动业务发展的时间却很少。 企业决策者需要以新的视角看待各种界限，以评估这些真空区可能提供的实际 ROI 或好处。很明显，消除的障碍越多，就越容易实施开发运营解决方案并减少浪费。 维护适当的安全、控制和合规性，同时平衡灵活性需求是一项挑战。企业安全团队必须确保数据的安全性和隐私性。毫无疑问，安全性与组织开展的其他活动具有同等的重要性。 但是，您构建的所有安全性界限都会产生相关的费用。如果安全性界限会造成团队的浪费以及产生冲突，则需要以新的视角来查看这些界限以确保它们能产生 ROI。您可能成为全球最安全的组织，但是如果您无法及时发布软件，则会在竞争上处于劣势。 平衡这些优先级并非是新的挑战，但也应该重新坦诚地看待各种流程以及您组织已存在的真空区。团队应着眼于企业价值，而不只是关注单个目标。 ## 发布管道 发布管道是生成代码、进行版本控制，然后经过各种环境并最终发布到生产的地方。在此过程中，您可以执行自动生成和测试。管道应处于这样一种状态：以透明的、可重复的、可信赖的以及快速的方式将更改内容应用到生产。这无疑会涉及到自动化。发布管道可能还包括设置应用程序主机环境。 如果存在以下因素，则无法优化发布管道： * 工具和流程不匹配，即每个环境中包含不同的工具和流程。（例如，开发团队使用一种工具进行部署，而运营团队使用另一种工具进行部署）。 * 手动步骤可能出现错误，因此避免手动步骤。 * 重新生成只是为了部署到下一个环境。 * 缺少可跟踪性，并且在了解已发布版本方面存在问题。 * 发布周期过长，即使对于修补程序也是如此。 ## 部署 有时，部署容器会被视为发布管道的可选部分。传统的本地方案通常存在于为了托管 Web 应用程序而运行的环境中。IIS Web 服务器或其他主机和后端 SQL Server 已通过大量迭代运行。快速发布到这些环境仅部署应用程序代码、后续 SQL 架构以及移动相应更新级别所需的数据更改。在这种情况下，您并未部署新的基础结构（IIS 和 SQL）来托管应用程序。您使用的是不考虑部署而仅注重应用程序代码本身的发布管道。 您可能还希望通过一些其他方案来更改各种容器配置设置。您可能需要调整 IIS 中的部分应用池设置。您可以将其作为发布管道的一部分来实现，或手动进行处理。然后，您可能选择在某些类型的版本控制系统中通过基础结构即代码 (IaC) 策略来跟踪这些更改内容。 您可能希望通过一些其他方案来作为自动发布管道的一部分进行部署。例如，在开发周期的早期，您可能想要关闭并为每个版本重新生成新的 SQL 数据库，完全以自动化方式测试环境。 借助 Azure 等云计算平台，您只需对所需内容支付即可。使用自动化的设置和关闭非常经济有效。通过自动化部署和环境更改，您可以避免错误并控制整个应用程序环境。类似情况使得加入部署作为整体发布管理系统的一部分极具吸引力。 有很多选项和技术可用于将部署添加为发布管道的一部分。具体因您要托管的应用程序类型和托管应用程序的位置而异。例如，托管传统的 ASP.NET Web 应用程序、Azure Web 应用或某些其他平台即服务 (PaaS) 应用程序（例如，Azure 云服务）。这些应用程序的容器各不相同，需要不同的工具技术来支持部署步骤。 ## 基础结构即代码 一个常用的部署技术是 IaC。应用程序是可执行文件，可以是编译后的代码、脚本等，可与运营环境结合。您会发现此环境会带来很多优势。 最近，Microsoft 委托 Forrester Research Inc. 对IaC 产生的影响进行研究（请参阅 [bit.ly/1IiGRk1](http://bit.ly/1IiGRk1)）。研究显示 IaC 是一个关键的开发运营组件。此外，研究还表明部署和配置是团队交付软件的主要冲突点。如果您要完全实现自己的开发运营目标，则需要利用自动化和 IaC 技术。 传统的运营挑战之一是自动化提供适当环境的功能，从而在环境中执行应用程序和服务，并使这些环境保持已知的的良好状态。虽然虚拟化和其他自动化技术非常有用，但是在同步中保留节点以及管理配置偏差方面仍然存在问题。运营和开发团队在使用不同的工具集、专业知识和流程方面仍感到非常很困难。 利用 IaC 的前提是，我们应能够通过自动化发布管道对基础结构代码进行描述、版本控制、执行和测试。例如，利用简单的 Windows PowerShell 脚本，您可以轻松地创建配置 IIS 的 Windows 虚拟机 (VM)。运营部门应可以使用相同的 ALM 工具为基础结构编写脚本、执行版本控制和测试。 其他好处包括能够启动和关闭环境的已知版本。由于开发和生产环境存在差异，您可以避免很多繁琐的问题。您可以在代码中表达应用程序特定于环境的依赖关系，并将它们沿用到版本控制中。简言之，您可以消除手动流程，并确保为您的应用程序测试了可靠的自动化环境容器。开发和运营团队可以使用常见的脚本语言和工具，从而提高效率。 应用程序类型和目标主机位置将决定执行您的基础结构代码所涉及到的工具。有几种工具在支持这些技术方面颇受欢迎，其中包括 Desired State Configuration (DSC)、Puppet 和 Chef 等。根据手头的方案，每种工具都可以帮助您实现类似的目标。 IaC 的代码部分可能是以下内容之一。可能只是部署资源的 Windows PowerShell 脚本。同样，应用程序类型和托管环境将决定您的选择。 对于 Azure，您可以使用利用 Azure 资源管理 API 的云部署项目来创建和管理 Azure 资源组。这样您就可以使用 JSON 来描述您的环境。借助 Azure 资源组，您还可以同时管理与组相关的资源，如网站和 SQL 数据库。通过云部署项目，您可以在版本控制中存储部署要求，并执行作为自动发布管道的一部分的 Azure 部署。以下是组成部署模板的基本结构的各部分： ~~~ {   "$schema": "http://schema.management.azure.com/schemas2015-01-01/     deploymentTemplate.json#",   "contentVersion": "",   "parameters" { },   "variables": { },   "resources": [ ],   "outputs": { } } ~~~ 有关模板的更多信息，请转到 [bit.ly/1RQ3gvg](http://bit.ly/1RQ3gvg)；有关云部署项目的更多信息，请参阅 [bit.ly/1flDH3m](http://bit.ly/1flDH3m)。 脚本语言和工具是成功采用 IaC 策略所需更改的唯一部分。开发和运营团队必须相互协作，为共同的一组目标整合工作流。这极具挑战性，因为一直以来，运营团队都注重保持环境的稳定性，而开发团队更注重将新功能引入这些环境。虽然各种复杂的技术不断涌现，但是成功实施 IaC 的基础将取决于运营和开发团队之间有效合作的能力。 ## 发布安排 Release Management 是 Visual Studio ALM 堆栈中的一项技术。实际上，它在更大程度上是一个概念，您可以安排包含软件发布的各种项目和任务。其中一些项目包括生成系统生成的有效负载或程序包、作为发布管道一部分的自动化测试、审批工作流以及控制接近生产的环境的通知和安全管理。 您可以使用 DSC、Windows PowerShell 脚本、Azure 资源管理器和 Chef 等技术来管理环境状态，并将软件和依赖项安装到运行环境中。就 Visual Studio ALM 提供的工具而言，将 Release Management 视为囊括您执行部署所需的任何技术和工具的服务。Release Management 可利用简单的命令行或 Windows PowerShell 脚本，使用 DSC 甚至执行您自己的自定义工具。您的目标应该是尽可能使用最简单的解决方案来执行发布。 依赖于 Windows PowerShell 也是一种很好的做法，因为它非常普遍。例如，您可以将 Windows PowerShell 脚本用作发布管道的一部分，以便部署 Azure 云服务。虽然有很多现成的工具可与 Release Management 结合使用（请参阅图 2），但您也可以灵活地创建自己的工具。  图 2 适用于 Release Management 的工具和选项 Release Management 可以帮助您完美地创建自动化发布管道，并生成可靠的自动化应用程序版本。您还可以选择加入部署。Release Management 工具与 Visual Studio 和 Team Foundation Server 可以帮助您将这些项目安排到整个发布事务中。它还提供丰富的仪表板样式的视图，可查看当前状态和历史状态。此外还与 Team Foundation Server 和 Visual Studio Online 完美集成。 ## DSC 适用于何处？ 最近发布了大量与 DSC 有关的内容。但是，DSC 并非可处理所有内容的包罗万象的工具。您可以将 DSC 用作开发运营结构中的一个工具，但不是唯一的工具。 您可以在请求或推送模式下使用 DSC。然后，您可以使用“执行此设置”状态来控制服务器状态。控制该状态可以非常简单，类似于确保文件或目录存在，或者是修改注册表、停止或启动服务或运行脚本以部署应用程序等更加复杂的操作。您可以重复执行此操作，不会出现错误。此外，您可以定义自己的 DSC 资源或使用大量的内置资源。 DSC 作为本地配置管理器 (LCM) 来实现，在目标节点上运行，接受管理对象文件 (MOF) 配置文件并使用该文件将配置应用到该节点本身。因此，没有硬性结合的工具。您甚至无需使用 Windows PowerShell 来生成 MOF。 若要开始使用 DSC，直接生成 MOF 文件即可。这将最终会描述要执行的各种资源，大部分都是在 Windows PowerShell 中编写的。基于 Windows 服务器系统上的 DSC 的主要优势之一是，LCM 是操作系统的原生程序，这为您提供了内置代理的概念。还有一些通过 Linux 利用 DSC 的方案。请参阅图 3，查看分离 DSC 脚本的配置数据的示例。 图 3 分离 DCS 脚本中的配置数据 ~~~ Configuration InstallWebSite {   Node $AllNodes.NodeName   {     WindowsFeature InstallIIS     {       Ensure = "Present"       Name = "Web-Server"     }   } } InstallWebSite –ConfigurationData .\config.ps1 Where config.ps1 contains $ConfigData = @{   AllNodes = @(   @{     NodeName = “localhost”   }) } ~~~ 如果 DSC 具有可用的资源来帮助支持您的部署，则它是发布管道的重要部分。对于本地或 IaaS 应用程序，DSC 是一个极佳的选择，可帮助控制环境配置并支持您的部署方案。 同样，DSC 并非适用于每种方案。因此，如果您部署的是 Azure PaaS 资源，则建议您使用 Azure 资源管理器来启动虚拟机并配置网络。这并非 DSC 的主旨。运行虚拟机之后，您可以使用 DSC 按照您希望的方式获取本地配置，并确保您关心的配置元素不会更改。 ## 使用 Application Insights 进行监视 应用程序和环境投入生产后，收集数据和监视运行状况是非常重要的。您还需要了解使用情况模式。此类数据对于管理运行状况服务非常重要。收集和监视此类数据是开发运营的重要部分。例如，Microsoft 使用生产数据对 Visual Studio Online 团队进行提升。此类丰富的数据可以帮助 Visual Studio Online 团队确保服务可用性，向他们演示开发人员是如何按照功能优先顺序使用服务并通知决策的。您可以访问[bit.ly/1AzDL9V](http://bit.ly/1AzDL9V) 详细了解 Microsoft 开发运营历程。 Visual Studio Application Insights 将 SDK 添加到您的应用程序并将遥测发送到 Azure 门户。它支持多种平台和语言，包括 iOS、Android、ASP.NET 和 Java。您可以捕获性能数据、应用程序正常运行时间和各种使用情况分析。您可以向决策制定者和利益干系人展示此类丰富的数据，这有助于做出更好的决策，检测问题并持续改进您的应用程序。您可以访问 [bit.ly/1IbRnrF](http://bit.ly/1IbRnrF) 详细了解 Application Insights。 图 4 和图 5 显示了Application Insights 收集的数据类型的示例。  图 4 Application Insights 可提供有关用户和页面视图的数据  图 5 Application Insights 还可以监视 Web 测试 ## 总结 开发运营帮助团队推动连续交付，并利用运行的应用程序中的数据来帮助做出更明智的决策。本文已检查可用于实现这些目标的各种主要的 Microsoft 技术： * Release Management 可让您使用任何技术来推动部署。这些技术包括简单的 Windows PowerShell 脚本、DSC 配置、甚至是 Puppet 等第三方工具。 * 基础结构即代码策略可帮助开发和运营团队高效地进行合作。 * Visual Studio Application Insights 为您提供了一种机制，可用于从运行的应用程序中捕获丰富的数据，从而帮助利益干系人了解应用程序运行状况，并检查使用情况模式来推动做出更明智的决策。 这些技术可帮助您显著提高开发运营的成熟度。您还需要融合一些适当的技术，同时努力克服文化障碍。 ### 更多资源 * 若要了解基础结构即代码的更多信息，请在 [bit.ly/1IiNqmr](http://bit.ly/1IiNqmr) 中的第 9 频道收听 Brian Keller 的讨论。 * 若要了解 Azure 资源组部署项目的更多信息，请参阅 [bit.ly/1flDH3m](http://bit.ly/1flDH3m)。 * 若要了解 TFS 规划、灾难避免和恢复以及 Azure IaaS 上的 TFS 的更多信息，请参阅[vsarplanningguide.codeplex.com](http://vsarplanningguide.codeplex.com/) 中的指南。 * 若要了解适合开发运营和 ALM 从业人员的配置即代码的更多信息，请参阅[vsardevops.codeplex.com](http://vsardevops.codeplex.com/)。 * * * Micheal Learned *是一位 Visual Studio ALM Ranger，目前侧重于开发运营和 Microsoft Azure。在超过 15 年的时间里，他负责 Microsoft 内部和外部的很多软件项目。他居住在伊利诺斯州中部，将自己的空余时间用于为社区提供帮助，并与妻子、女儿和两个儿子一起度过闲暇时光。通过 Twitter 与他联系：[twitter.com/mlhoop](http://twitter.com/mlhoop)。*