CN108701057B - 用于供应部署管道的计算机可读存储介质、系统和方法 - Google Patents

Abstract

本发明呈现了使用可继承的且可扩展的源代码模板‑通常被称为实时管道模板(LPT)来管理部署管道的技术。如所描述，实时管道模板可以用于管理部署管道，进而用于启动、维护和更新用于托管和提供计算服务的服务和系统。

Description

用于供应部署管道的计算机可读存储介质、系统和方法

发明背景

云计算已成为允许企业获得对大量计算资源的访问的广泛采用的方法。云计算所依据的主要技术之一是虚拟化。虚拟化允许物理计算服务器托管多个虚拟机实例，所述多个虚拟机实例中的每一个作为具有由操作系统管理的虚拟硬件部件，诸如CPU和存储器的独立计算系统执行。在启动之后，企业可以在虚拟机实例上以与在由企业使用的物理计算系统或服务器上运行应用相同的方式运行应用。由于可以根据需要启动附加的虚拟机实例，云计算允许企业根据需要获得计算资源，而不需投资和维护底层物理计算基础设施。

除了提供计算服务(例如，虚拟机实例)之外，云计算提供商还可以向企业客户提供各种其他计算资源和服务。例如，服务提供商可以提供数据库服务、永久存储服务、联网服务、负载均衡、自动缩放、消息服务、云搭建服务、监控服务等作为基于云的服务供应的一部分。

不管企业决定是在企业计算基础设施上托管计算服务还是使用来自云计算提供商的虚拟化服务，对用于托管计算服务的基础系统和服务进行配置都可能是一项富有挑战性的任务。因此，工程师可能要花费几天来对甚至是托管简单服务所需的系统和服务进行配置。另外，在部署之后，更新应用，改变基础系统和服务的配置或者将应用部署到附加系统或位置也可能需要大量的工程师时间。例如，假设企业想要部署零售购物网站，其中网站受到使用云计算提供商提供的服务部署的web服务器、应用服务器和数据库应用支持。实施起来尤其需要工程师对各种虚拟机实例(或实例类型)配置和供应所需的web和应用服务器应用程序，对这些系统提供内容，配置网络地址，配置数据库和存储服务，供应安全机制(例如，向所有面向公众的系统提供SSL证书)，配置管理性和基于角色的访问控制，配置和启动负载均衡系统，缩放群组以及配置监控、记录和报告应用。在部署之后，添加特征或更新用于提供面向公众的服务的软件(例如，零售网站)会需要类似水平的配置和供应。

云计算提供商在展示由部署零售网站的企业使用的基础云计算服务过程中会面临类似的挑战。例如，启动计算服务，自动缩放服务，数据库服务，存储服务等需要工程师在云计算提供商处单独地配置和供应用于提供每项云计算服务的基础计算系统和应用。

考虑到部署甚至是相对简单的计算服务的复杂性，企业将会频繁地开发部署或推广过程来对如何启动(或如何在新位置启动)新服务进行管理。部署过程通常可以指定正在供应的服务的配置。在一些情况下，部署过程还可以指定每个阶段伴随成功、失败或回滚条件的一组测试阶段-往往被称为部署管道-用于维护面向公众的服务(例如，先是集成测试，接着是α、β和γ阶段)。相同的部署管道可以在用于提供面向公众的服务的基础系统或服务改变时更新用于提供这种服务的应用、系统或服务。类似地，服务提供商可以定义用于将应用源代码中的变化(例如，漏洞修补或新特征)推出到托管给定服务的生产系统的部署管道。这种管道可以指定集成测试，α、β和γ测试阶段以及工作流，所述工作流用于核准或完成每个阶段，或者在正在投入生产的应用的新版本达不到核准要求或经证明对服务具有破坏性的情况下使应用回滚到先前状态。

然而，这种方法使得管理给定部署管道的工程师不仅要同时正确地配置和供应每个系统和服务，而且要在构建部署管道的过程中遵循任何企业最佳实践。如此行为会导致在用于其他类似的服务或应用的不同部署管道中产生不一致的结果。另外，这种方法限制了企业重复使用或标准化部署过程的能力。相反，工程师频繁地“剪切、粘贴和自定义”现有部署管道的元件来用于新服务(或现有服务的新实例)。在企业依赖于改变管理过程来更新应用或服务的特征或需求时会进行类似方法。在这类情况下，工程师需要花费大量时间来规划如何将更新部署到提供面向公众的服务的系统或应用并且对所述更新进行测试。因此，对于甚至是管理少量部署管道的企业来说，随着最佳实践的发展而维护、更新或改变部署管道组或者针对新的计算服务构建新的部署管道会需要大量工程资源。因此，在改进经由部署管道部署的实际应用或服务的质量或特征的过程中，管理一组部署管道可能已经变成了一项让企业分心的事物。

附图简述

现将参考附图描述根据本公开的各种实施方案，在附图中：

图1示出了根据一个实施方案的具有多个区域的云计算环境的示例，每个区域托管经由持续部署管道部署的生产计算服务的区域实例。

图2示出了根据一个实施方案的“元管道”的示例，所述元管道用于为生产计算服务构建和配置持续部署管道。

例如，图4示出了根据一个实施方案的实时管道模板的模板实例的源代码的示例。

图4示出了根据一个实施方案的图3中首先示出的实时管道模板的实例的源代码的示例。

图5是示出根据一个实施方案的用于配置部署管道的实时管道模板合成过程的数据流的概念图。

图6示出了根据一个实施方案的从图5所示的应用定义和LPT实例生成的持续部署管道的示例。

图7示出了根据一个实施方案的从实时管道模板创建用于部署生产计算服务的部署管道的方法。

图8示出了根据一个实施方案的由元管道修改部署管道的方法，所述部署管道自身用于基于实时管道模板的变化而部署生产计算服务。

图9示出了根据一个实施方案的用于确定是否可将实时管道模板的变化传播到持续部署管道的叶系统的方法。

图10示出了根据一个实施方案的基于现有实时管道模板而在最新可获得的云计算区域中自动配置和部署部署管道的方法。

图11示出了根据一个实施方案的叶系统驱动器的部件的示例，所述叶系统驱动器用于配置、部署和检查作为部署生产服务的一部分的计算资源。

图12是示出根据一个实施方案的实时管道模板分析过程的概念图，所述实时管道模板分析过程用于评估部署的计算服务的配置。

图13示出了根据一个实施方案的用于执行实时管道模板分析的管道分析引擎的部件。

图14示出了根据一个实施方案的识别生产管道中通过使用实时管道模板分析而暴露出的问题的示例界面。

图15是示出根据一个实施方案的用于评估部署管道的LPT分析过程分析的数据流的概念图，所述部署管道用于部署生产计算服务。

图16示出了根据一个实施方案的使用LPT分析过程监控部署管道的方法。

图17示出了根据一个实施方案的使用于现有计算服务的持续交付管道的配置和部署处于实时管道模板控制之下的方法。

图18示出了根据一个实施方案的用于托管实时管道模板服务的部件的示例计算系统。

具体实施方式

由云计算提供商提供的计算服务的可获得性和多样性持续增加。然而，对于云计算提供商来说，部署和维护提供给客户(或内部使用)的一系列计算服务已变得具有挑战性。将一系列应用或服务部署到云提供商并对所述应用或服务进行维护或者在其自身的计算基础设施上托管应用或服务的企业面临类似的挑战。

本文呈现的实施方案提供了使用可继承的且可扩展的源代码模板-通常被称为实时管道模板(LPT)来管理部署管道的技术。如本文详细所描述，实时管道模板允许企业客户和云计算提供商两者定义和管理部署管道，进而用于启动、维护和更新用于托管和提供计算服务的服务和系统。换言之，实时管道模板通常可以用于为给定类型的应用或服务封装部署管道的综合模型和生产配置。使用实时管道模板构建的部署管道有时被称为“持续部署管道”，因为经由这个管道部署的应用或服务的变化可以经由管道站自动朝向生产部署传播(或在检测到错误或冲突的情况下回滚)。

在一个实施方案中，代替开发部署过程或策略来从头部署新应用或服务(或将现有应用或服务部署到新位置)，开发者可以在实时管道模板的源代码中指定与特定服务或应用有关的少量信息。所述信息之后用于生成所述实时管道模板的新实例，使用由开发者指定的源代码来进行自定义。例如，开发者可以在实时管道模板中指定与应用或服务有关的高级别细节，诸如服务名称、管理者以及何处应该(或不应该)部署管道，诸如由云服务提供商提供的一组特定云计算区域。重要的是，针对给定应用或服务类型使用实时管道模板对部署过程建模会使部署管道的配置处于源代码控制之下。也就是说，代替使用改变管理命令或专设工作流来指定部署过程，使用实时管道模板的源代码来指定部署管道，之后可以由开发者针对所述实时管道模板的每个实例对所述部署管道进行定位。

实时管道模板的其余部分封装最佳实践来对对应于实时管道模板的服务的类型的实例进行配置、部署和维护。例如，实时管道模板可以指定部署管道所需的各种软件或其他制品，包括例如部署系统配置、部署用户、用于部署或更新应用的管道站、主机类、源代码存储库、虚拟机图像或配置、网络需求(例如，供虚拟机实例使用的虚拟IP地址)、SSL证书、用户名称、身份和访问控制信息、简报页面的内容、性能度量标准、回滚和稳态监控器、监控警报器等。

仅根据需要超控实时管道模板的特定元件允许实时管道模板被使用来生成持续部署管道的服务特定实例，而不需要开发者在部署给定服务类型的应用的过程中正确地配置遵循的所有最佳实践的部署管道。相反，实时管道模板封装所述服务类型所需的最佳实践并且可以用于将这类实践自动构建和配置到部署管道的服务特定实例中。因此，为复杂的生产服务配置和构建部署管道所需的时间可以从几天(或甚至几周)减少到几小时。

在一个实施方案中，在指定用于基于实时管道模板而定义新应用或服务的实例的高级别细节之后，使用所述实例来生成部署管道的综合模型。综合模型可以提供对部署管道的全面指定的配置以使用来部署所述应用或服务。通常被称为应用定义的这个综合模型可以在LPT合成过程期间使用来配置使部署管道实例化所需的系统和服务。应用定义可以使用机器可读交换格式来指定，例如指定为JSON或XML文档。在合成过程期间，启动、配置或以其他方式准备好部署管道所需的每个系统和服务以供使用。在LPT合成之后，所得的部署管道可以用于部署和维护生产应用或服务的实例。也就是说，部署管道可以用于使应用或服务准备好来接收客户流量，并且经由管道将服务的更新或新特征推向生产。

在一个实施方案中，LPT引擎可以包括一组叶系统驱动器，所述叶系统驱动器用于配置如由应用定义所指定的一组服务或系统。例如，每个叶系统驱动器可以提供对应于给定叶系统的软件应用，诸如监控服务、警报服务、部署服务等，所述给定叶系统被包括在经由应用定义建模的部署管道中。每个叶系统驱动器可以指定应用定义的哪些部分在被执行之前应该由其他驱动器实施。例如，配置警报服务的叶系统驱动器可能要求在配置和启动警报服务之前配置和操作监控服务。也就是说，每个叶系统驱动器可以实行对应的叶系统正确操作所需的任何依赖性。为了做到这一点，LPT引擎可以识别应用定义的哪些元素已被实例化，并且在依赖性被满足时，启动叶系统驱动器中的一个或多个。进而，叶系统驱动器执行API调用来使对应的叶系统与应用定义相一致，这允许执行附加叶系统驱动器，直到部署管道被完全实施为止。

实时管道模板允许企业设置用于部署给定服务类型的应用的最低自动实行标准。另外，可以使用受给定源代码语言支持的继承机制来用服务或域特定信息对基本实时管道模板进行扩展。例如，企业可以指定不管应用服务类型如何任何部署管道都应该遵循的一组最低限度最佳实践。给定服务类型的实时管道模板可以对企业范围模板进行继承，并且添加(或超控)企业范围实时管道模板中特定服务类型所特有的方面。另外，给定业务单元可以对服务特定模板进行继承并且指定业务单元信息(例如，用户名或访问权限)。最后，对于实时管道模板的特定实例，开发者可以将业务单元模板子类化，并且仅需要指定给定服务的实例特定细节，诸如服务类型、服务名称、管理者以及哪些云计算区域应当部署服务。

使部署管道的配置处于源代码控制之下允许与所述部署管道相关联的最佳实践的任何变化在所述管道的实例中检查和实施之前接受同行审查和评估。在一个实施方案中，在提交实时管道模板中指定的部署配置的变化时，LPT引擎可以更新基于所述实时管道模板的任何部署管道的配置。也就是说，(用于将应用或服务的更新或变化推向生产的)部署管道自身可以是用于将部署管道的变化推向生产的“影子”或“元管道”的目标。

除了在提交之前提供任何变化的同行审查之外，元管道可监控部署管道的给定变化被推向生产是否导致错误和冲突且是否应回滚。另外，除了对实时管道模板的变化作出响应之外，元管道还可以监控部署管道并且对云计算环境的变化作出响应。例如，LPT引擎可以被配置成在新的(或附加的)计算区域、区等变得可从云计算提供商获得(假设这类区域、区等中适当位置处的任何必要的服务依赖性被满足)时在其中从实时管道模板自动构建部署管道(所述部署管道之后可以配置和部署基础服务或应用)。

除了刚刚描述的LPT合成过程之外，LPT引擎还可以执行LPT分析过程，以便于针对给定应用或服务评估部署管道的配置，而不管所述应用或服务是基于实时管道模板还是使用LPT合成过程来部署。例如，在一个实施方案中，叶系统驱动器可以被配置成检查部署管道的配置，并且构建匹配所述部署管道的实际配置或与之配合的应用定义。例如，叶系统驱动器可以识别哪些阶段被包括在部署管道中，针对每个阶段配置了哪些警报器或监控器，在每个阶段配置或部署了哪些叶系统(例如，哪些虚拟机实例被供应、启动和投入生产)，对哪些主机类进行了定义等操作以及叶系统被如何配置。LPT引擎之后生成应用定义，所述应用定义使用经由LPT合成过程生成的相同的机器可读交换格式，例如JSON或XML文档描述所识别的配置。

在一个实施方案中，LPT引擎可以对照一组规则评估“基准”应用定义以识别部署管道中无法满足给定规则的需求的方面。规则可以用于确保部署管道遵循由企业建立的最佳实践。例如，规则可以确定部署管道在每个生产阶段之前是否包括γ和一体化测试阶段，或者确认部署管道中用于执行一体化和生产阶段的部署系统的自动回滚监控器的存在。更一般而言，规则可以使用条件语句或无条件需求或应该遵循或存在的属性来指定。在一些情况下，LPT引擎阻止部署管道被激活，直到所述部署管道满足一条或多条规则为止。然而，除了识别部署管道中未满足一条或多条规则的方面之外，LPT分析过程还可以建议“治愈”部署管道或使其与最佳实践相符所需的动作。也就是说，LPT引擎可以将给定规则违反与符合规则的解决方案配对。因此，LPT引擎可以向部署或开发团队提供教育和工具以整体符合由企业采纳(如规则中所表达)的最佳实践。

另外，相关业务单元可以指定哪些规则适用，以及给定LPT规则在所述业务单元内应该如何(或是否应该)实行，例如，是阻止部署管道还是仅仅提醒开发者某一方面不符合规则。在一个实施方案中，LPT引擎可以使用结果来自动改变部署管道的配置以符合一条或多条规则。当然，任何变化在实施之前还会被路由到开发者或管理员。可以按特定的间隔重复LPT分析过程以识别可能已由工程师手动作出的任何改变(即，绕过用于管理持续部署管道的元管道的改变)。

在其他情况下，LPT引擎可以从实时管道模板构建应用定义并且将所述应用定义与经由LPT分析过程生成的“基准”应用定义进行比较。这类差异可以作为建议呈现给开发者以改变实际部署的管道来匹配实时管道模板中指定的配置。这种方法允许LPT分析过程使部署的管道处于实时管道模板的源代码控制之下。也就是说，实际部署的管道可以成为元管道的目标，所述目标遵循基于介于实时管道模板应用定义与“基准”应用定义之间的差异而对部署的管道作出的任何改变。另外，将经由LPT分析生成的“基准”应用定义与从一组LPT模板生成的不同应用定义进行比较可以用于向开发者提供对哪些LPT模板与实际部署管道最配合的建议。

另外，在一个实施方案中，LPT分析过程可以用于帮助识别应该用于与给定应用或服务类型相关联的部署管道的最佳实践。例如，针对大量应用或服务给部署管道添加裕度的云计算提供商可以使用LPT分析过程来为具有常见服务类型模式的一组管道识别“基准”应用定义中的模式或惯例。如此行为可以允许云计算提供商构建反映一组最佳实践的实时管道模板，所述最佳实践随着时间的推移对于一系列持续部署管道来说已经“固定成型”。

有利的是，实时管道模板允许企业确保在用于将应用、服务和升级推向生产的持续部署管道中在可获得性、安全、测试、性能、部署和监控方面遵循可操作的最佳实践。此外，实时管道模板将实行和验证与工具组合以使应用或服务与部署最佳实践相符，随着操作准则或最佳实践的发展而保持应用或服务的部署管道与时俱进，并且帮助开发者正确地设置新服务。如此行为可以大幅减少因部署过程中可容易地预防的缺陷而引起的停运，并且减少开发者在操作设置和配置方面花费的时间。

应注意，本文相对于云计算提供商使用实时管道模板来部署和管理提供给企业客户的一系列生产服务的示例描述了一些实施方案。然而，本领域技术人员将容易认识到，相对于云计算提供商描述的实施方案可以适于或提供到企业，所述企业使用云提供商的服务来维护由云提供商托管的一系列应用或服务；并且适于部署管道，所述部署管道管理使用企业计算基础设施托管的应用或服务。

图1示出了根据一个实施方案的具有多个区域的云计算环境的示例，每个区域托管经由持续部署管道部署的生产计算服务的区域实例。如所示，计算环境100包括客户端计算系统105以及经由公共计算网络150 (例如，互联网)连接的三个云计算区域-区域A 120、区域B 130和区域C 140。客户端系统105被包括来表示通用计算系统，诸如台式计算机和膝上型计算机系统，而且表示移动计算装置，诸如配置有服务控制台应用程序或web浏览器软件的平板计算机和智能手机。

云计算区域120、130和140通常对应于在向客户端系统提供web服务(例如，用于构建生产服务125的服务)的过程中由服务提供商限定的区域。开发者可以供应、启动和管理每个云计算区域120、130和140内的虚拟化计算资源。虽然沿着任意边界绘制了云计算区域，但是云计算区域往往对应于地理、国家或容错边界，其中一个区域中的计算资源以通常与其他区域隔离的方式进行部署和管理。更确切地说，云计算区域120、130和140各自可以对应于位于特定地理区域中的一个(或多个)数据中心。不同区域中的数据中心可以帮助提供容错web服务，例如，如果某一区域中的一个数据中心变得不可访问，则所述区域(或其他区域)中的其他数据中心可以在几乎没有或没有中断web服务本身的情况下继续操作。另外，提供商可以在给定云计算区域内实现多个物理或逻辑区。例如，用于提供云计算区域的单一数据中心可以提供多个容错可用区，其中一个可用区中的服务中断不会影响同一个云计算区域(或其他区域)内的其他可用区，并且某一区域内的可用区可以向同一个区域内的其他可用区提供廉价的、低延迟的网络连接。

在图1的示例中，假设企业客户已经使用由云提供商提供的云计算服务在区域120中部署了生产服务125，在区域130中部署了生产服务135并且在区域140中部署了生产服务145。如所示，生产服务125包括一组虚拟机(VM)实例123、数据库126和永久存储设备128。此外，生产服务125包括负载均衡器124，所述负载均衡器用于将生产服务125接收到的请求分配到VM实例123中的一个上的客户端应用127。返回到零售网站的示例，假设每个VM实例123上的客户端应用127提供web和应用服务器，所述web和应用服务器被配置成根据需要访问数据库126和存储设备128以便于处理从客户端浏览器接收的HTTP请求。由于接收到请求，负载均衡器124将HTTP请求分配到VM实例123中的一个上的应用127上。在用户请求信息和订购产品时，应用127可以读取与客户请求或购买相关的数据并且将所述数据写入到数据库126和存储设备128。另外，生产服务125还可以结合由云提供商提供的各种其他计算服务。例如，可以基于需求使用自动缩放服务来增大或减小由生产服务125使用的VM实例123的计数。类似地，云监控服务可以监控VM实例123的健康并且收集与生产服务125相关的性能度量。虽然没有用相同程度的细节进行示出，但是区域130中的生产服务135和区域140中的生产服务145可以具有匹配区域120中的生产服务125的配置的部署配置。

如所示，生产服务125、135和145各自具有对应的管道部署代理129、139和149。管道部署代理129通常包括软件应用，所述软件应用用于将软件(例如，应用127)自动部署到生产服务125。管道部署代理139和149通常分别对生产服务135和145提供相同的功能。更确切地说，管道部署代理129、139和149可以被配置成持续地将软件、相关脚本、制品或配置状态等集成到生产服务125、135和145中。例如，管道部署代理129可以从源代码存储库构建应用127的可执行文件，在可执行文件上运行自动化测试套件来识别错误或冲突。如果自动化测试成功，则管道部署代理129可以开始将可执行文件推送到越来越广泛的生产环境中。在每个阶段，管道部署代理129可以监控生产服务125以确保正在部署的软件在整个部署过程中恰当地或在有关性能度量的任何限制内继续发挥作用。

管道部署代理129可在通过在各阶段将更新滚动到VM实例123上的应用127并在每个阶段期间监控错误或冲突的部署期间保护生产服务127免受停机时间。如果在软件推出到生产服务125时出现错误或意料之外的冲突或集成问题，则管道部署代理129可以使任何更新的VM实例上的应用127回滚到先前版本并且向开发者提供有关被中断的部署的日志和数据。

如所提及，部署管道可以包括用于构建、测试软件和相关制品并将其发布到生产服务125、135和145中的一组阶段。例如，由管道部署代理129、139和149使用的部署管道可以包括生产前测试阶段，诸如α或集成测试阶段；以及β测试阶段，其中使用自动化测试来对应用进行测试。在生产前阶段成功完成之后，但是在前进到处理实际客户流量或数据的部署阶段之前，可以用部署在生产环境中的应用执行γ或部署集成测试。在γ测试之后，客户流量获取阶段可以包括一体化阶段，所述一体化阶段用来对应用的单一生产实例进行测试(例如，通过更新单一VM实例123上的应用127)。在由部署管道对一体化测试指定的一段时间之后，管道部署代理129可以开始全面将应用部署到生产服务125。部署管道可以包括每个部署阶段的回滚监控器，以及用于服务度量的警报器，诸如有关VIP度量或JMX度量的警报器。这类警报器可以用于自动检测(和回滚)显示出会破坏生产服务125的迹象的部署。用于生产服务135和145的部署管道可以包括类似的测试和部署阶段以持续地将软件部署到生产中。

部署管道的配置会对可以如何测试成功的软件更新并将其投入生产(或者在部署阶段失败之后阻止所述软件更新或使其回滚)产生显著影响。另外，如上文所述，构建和配置部署管道会需要大量开发者时间。为了解决这些(和其他)问题，在一个实施方案中，部署管道142可以使用实时管道模板(LPT)引擎155来进行自我构建和部署。为了方便起见，LPT引擎155被示出处于区域140内。然而，区域120和130也可以包括LPT引擎155的实例。

在一个实施方案中，实时管道模板109提供源代码，所述源代码通常针对给定类型的应用或服务定义部署管道。虽然可以根据偏好指定使用的编程语言，但是可以使用通常支持面向对象的类和继承的任何语言。如所示，客户端系统105包括集成部署环境(IDE)107，所述集成部署环境可以用于生成实时管道模板109的服务特定实例，即，生成继承了实时管道模板109的源代码的LPT实例103。例如，实时管道模板109可以定义基类，所述基类对特定类型的生产服务，诸如工作流服务、请求回复服务等进行建模。开发者可以使实时管道模板109专用于通过对有待使用对应于实时管道模板109的LPT实例103的部署管道部署的生产服务指定实例特定细节来创建LPT实例103。在指定实例特定细节之后，LPT实例103的源代码可以被编译和执行(或解释)来生成部署管道的精确配置，所述精确配置包括由LPT实例103指定的生产服务的服务或实例特定细节，连同实时管道模板109中开发者未明确指定的所有最佳实践、安全机制、部署阶段等。

在一个实施方案中，LPT引擎155被配置成构建、更新和分析部署管道142。为了做到这一点，LPT服务155可以使用LPT实例103来生成对应于LPT实例103的部署管道的完整(和正确)配置。另外，管道部署代理129、139和149可以使用所得的部署管道142来在云计算区域120、130、140中构建和配置部署管道。

另外，在一个实施方案中，LPT引擎155可以被配置成使用元管道来将变化传播到从LPT实例103构建的部署管道。也就是说，就像部署管道可以用于将变化部署到生产服务125、135和145一样，元管道可以用于基于实时管道模板109或LPT实例103的变化而将变化传播到部署管道。例如，开发者可以改变实时管道模板109的内容来反映最佳实践的变化以用于随着这类实践的发展或改变而部署给定服务类型。例如，实时管道模板109可以被更新来包括由云提供商提供的新服务的配置，所述新服务可以改进使用实时管道模板109构建的部署管道。类似地，随着给定服务类型的最佳实践在企业内的变化，实时管道模板109可以被更新来反映企业的变化的需求。作为另一个示例，服务特定信息的变化(即，LPT实例103中的服务特定信息的变化)也可以使用元管道来传播到部署管道。例如，开发者可以改变LPT引擎155在哪个区域中通过更新LPT实例103的源代码来构建和配置部署管道，或者改变管理者或超控基本配置的其他方面来适应特定情况的需求。在这些示例中的每一个中，对部署管道的提出的变化可以在提交在实时管道模板109或LPT实例103的源代码中并以受元管道控制的方式部署到管道之前接受同行审查。

图2示出了根据一个实施方案的元管道210的示例，所述元管道用于为生产计算服务240构建、配置和更新持续部署管道230。如所示，元管道210包括一个版本的LPT包212和从LPT包212继承的一个版本的LPT实例214。元管道还包括构建阶段216和测试阶段218。LPT包212和LPT实例214通常对应于特定版次的实时管道模板206，所述实时管道模板连同构建和执行实时管道模板所需的任何相关制品或文件，例如描述从LPT实例214构建应用目标所需的构建过程和任何依赖性的文件一起存储在LPT存储库207中。

版本控制系统205用于管理存储在LPT存储库207中的实时管道模板206的源代码的修改。版本控制系统205允许企业对经由元管道210如何部署实时管道模板206的源代码(以及这个实时管道模板的实例)的变化进行管理和控制。也就是说，版本控制系统205使部署管道230的配置处于源代码控制之下。通常，高级开发者或工程师可以负责审查和核准实时管道模板206的源代码(以及这个实时管道模板的实例)的任何变化。如此行为可确保部署管道230反映企业使用部署230来部署生产服务240的最佳实践和需求。

如由箭头2220所示，元管道210的输出或目标可以是应用定义。例如，当LPT包212和LPT实例214起初提交到版本控制系统205时(即，在可获得版本1.0.0之后)，元管道210可以用于构建应用定义215。在一个实施方案中，应用定义215可以指定综合模型，所述综合模型全面指定了用于构建和部署生产服务240的部署管道230的配置。应用定义215可以使用机器可读交换格式来指定，例如指定为JSON或XML文档。进而，LPT引擎155可以配置、供应和构建部署管道230的第一实例。

在构建阶段216期间，LPT包212和LPT实例214被编译来生成可以生成应用定义215的软件。例如，LPT包212和LPT实例214可以包括可以使用熟知的Ant构建工具构建的软件包。在构建之后，所得的软件包可以被执行(或解释)来生成应用定义215。作为说明，元管道210包括测试阶段218，所述测试阶段用于评估构建阶段216的结果(即，应用定义215)。例如，测试阶段218可以对照指定对部署管道的最低需求的一套规则评估应用定义215。如此行为可以帮助确保开发者不会以导致不完整或不可操作的部署管道230或者导致无法满足企业所指定的某些最低标准或需求的部署管道230的方式超控LPT实例214中的LPT包212的元件。

在构建(在构建阶段216期间)和测试(在测试阶段218期间)之后，所得的应用定义215可以提供到LPT引擎155。如使用箭头250所表示，LPT引擎155可以像应用定义215中指定的一样构建和配置部署管道230。在图2的示例中，部署管道230包括构建阶段234、生产前阶段236和生产阶段238。在一个实施方案中，为了构建部署管道230，LPT引擎155可以调用一组叶系统驱动器，所述叶系统驱动器用于配置处在部署管道230之下的一组对应的叶系统。也就是说，叶系统驱动器用于配置共同构成部署管道230的基础系统、应用或服务。例如，叶系统驱动器可以配置部署系统，所述部署系统被配置成根据需要管理生产前阶段236和生产阶段238，创建VM实例的主机类，配置虚拟网络地址和计算资源之间的路由，供应和配置VM实例或其他虚拟计算资源，设置监控警报器、部署回滚阈值、性能监控器等，以便于维护部署管道230。

在一个实施方案中，在部署管道230的初始启动之后，元管道210可以在经由版本控制系统205提交实时管道模板206的变化时将实时管道模板206的变化传播到生产中。也就是说，元管道210可以用于将LPT包212和LPT实例214的发布版本中反映的实时管道模板206的变化传播到部署管道230。在一个实施方案中，在由版本控制系统205提交和发布新版本时，元管道210可以将LPT包212或LPT实例214的新版本自动传播到部署管道230的生产中。当然，元管道210还可以根据需要调用来将实时管道模板206的新版本推送到部署管道230。

在LPT引擎155完成部署管道230的初始供应和配置之后，部署管道230可以用于部署(和更新)提供生产服务240的软件应用和系统。源代码存储库227可以存储生产服务的源代码，连同可以存储在源代码存储库227中的相关配置、数据和其他制品。生产服务240的源代码的变化可能受到版本控制系统225的制约，其中变化在提交之前首先要接受审查。在提交生产服务240的源代码的变化，从而产生源代码232的新的构建包时，部署管道230可以经由部署管道230更新生产服务240。

如所示，例如，部署管道230包括构建阶段234，所述构建阶段编译源代码232以为部署生成候选可执行文件。在这个示例中，在构建阶段234期间生成的可执行文件首先传递到生产前阶段236，并且如果可执行文件通过了在这个阶段执行的测试，则所述可执行文件传递到生产阶段238。在生产前阶段236期间，可执行文件在用于处理客户流量之前使用集成测试、测试套件和样本数据等来测试。在生产阶段238期间，可以将可执行文件推向更广泛的生产用途，直到生产服务240内更新的应用的部署完成为止。如，生产阶段测试可以包括γ集成阶段测试、一体化测试以及最终的全面生产部署。同样在生产阶段238期间，性能监控器和警报器可以监控如部署在生产环境中的可执行文件的性能。如果可执行文件在超过警报阈值的速率下失效，或者另外由于性能低下而导致警报被触发，则部署管道230可以回滚部署。此外，部署管道230可以生成由开发团队使用的日志和相关数据以理解由什么导致部署要回滚。

图3示出了根据一个实施方案的实时管道模板(LPT)实例300的部件，所述实时管道模板实例继承了来自其他管道模板的部署管道配置数据。如所示，LPT实例300包括部署管道模板的继承层次，其中层次中的每个模板可以超控从层次中的其他管道模板继承的方面并且将附加配置数据添加到LPT实例300。在这个特定示例中，LPT实例300包括企业基本模板305、服务类型模板310、团队特定模板315以及服务特定模板320。当然，本领域技术人员将认识到，模板的数量、模板之间的继承模式或每个模板中存储什么信息可以根据需要针对给定部署管道或企业实践来定制。

在一个实施方案中，企业基本模板305可以用于为持续部署管道封装特定企业内使用的任何部署管道都应遵循的一组最佳实践或需求。例如，考虑提供客户计算、数据库、存储、联网和监控服务等的云服务提供商。尽管存在不同服务类型，但是由云提供商提供的计算服务中的每一个可能共有一些部署实践。例如，企业可能要求用于更新在这些计算服务之下的软件的任何部署管道应当在与客户流量一起使用之前进行集成测试并且最初应当使用一体化阶段来部署在具有客户流量的生产中。在这种情况下，可以在企业基本模板305的源代码中捕获这些需求。

如所示，服务类型模板310继承了企业基本模板305中指定的部署管道配置。服务类型模板310可以用于例如指定给定服务类型所特有的部署管道需求。继续云服务提供商的示例，服务类型模板310可以包括提供到客户的服务中的给定服务所特有的配置数据。例如，用于更新提供虚拟化数据库服务的软件和系统的部署管道可以包括一系列特定β测试，所述β测试用于测试查询的延迟，所述查询用于读取使用服务供应的数据库的测试实例/将数据写入到所述测试实例。类似地，用于计算服务的部署管道可以包括测试阶段，所述测试阶段根据由提供商提供的每个实例配置类型启动不同的VM实例并且测试VM实例的正确性。更一般而言，由云计算提供商提供的每种计算服务可以具有封装于对应的服务类型模板310中的一组不同的部署需求。除了对部署管道指定附加配置参数之外，服务类型模板310可以超控或扩展企业基本模板305中指定的任何需求。然而，通常，基本模板305包括应被包括在给定企业内使用的任何部署管道中而在将企业基本模板305归入子类的过程中不应被超控的企业最佳实践或需求。

团队特定模板315对企业基本模板305和服务类型模板310两者进行继承，并且可以扩展或超控企业基本模板305或服务类型模板310的方面。团队特定模板315可包括由负责管理给定服务的部署团队使用的配置数据。再次使用向企业客户提供计算服务的云计算提供商的示例，团队特定模板315可以将服务类型模板310扩展成包括与对经由从LPT实例300构建的部署管道部署的生产服务进行管理的开发团队有关的信息。例如，开发团队可以使用服务类型模板310来包括实时管道模板300中的团队信息，诸如用户名时运行、访问控制权限等以用于被包括作为如由企业基本模板305和服务类型模板310所指定的持续部署管道的一部分的叶系统。

最后，LPT实例300的模板实例320继承了企业基本模板305、服务类型基本模板310和团队特定模板315中指定的部署管道的配置。在一个实施方案中，模板实例320利用与用于部署生产服务的部署管道的特定实例相关的服务或实例特定参数对这些模板进行扩展(或超控这些模板中的方法)。模板实例320可以用服务特定信息对其他模板进行扩展，诸如服务名称、管理者以及何处应该部署从实时管道模板300构建的部署管道，例如部署到由云服务提供商提供的一列指定的云计算区域。

例如，图4示出了根据一个实施方案的图3所示的LPT实例300的模板实例320的示例的源代码。在这个示例中，源代码包括以Ruby编程语言编写的Ruby模块400。

如由第1-4行所示，Ruby模块400用“请求回复服务”的服务类型对部署管道的服务类型模板310进行扩展。确切地说，第4行声明名称为“TemplateInstance”的类作为名称为“Lpt::Templates::RequestReplyService”的另一个管道模板类的子类。Ruby模块400的第06-29行指定用从LPT实例300构建的部署管道的实例的服务或实例信息超控服务类型模板310的方法的方法。

首先，第06-08行声明名称为“pipeline_name”的Ruby方法并且定义生产管道的部署实例的名称。第10-13行声明名称为“pipeline_description”的Ruby方法并且提供对实时管道模板的这个特定实例的文字描述。在这个示例中，描述指出正在定义的部署管道用于部署请求回复服务，所述请求回复服务自身用于提供可以向请求客户端提供IP地址的区域请求/回复服务。

Ruby模块400的第15-17行声明名称为“pipeline_notification _email_address”的Ruby方法并且指定从LPT实例300构建的部署管道的电子邮件地址。这种电子邮件地址可以用于向开发团队的成员发送与部署管道有关的消息。例如，部署管道可以向负责构建和管理使用部署管道部署的特定服务的开发团队自动发送与部署管道中的每个测试阶段的成功(或失败)有关的电子邮件消息。

第19-21行声明名称为“dimensionality”的Ruby方法，所述Ruby方法用于指定部署管道的逻辑部署单元。在这种情况下，管道的维度处于云计算区域的层次，即，处于云计算提供商向其中提供服务的不同地理区域的层次。在其他情况下，部署管道可以被构建来在云计算区域内的个别可用区中、在私营企业网络内或在可以部署计算服务的其他逻辑或物理区内部署软件。相关地，第23-25行声明名称为“blacklisted_dimensionality”的Ruby方法，所述Ruby方法指定不应部署对应于LPT实例300的部署管道的一组区域。在这个示例中，黑名单区域包括在欧洲和亚洲的云计算区域，从而使生产服务部署于在美国或北美和南美的区域的数据中心中。如下所述，指定不应该配置部署管道的云计算区域的“黑名单”允许所述部署管道自动部署到可获得的新计算区域(前提是新计算区域内也要满足部署管道的任何服务依赖性)。当然，Ruby模块400中声明的另一种方法可以指定应该部署部署管道的正面清单。Ruby模块400的第27-29行声明名称为“deployment-service_run_as_user”的Ruby方法。这种方法指定在供应和配置从LPT实例300构建的部署管道的测试阶段(或其他元素)的过程中供叶系统驱动器访问的部署服务的用户名。

最后，第31-36行包括注释，所述注释指出由Ruby模块400表示的模板实例320从高级模板，即在这个示例中为从企业基本模板305、服务类型基本模板310和团队特定模板315继承了模板内容。如由Ruby模块400所示，从高级模板(即，在这种情况下从“RequestReplyService”模板)子类化允许开发者通过在模板实例320的源代码-在这个示例中为Ruby源代码的下面30行中指定与特定服务或应用有关的少量信息来生成用于构建部署管道的实时管道模板的实例(例如，LPT实例300)。开发者之后可以将实时管道模板实例化并运行所述实时管道模板来构建部署管道，而不需直接指定构建部署管道所需的最佳实践、安全机制、部署阶段等。

图5是示出根据一个实施方案的用于将部署管道实例化的实时管道模板合成过程的数据流的概念图。如所示，LPT实例500被构建和执行来创建应用定义510。进而，LPT引擎555使用应用定义510来根据应用定义510供应和配置部署管道530。也就是说，在LPT合成过程期间，LPT引擎555供应、配置、启动服务或系统或者让它们做好准备，需要所述服务或系统来使部署管道530进入状态，在所述状态下，部署管道530可以开始部署生产应用。

在这个特定示例中，LPT实例500包括三个管道模板的层次-企业管道模板505、服务类型模板507和模板实例509。如上所述，企业管道模板505可以捕获在企业层指定的部署管道的一组基本最佳实践和需求。另外，服务类型模板507可以将企业管道模板505扩展成包括用于部署特定类型的服务(例如，相对于图4论述的请求回复服务)的部署管道的需求和配置信息。进而，模板实例509对服务类型模板507进行扩展，以便于指定部署管道的特定实例(例如，相对于图4论述的Ruby模块400)的细节。如所提及，企业管道模板505、服务类型模板507和模板实例509可以使用源代码(例如，Ruby)来表示并且在版次控制系统的控制下接受管理。

合起来，企业管道模板505、服务类型模板507和模板实例509形成LPT实例500。在使用模板实例509来对这些基本模板进行继承并根据需要来使所述基本模板专用于特定部署管道之后，将所得的LPT实例500编译(或以其他方式构建)和执行来生成用程序定义510。继续基于Ruby编程语言的示例，LPT实例500可以传递到MRI Ruby解释器并且执行来生成应用定义510。

在一个实施方案中，应用定义510被定义为暗指结构化文档(例如，JSON文档512)的Ruby模型。将应用定义510格式化为结构化文档512以交换格式提供了对部署管道530的描述，LPT引擎555的各种软件部件可以使用所述描述来供应和配置部署管道530 (同样用于评估部署的管道的配置状态)。应用定义510可以指定有待供应和实例化的部署管道的配置。另外，如下文更详细所描述，由LPT引擎555生成的输出在评估现有部署管道的过程中用于通过查询一组叶系统来了解部署管道的当前配置状态。

在一个实施方案中，应用定义510提供了被包括在部署管道530中的每个叶系统532-544的全面指定的配置，而不存在任何未解决的变量、宏或其他外部引用。在生成之后，可以由被包括在LPT引擎555中的一组LPT合成驱动器517-529对应用定义510进行解析，所述LPT合成驱动器之后可以根据应用定义来供应和配置被包括在部署管道530中的叶系统532-544。

如所示，JSON文档512-名称为“MyApplication.LPT”说明了部署管道530的配置的一部分。在图5的特定示例中，应用定义512的所述部分包括一组“性能度量监控器”的配置信息，所述性能度量监控器用于监控为云计算区域(名称为“US-East”)中设置和部署的“生产”数据的一部分的虚拟机器主机的状态。当然，JSON文档512中所含的信息的特定内容和结构可以根据应用定义中描述的相关叶系统的能力和特定情况的需求来定制。

在一个实施方案中，LPT引擎555包括一组LPT合成驱动器517-529。每个LPT合成驱动器517-529可以提供对应于叶系统532-544中的特定叶系统的一份软件。另外，每个LPT合成驱动器可以对应用定义510中与特定LPT合成驱动器相关的部段进行解析和解释(并且忽略其他部段)以了解部署管道530中对应的叶系统的所需配置。在对应用定义510进行解析之后，每个LPT合成驱动器可以被配置成识别存在或已供应了对应的叶系统的哪些元素以及其当前配置状态。另外，在识别之后，LPT合成驱动器可以确定一组API调用以对照对应的叶系统调用以使所述叶系统的配置与应用定义510一致。

LPT合成驱动器517-529还可以声明在给定LPT合成驱动器能够配置对应的叶系统之前应该实施应用定义510的哪些其他部分。例如，用于配置监控性能度量并生成警报的警报服务544的LPT合成驱动器(即，驱动器529)可以要求生成性能度量的性能监控服务542在警报服务544被激活之前进行配置和运行。

在图5的特定示例中，被包括在LPT引擎555中的LPT合成驱动器517-529包括管道驱动器517，部署驱动器519，主机类、主机和自动缩放组(ASG)驱动器521，网络和安全驱动器523，身份和访问管理(IAM)驱动器525，性能监控器驱动器527以及警报监控驱动器529。

在一个实施方案中，LPT合成驱动器517-529通过向叶系统532-544传递配置状态的描述来在对应的叶系统上实施所需配置。进而，对应的叶系统确定为了在所述叶系统上实施所需配置需要哪些变化。也就是说，叶系统532-544可以被配置成响应于来自对应的LPT合成驱动器517-529的消息而改变其相应的配置状态。然而，LPT合成驱动器517-529还可以根据需要调用API调用来直接改变配置状态、设置、属性、参数或性质等。管道驱动器517可以用于配置管道服务532。在一个实施方案中，管道服务532可以包括系统和服务，所述系统和服务在源代码存储库中监测应用的新版本并且开始经由部署管道530将所述应用推向生产的过程。因此，管道服务517可以用于供应具有适当的构建工具(例如，编译器、解释器等)的VM实例，指定源代码存储库、构建目标和安装脚本或工具连同从生产服务的源代码构建一组可执行软件所需的任何其他相关制品。类似地，管道驱动器517可以对由管道服务532使用的警报器进行配置，以在为正在部署的应用的新版本创建构建目标时提醒开发团队构建错误或警告。

部署驱动器519可以用于配置部署服务534。在一个实施方案中，部署服务535可以包括系统和服务，所述系统和服务推动由管道服务创建的构建目标经过一系列测试阶段并且如果成功的话推向生产。因此，部署服务534可以配置VM实例，所述VM实例可以将构建目标部署到生产前测试环境中并且执行应用定义510中指定的任何“沙箱”测试。部署服务还可以例如使用一体化测试周期将构建目标部署到生产服务器上，之后逐渐部署到全面生产。部署驱动器519还可以将部署服务534配置成对相对于由性能监控服务542 (如由性能监控器驱动器527所配置)和警报服务529 (如由警报驱动器527所配置)提供的性能度量生成的警报作出反应。在这种情况下，部署驱动器519可以要求在配置依赖于性能监控服务542和警报服务544的部署环境之前供应和部署并激活性能监控服务542和警报服务544。

主机类、主机和ASG驱动器(简称为主机驱动器521)可以用于配置计算服务536。在一个实施方案中，计算服务536可以包括VM实例和由作为正在部署的生产服务的一部分的VM实例使用的相关服务。例如，主机驱动器521可以为用于运行由管道服务532构建的应用目标的VM实例配置主机类。例如，主机驱动器521可以配置主机类“服务器”，所述主机类服务器指定用于托管应用服务器的VM实例的特征。在配置之后，主机驱动器521可以访问计算服务536以启动“服务器”主机类的VM实例池并且将它们与由管道服务532构建的应用目标一起部署到由部署配置驱动器519供应的环境。类似地，主机驱动器521可以配置自动缩放服务(在这个示例中被提供为计算服务536的一部分)，所述自动缩放服务基于由生产服务接收的需求而启动(或移除)来自该池的“服务器”主机类的VM实例。在这种情况下，主机驱动器521可以要求供应和配置性能监控服务542和警报服务544，以便于创建自动缩放组来管理部署到该池的主机。主机驱动器521还可以配置使用部署管道530正在部署的生产服务所需的各种其他计算服务，例如，诸如以下的服务：数据库服务、存储服务、消息服务、通知服务、工作流服务等。

网络和安全驱动器523可以用于配置网络服务538。在一个实施方案中，网络和安全驱动器523可以供应由驱动器519启动的VM实例所使用的数据通信网络。例如，网络和安全驱动器523可以配置虚拟IP地址(VIP)，所述虚拟IP地址用于为由主机驱动器521部署的VM实例创建网络。为了做到这一点，应用定义510可以指定IP地址的配置、域名信息、交换和路由信息、防火墙或流量整形规则、边缘服务器的位置或CDN的地址等。另外，网络和安全驱动器523还可以在VM实例与安装安全证书，例如VM实例和应用上的SSL证书之间供应虚拟专用网络。如此行为允许由部署管道530正在部署的生产服务的应用使用加密通道彼此通信(或与客户端系统通信)。

身份和访问管理(IAM)驱动器525可以用于配置身份服务540。在一个实施方案中，IAM驱动器525可以供应被包括在生产服务的部署中的VM实例上，即由主机驱动器521启动的VM实例上的用户账号、用户名、访问控制列表、访问规则等。

如所提及，性能监控器驱动器527配置性能监控服务543，并且警报监控驱动器529配置警报服务544。在一个实施方案中，监控服务543和警报服务544可以用于监控由部署管道530正在部署的应用、系统或服务的任何可测量的方面，以及部署管道530自身的方面。另外如所提及，其他LPT合成驱动器可以在将软件应用传播通过部署管道530并传播到生产的过程中中以及在监控生产服务自身的性能的过程中依赖于警报器的配置或性能度量的值。

图6示出了根据一个实施方案的使用图5所示的应用定义510和LPT实例包500，使用LPT合成过程生成的持续部署管道的示例。在这个示例中，部署管道600用于在两个生产前测试阶段(即，α测试阶段604和β测试阶段605)中以及在三波生产测试阶段中将版次传播到源代码包602，所述生产测试阶段将应用目标603部署到三组云计算区域。

源码包602对应于源代码和构建应用目标603所需的任何相关文件(例如，构建文件、存储库、图像、web或媒体内容等)。在这个示例中，管道启动601表示对持续部署管道是否自动将版次部署到源码包602 (例如，每个新版本提交到版本控制系统)的设置，或者要求开发者触发有待传播通过部署管道602并传播到生产中的特定版本。在任一种情况下，在触发之后，部署管道检索源码包602并且构建应用目标。

如果从源码包602对应用目标603的构建是成功的，则部署管道600前进到α阶段测试604。通常，α阶段测试被执行来使用测试框架或工具模拟应用目标的预期用途。开发团队内的用户也可以在α阶段测试期间在模拟生产环境中与应用目标交互。然而，由于部署管道600通常用于使部署过程自动化，在许多情况下可以省略直接用户交互。α阶段测试还可以包括执行集成测试来确定应用目标603是否恰当地与其他已经部署的系统和/或服务交互，所述系统和/或服务是正在部署应用目标603的生产服务的一部分。如果应用目标603没有通过α阶段测试604之一(或者另外无法满足对α阶段测试指定的阈值需求的任何组合)，则部署管道600可以中止应用目标603的部署并且向开发团队提供记录数据。例如，部署管道600可以向用于构建部署管道600的实时管道模板的模板实例中指定的管理者发送消息。

如果应用目标603成功通过α阶段测试604，则部署管道600可以前进到β阶段测试605。通常，β阶段测试可以包括。例如，β阶段测试605可能包括部署动作，所述部署动作将应用目标603部署到由部署管道600启动的一个或多个开发用服务器。在β阶段测试605期间，可以按需根据任意组度量来监控和评估在开发用服务器上运行的应用目标603的性能以确定应用目标在开发用环境中是否正确地操作。就像α阶段测试604一样，如果应用目标604无法满足对β阶段测试605指定的任何性能需求，则部署管道可以中止应用目标603的部署并且向开发团队提供记录数据。

在生产前测试阶段之后，即在α阶段测试604和β阶段测试606之后，部署管道600可以开始将应用目标603推向更广泛的生产用途，直到应用目标603被完全部署为止。在图6的特定示例中，部署管道600包括三个生产部署波。在每波中，应用目标603被推向面向一组不同计算区域的生产。每波包括γ阶段测试，所述γ阶段测试用于在前往区域客户流量获取阶段之前测试区域配置和在应用目标603与给定云计算区域之间的集成配合度。在γ阶段测试之后，每波包括用来检测致命错误或延迟问题的一体化阶段。在一体化阶段期间，在实时提供环境中测试单一实例应用目标。在监控一段时间之后，部署管道600可以前进到全面生产部署阶段，其中应用目标603滚出到给定云计算区域中托管应用目标603的各自的服务器。

当然，应用目标603传播到全面生产所处的速率和停止、中止或回滚正在进行的部署的条件可以作为实时管道模板的一部分进行指定，所述实时流水模板用于使用上文论述的LPT合成过程来使持续部署管道600实例化。例如，如所提及，部署管道600可以包括每个区域内的每个生产阶段的回滚和性能监控器、以及有关服务度量的稳态警报器和用于在应用目标部署到生产使用中时监控所述应用目标的有关服务度量的其他警报器，诸如有关VIP度量或JMX度量的警报器。然而，重要的是，构建部署管道600的开发者在构建部署管道600的过程中并不需要明确指定这些安全特征、回滚条件、警报或性能度量阈值等中的任一个。相反，这些特征通过选择实时管道模板来暗示以用服务实例模板加以扩展，并且在LPT合成期间由LPT引擎自动生成在部署管道600中。

在图6的示例中，应用目标603首先在γ/集成阶段622期间部署到名称为“AP-Southeast-1”的计算区域。在这个阶段之后，应用目标603接着部署在一体化生产阶段614中并且之后部署在全面生产部署阶段616中。如果应用目标603完全部署到“AP-Southeast-1”计算区域，则部署管道600在第二部署波期间重复这个过程。因此，第二部署波也包括γ/集成阶段622、一体化生产阶段624和全面生产部署阶段626，它们用于将应用目标部署到三个附加云计算区域-名称为“SA-East”、“US-West”和“AP-Southeast-2”。在第二波的每个阶段，(实时管道模板的基本模板中指定的)性能监控器和警报器可以监控应用目标603在这些区域中的部署。应注意，部署管道600可以独立地监控“SA-East”、“US-West”和“AP-Southeast-2”区域的每一个中的应用目标603。因此，应用目标603最终会被成功地传播到这些区域中的少于所有三个的区域。最终，如果应用目标603传播到“SA-East”、“US-West”和“AP-Southeast-2”计算区域中的一个或多个，则部署管道600继续在最终部署波期间将应用目标603传播到两个附加的计算区域(在这个示例中名称为“EU-West”和“US-East”)。类似于第一波和第二波，最终部署波包括γ/集成阶段632、一体化生产阶段634和全面生产部署阶段636，其中部署管道600保持监控应用目标603，直到所述应用目标被完全部署到生产中(或因性能问题而被停止)为止。

应注意，在这个示例中，部署管道600的区域可以已由LPT引擎通过从可获自提供商的计算区域的总列表减去图4所示的服务实例模板的第23-25行中明确列入黑名单的区域来计算(而不是明确地指定)。另外，LPT引擎155可能已通过生成部署波来自动为选定区域预定部署流，所述部署流开始于起初具有最低流量的计算区域并且终止于具有最高流量的区域(其中其余区域处于中间部署波中)。当然，开发者可以定义图4所示的模板实例320中的方法，所述模板实例明确指定了部署命令流或甚至单一计算区域。

更一般而言，本领域普通技术人员将认识到，α、β、γ、一体化和全面部署阶段的使用被包括来说明企业可以纳入从实时管道模板构建并用于将应用目标603传播到生产中的部署管道中的测试类型。另外，在实践中，部署管道600可以配置有这些或其他测试阶段，但是它们可根据需要标记或配置来适应特定情况的需求。

图7示出了根据一个实施方案的从实时管道模板创建用于部署和更新生产计算服务的部署管道的方法700。如所示，方法700开始于步骤705，其中实时管道模板引擎接收LPT包。LPT包可以包括用于实时管道模板的服务特定实例的源代码，所述实时管道模板对一个或多个基本管道模板的层次子类化。服务特定实例可以根据需要扩展和/或超控一个或多个基本模板，以对持续部署管道指定有限数量的服务实例特定细节。一个或多个基本管道模板可以捕获一组最佳实践、安全特征、回滚条件、警报或性能度量以用于部署给定服务类型的生产服务的应用或部件。

在步骤710处，适当的构建工具可以构建LPT包的应用目标。使用图4所列的Ruby模块400作为示例，LPT包可以使用MRI Ruby解释器来执行以便于将应用定义的内容写入到文件。如所提及，应用定义可以提供部署管道的全面指定的配置，而不存在任何未解决的变量、外部引用或宏。应用定义可以结构化交换格式进行格式化(例如，JSON格式化文档)。

在步骤715处，可以将所得的应用定义传递到LPT引擎，所述LPT引擎使用被包括在LPT引擎中的一系列LPT合成驱动器来根据应用定义供应、启动、配置部署管道的系统或服务部件或者以其他方式让它们做好准备。在步骤725处，LPT合成驱动器对应用定义进行解析以识别应用定义中与给定LPT合成驱动器相关的一个或多个部段。

在步骤730处，LPT合成驱动器中的每一个可以确定是否满足对配置对应于给定LPT合成驱动器的叶系统的任何需求。例如，用于配置部署服务的部署驱动器可以依赖于在构建部署环境的生产前测试阶段和生产测试阶段之前配置的监控和警报服务。类似地，用于提供自动缩放组的自动缩放服务可能需要在配置自动缩放组之前可获得的自动缩放组中使用的VM实例的主机类配置。更一般而言，每个LPT合成驱动器可以声明应用定义的哪些其他部分需要在其被触发来配置应用定义中指定的部署管道的元素之前实施。

在对给定LPT合成驱动器的任何需求已被满足之后，所述驱动器就可以配置应用定义中指定的部署管道的对应的叶系统部件。在步骤735处，如果给定LPT合成驱动器成功配置了对应的叶系统部件，则在步骤740处，LPT引擎报告错误并且停止LPT合成过程以免其继续配置部署管道的叶系统部件。当然，可以捕获日志数据或其他消息并将其发送到开发团队，从而指示哪些LPT合成驱动器无法根据应用定义配置对应的叶系统以及出现了什么错误。否则，如果配置成功，则在步骤745处，LPT引擎确定是否需要多个LPT合成驱动器来配置管道的叶系统部件。如果是这样的话，则方法700返回到配置附加叶系统部件的步骤730。通常可以重复这个过程，直到出现错误或者部署管道完全配置好并准备好用于部署生产服务为止。

在例如根据图7的方法700部署之后，所得的持续部署管道自身可以是元管道的部署目标。如所提及，元管道可以用于将对实时管道模板作出的改变传播到持续部署管道中。换言之，元管道与部署管道的用于传播应用或生产服务的其他部件的变化的动作是分开的。图8示出了根据一个实施方案的由元管道修改部署管道的方法800，所述部署管道自身用于基于实时管道模板的变化而部署生产计算服务。

如所示，方法800开始于步骤805，其中元管道(或LPT引擎的部件)检测改变与持续部署管道相关联的LPT包的记录版本的触发事件。在一个实施方案中，LPT引擎可以监控被提交到版本控制系统内的部署版本分支的实时管道模板的源代码的变化。

例如，随着部署管道的最佳实践或偏好在企业或业务单元变更内的发展，开发团队可以更新企业基本模板的源代码。作为另一个示例，可以更新企业基本模板的源代码以在新服务或现有服务的新特征在托管生产服务的云计算区域内变得可获得时利用所述新服务或新特征。作为附加示例，可以改变实时管道层次中的多个特定模板的方面，诸如添加附加联系人信息的开发团队模板，或者为了超控基类模板中的附加方法或从服务特定模板移除列入黑名单的区域而对服务特定模板作出的改变。后一个示例可以产生全新的系统和服务的实例，所述系统和服务用于提供在新计算区域中供应和启动的持续部署管道。

LPT实例或模板的基础层次的什么变化会经由元管道触发传播到持续部署管道的变化可以在具体情况下根据偏好来定制。另外，除了触发部署管道的更新的实时管道模板的变化之外，云计算环境的变化也会导致元管道被用来修改部署管道。例如，如果可获得新的云计算区域，或者如果部署管道所需的某些服务被供应和启动于现有的云计算区域中，则元管道可以用于在这类计算区域中为新的持续部署管道供应和启动系统和服务。当然，开发者还可以手动地激活元管道来将实时管道模板的变化传播到生产使用中。

再次参考图8，在步骤810处，使用LPT引擎来从实时管道模板的更新的源代码构建更新的应用定义。在步骤815处，开始循环，其中LPT合成驱动器中的一个(或多个)对更新的应用定义进行解析以识别指定对应的一个(或多个)叶系统的所需配置状态的部段。如所提及，一些LPT合成驱动器可能对其他合成驱动器具有依赖性。在各自通过循环开始步骤815时，可以使用不具有任何未被满足的依赖性需求的LPT合成驱动器来基于更新的应用定义而更新对应的叶系统的配置状态。

在步骤820处，LPT合成驱动器可以将所需配置状态传递到对应的叶系统。进而，叶系统可以确定是否可以作出改变或者从LPT合成驱动器传递的配置状态是否可以在叶系统上实施(步骤825)。例如，每个叶系统可以识别介于所述叶系统的当前状态与由对应的LPT合成驱动器请求的所需状态之间的差异。如果给定叶系统的配置状态无法修改或像LPT合成驱动器所请求的那样实施，则在步骤830处，对应的LPT合成驱动器报告错误，并且对所述叶系统作出(或作为更新部分对其他叶系统作出)的任何改变可以回滚到先前的配置状态。当然，可以捕获日志数据或其他消息并将其发送到开发团队，从而指示更新的应用定义如何与当前部署管道冲突或者描述为什么无法更新部署管道。

否则，在步骤835处，如果需要处理多个叶系统，则方法返回到步骤815，其中LPT合成驱动器中的一个(或多个)继续在对应的一个(或多个)叶系统上实施应用定义，直到部署管道被完全更新(或出现中断更新的错误)为止。

图9示出了根据一个实施方案的确定实时管道模板的变化是否可以传播到持续部署管道的叶系统的方法900。方法900大体上示出了可以作为图8的方法800的步骤835的一部分执行的步骤。如所示，方法900开始于步骤905，其中叶系统识别介于当前配置状态与由LPT合成驱动器请求的目标配置状态之间的差异。

在步骤910处，叶系统可以确定目标配置状态可能需要哪些其他服务、应用部件或服务依赖性。也就是说，叶系统确定为了在所述叶系统上实施目标配置状态需要满足什么依赖性。

在步骤915处，叶系统可以确定是否可获得在步骤910处识别的系统或服务，或者另外是否满足叶系统的任何需求。例如，实时管道模板的更新可以指定对第一叶系统的配置，所述配置需要第一叶系统不可获得的其他叶系统或服务。在其他情况下，给定叶系统可以确定更新的应用定义引用了尚未部署到给定托管区域的给定叶系统的特征。

叶系统还可以确定是否满足所述叶系统所需的任何服务依赖性。例如，一个区域中的叶系统可能要求可获得应用定义未明确引用的不能从所述区域获得的其他服务。例如，用于在面向公众的服务器系统上供应和配置安全证书，同时经由部署管道部署应用的网络安全服务可能具有要求访问证书认证机构的依赖性，所述证书认证机构发布标记出由网络安全服务生成的公钥的数字证书。作为另一个示例，管道服务可能具有与以下各项相关的依赖性：源代码存储库、版本控制系统和托管管道服务所在的云计算区域中的可获得的构建工具的可获得性。

如果无法获得由更新的应用定义指定的任何服务或依赖性，或者识别到任何未解决的依赖性问题，则叶系统可以向LPT合成驱动器报告错误(步骤920)。否则，意味着满足所有依赖性，则在步骤925处，叶系统可以确定是否可实现叶系统的更新的配置状态(步骤920)。也就是说，叶系统还可基于该叶系统的操作能力来验证任何参数、属性或目标配置状态的其他方面。如果发现任何配置冲突或无效的配置设置，则叶系统可以向LPT合成驱动器报告错误(步骤935)。否则，在步骤930处，叶系统更新所述叶系统的当前配置状态以匹配从LPT合成驱动器接收的目标配置状态。在实施之后，叶系统可以向对应的LPT合成驱动器报告已完成更新。

图10示出了根据一个实施方案的基于最新可获得的云计算区域中的现有实时管道模板而为部署管道自动配置和部署系统和服务的方法1000。

如在图4的Ruby模块400中所示，在一个实施方案中，开发者可以在启动部署管道的过程中指定要从LPT合成过程排除的一组计算区域。因此，要阻止经由所述管道部署的生产服务在该同一组计算区域中启动。如果开发者从该组移除了一个云计算区域，或者在提供商供应新的云计算区域的情况下，则可以触发方法1000来配置用于在这类云计算区域中部署基础生产服务的部署管道。

如所示，方法1000开始于步骤1005，其中LPT引擎(或元管道)检测新的云计算区域的存在，其中可获得使用持续部署管道部署的生产服务。这种管道可以使用对应于实时管道模板的LPT实例来建模。在步骤1010处，LPT引擎确定新区域是否托管支持生产服务所需的叶系统或服务。此外，LPT引擎可以确定新的云计算区域是否托管部署管道所需的叶系统和服务。也就是说，LPT引擎确认在新的云计算区域中可获得由应用定义引用的部署管道的叶系统部件。

在步骤1015处，LPT确定在新的云计算区域中是否可获得与生产服务相关联的任何服务依赖性。此外，LPT引擎可以确定在新的云计算区域中是否可获得与构建和启动部署管道所需的叶系统或服务相关联的任何服务依赖性。也就是说，除了确认可获得应用定义中明确引用的叶系统和服务(步骤1010)之外，LPT引擎还确认对于生产服务和用于部署所述生产服务的部署管道两者来说可在新的云计算区域中获得与这类叶系统和服务相关联的任何依赖性。

在步骤1020处，LPT引擎基于步骤1010和1015而测试是否可从新的云计算区域获得用于部署管道和基础生产服务两者的叶系统和服务(以及服务依赖性)。如果无法获得，则方法1000结束，因为新的计算服务未满足部署管道的需求或基础生产服务(或两者)。当然，可以生成日志数据或其他消息并将其发送到开发团队，从而指示新的云计算区域的可获得性。这类消息可以指示未满足哪些叶系统、服务或其依赖性，并且因此哪些叶系统、服务或其依赖性会阻止实时管道模板使用来在新的云计算区域中启动部署管道。

图11示出了根据一个实施方案的LPT合成驱动器1100的部件的示例，所述LPT合成驱动器用于配置、部署和检查作为部署生产服务的一部分使用的叶系统1130的计算资源。如图所示，LPT合成驱动器1100包括应用定义解析部件1105、叶系统检查部件1110、叶系统控制器1115和服务依赖性数据集合1120。

应用定义解析部件1105提供LPT合成驱动器1100的用于识别应用定义的相关部段的软件元件。考虑到应用定义，解析部件1105对描述对应于LPT合成驱动器1100的叶系统1130的配置的部段进行解释，并且忽略应用定义的其他部段。例如，对于被构建为JSON文档的应用定义，解析部件可以在JSON文档中搜索被解析部件1105辨别的键值。在识别之后，解析部件1105可以从与所辨别的键值相关联的JSON元素提取叶系统1130的所需配置。例如，假设叶系统1130对应于由云计算提供商托管的部署服务。在这种情况下，解析部件1105可以识别描述部署管道中的所需部署阶段的JSON元素，诸如图6所示的用于低流量、高流量和中间流量云计算区域的三波的γ、一体化和生产阶段。

叶系统检查部件1110提供LPT合成驱动器1100的软件元件，所述软件元件可以访问叶系统1130并且识别叶系统1130的当前配置状态、参数、操作状态、性能度量或特征、或其他相关属性或性质。叶系统检查部件1110可以在下文描述的LPT分析过程期间使用。在一个实施方案中，叶系统检查部件1110可以调用叶系统API 1125所展示的API调用来访问、查询或检查叶系统1130。继续部署服务的示例，叶系统检查部件1110可以调用叶系统API1125来识别什么阶段存在于部署管道中，在每个阶段成功或失败的条件，由什么监测警报，回滚条件或性能监控器在每个阶段是否到位等。

叶系统控制器1115提供LPT合成驱动器1100的软件元件，所述软件元件可以请求叶系统1130根据需要来修改叶系统1130的配置或操作状态以实施由部件1105从应用定义解析出的目标配置。为了做到这一点，叶系统控制器1115可以调用API调用1125来传递叶系统1130的目标配置状态。

继续部署服务的示例，叶系统控制器1130可以请求部署服务基于性能度量(例如，对客户端请求的响应的平均延迟)而修改生产部署阶段以对回滚部署设置较低阈值。这种修改可以响应于在为部署管道构建LPT实例的过程中使用的企业基本模板中捕获的最佳实践的变化而进行。在这种情况下，元管道可以(经由解析部件1105)识别这种变化，(经由控制器部件1110和API 1125)将改变的配置传递到叶系统1130，并且确认改变已被实施。

服务依赖性数据1120识别应该在叶系统驱动器1110检查或配置叶系统1130之前配置和获得部署管道中的哪些叶系统。也就是说，服务依赖性数据1120识别在叶系统1130自我配置之前需要完整配置部署管道中除了叶系统1130之外的哪些叶系统。再次继续部署服务的示例，服务依赖性数据可以指示在叶系统驱动器访问或修改叶系统1130之前经由部署服务配置的部署管道的每个部署阶段所需的任何警报器或性能监控器。

除了上文描述的LPT合成过程之外，LPT引擎还可以执行LPT分析过程，以便于针对给定生产应用或服务评估部署管道的配置，而不管所述应用或服务是使用实时管道模板还是使用上文描述的LPT合成过程来部署。另外，虽然在上文中被描述为LPT合成驱动器，但是在一个实施方案中，LPT合成驱动器可以包括用来提供以下将详细描述的LPT分析驱动器的功能的叶系统检查部件1110。因此，虽然在本文中为了方便起见单独描述了LPT合成驱动器和LPT分析驱动器，但是本文论述的LPT合成驱动器和LPT分析驱动器可以被实施为集成的LPT合成和分析驱动器。

图12是示出根据一个实施方案的执行LPT分析过程的LPT服务1220的部件的概念图，所述LPT分析过程用于评估部署管道1229的配置，所述部署管道自身用于部署和更新生产计算服务1223。如所示，生产服务1223被托管在全球计算云1200中。生产服务1223自身包括托管客户端应用1227的一系列VM实例1224。生产服务1223还包括负载均衡器1225、存储服务1228和数据库服务1226。例如，生产服务1223如相对于图1所描述可以提供零售网站。另外，系统和服务的实例用于提供部署在全球计算云1200的多个云计算区域中的生产服务1223云，例如全部示出于图1中的区域120中的生产服务125、区域130中的生产服务135和区域140中的生产服务145。

在这个示例中，生产服务1223可以使用部署管道1229来部署和更新。部署管道1229可以包括全球计算云1200内可获得的一套服务和系统，所述服务和系统用于配置、供应和启动全球计算云1200内的计算服务1224-1228。此外，在开发团队更新客户端应用1227或对计算服务1224-1228更新所需配置时，部署管道1229可以将这类变化传播到生产服务1223。

对于这个示例，假设开发者手动地配置和部署由部署管道1229使用的系统和服务。在这种情况下，部署管道1229可能缺乏由管理生产服务1223的企业或业务单元偏爱的最佳实践、安全机制、部署阶段、回滚能力等中的一些-或者可能仅仅是不完整的或未被正确地配置。

在一个实施方案中，托管在全球计算云1200中的LPT服务1220可以被配置成检查部署管道1229，以识别在部署管道1229的偏爱的配置与部署管道1229的实际配置状态之间的任何不一致。如所示，LPT服务1230包括LPT引擎1232、应用定义1234、管道分析引擎1236、规则1238以及LPT分析报告1240。在一个实施方案中，LPT引擎1232可以生成“基准”应用定义1234，所述应用定义根据用于LPT合成过程的相同的结构化交换格式，例如JSON格式化文档描述部署管道1229。

另外，LPT服务1230可以包括一系列LPT分析驱动器(例如，图11的具有检查部件1110的LPT合成驱动器1100)。在一个实施方案中，每个LPT分析驱动器用于访问自身用作部署管道1229的一部分的服务或系统，并且确定所述服务或系统的当前配置状态。基于当前配置，LPT分析驱动器可以生成根据交换格式格式化的应用定义1234的一部分。在每个LPT分析驱动器评估部署管道1229之后，所得的应用定义1234可以传递到管道分析引擎1236。

进而，管道分析1236可以对照一组规则1238来评估应用定义1234。规则1238可以用于为部署管道捕获最佳实践或配置需求。也就是说，规则1238可以用于确保部署管道1229遵循由部署管道的企业建立的最佳实践。规则1238中的一些可以应用于由企业使用的所有部署管道以部署和维护生产服务，而其他规则对于给定服务类型来说可能是特定的。

在一个实施方案中，可以就由企业基本模板305指定的部署管道的方面对规则1238进行建模。类似地，可以就服务类型模板310的方面针对特定服务类型对规则1238进行建模(上文相对于图3对两者进行了论述)。例如，企业范围规则1238可以指定每个部署管道必须包括作为每个生产部署阶段的一部分的γ和一体化测试阶段。类似地，另一条规则1238可能要求对部署管道中的一体化和生产阶段配置自动回滚监控器。在后一种情况下，规则1238的服务特定规则可以用于指定最小性能阈值，所述最小性能阈值应该在触发回滚机制并且中断无法满足最小性能阈值的部署之前应用于生产系统。当然，本领域技术人员将认识到，可以基于企业的需求和实践、可获得来构建部署管道的服务、由部署管道部署的服务的类型和特定情况的境遇等而定制规则1238的实质内容。

在评估应用定义1234之后，管道分析1236可以生成LPT分析报告1240。LPT分析报告1240可以(基于“基准”应用定义1234)提供对部署管道1229的当前配置的指示，连同对部署的管道1229满足或未满足哪些规则1238的指示。除了暴露对部署管道的任何批评，诸如规则违反或与部署管道1229的配置状态有关的警告之外，LPT分析报告1240还可以指定应该对部署管道1230的配置采取哪些措施或改变来纠正给定规则违反。例如，LPT分析报告1240可以建议部署管道中的测试阶段的数量、次序或类型的改变、回滚监控器的配置和值、有关性能度量的警报器、被包括在部署管道中的系统和服务的类型等。

另外，在一个实施方案中，LPT服务1230可以对部署管道1226中发现的规则违反提供“一键修复”。在这种情况下，LPT分析报告1240可以指定与给定规则违反相关的纠正措施。根据来自开发者的请求，LPT服务1230之后可以修改“基准”应用定义1234的部分(或修改基础实时管道模板的源代码)以对LPT分析报告1240中识别的规则违反进行补救。作为响应，LPT服务1230可以使用上文描述的LPT合成过程来将修改后的应用定义1234的变化(或基础LPT实例的变化)传播到部署管道1229。

在另一个实施方案中，管道分析1236可以将“基准”应用定义与另一个应用定义进行比较，并且生成反映任何不一致或差异的LPT分析报告1250。例如，开发者可以选择匹配与生产服务1223相关联的服务类型或与之配合的服务类型实时管道模板。作为响应，管道分析1236可以将使用这个实时管道模板生成的应用定义与“基准”应用定义1234进行比较。在另一种情况下，“基准”应用定义1234可以与用于构建部署管道1234的应用定义进行比较。如此行为可以识别直接对部署管道1229作出的与LPT实例和用于构建部署管道1229的对应的应用定义相冲突的改变。在任一种情况下，LPT分析报告1234可以被生成来将由应用定义表示的配置的任何不一致识别为在部署管道1229中要解决和纠正的潜在问题。

另外，在一个实施方案中，LPT分析报告还可以建议专用于部署管道1229的实时管道模板。如此行为将允许开发团队使部署管道1229处于LPT合成过程的源代码控制之下，并且开始使用元管道来维护部署管道1229的配置。例如，管道分析1236可以将“基准”应用定义1234与从不同的LPT模板实例构建或在高级基本或服务类型模板上建模的应用定义进行比较。取决于应用定义之间的相似性，管道分析1236可以在实时管道模板的LPT分析报告1240中包括最匹配部署管道1229的“基准”配置或另外与之配合的建议。

图13示出了根据一个实施方案的用于执行LPT分析过程的管道分析1236的部件。如所示，管道分析1236包括差异比较部件1300、规则评估部件1305、建议部件1310以及报告部件1315。部件1300-1315通常提供管道分析1236的软件元件，所述软件元件用于对部署管道1229的配置状态进行评估和报告。

差异比较部件1300提供管道分析1236的软件元件，所述软件元件被配置成将一个应用定义与另一个应用定义进行比较并且识别由被比较的应用定义表示的部署管道的差异。例如，差异比较部件1300可以将不同的应用定义中的给定叶系统的结构化内容进行比较，并且生成描述给定叶系统的配置的任何差异的报告。可以对部署管道1229中的每个叶系统部件重复所述过程。如所提及，如此行为可以允许开发团队理解为了使操作的部署管道处于实时管道模板的控制之下需要对操作的部署管道作出什么改变。在其他情况下，可以使用比较来识别直接对最初使用LPT合成过程配置的部署管道作出的改变。在其他情况下，差异比较部件1300可以将从候选管道模板构建的多条潜在部署管道与实际部署管道进行比较，以帮助识别应该使用来使实际部署管道处于源代码控制之下的候选管道模板。

规则评估部件1305提供管道分析1236的软件元件，所述软件元件可以确定应用定义是否满足一组一条或多条规则。在一个实施方案中，由部件1305评估的应用定义可以表示实际部署管道的“基准”状态。如此行为可以允许开发团队理解使用中的部署管道对一组最佳实践或准则遵循到什么程度。类似地，规则评估部件可以协助开发团队诊断没有像预期那样操作的部署管道。在另一种情况下，规则评估部件1305可以评估从LPT实例构建的尚未用于构建部署管道的应用定义。如此行为可以帮助开发者理解候选管道模板是否满足该组规则中反映的任何最佳实践或操作需求。

规则建议部件1310提供管道分析1236的软件元件，所述软件元件可以协助开发团队修改未满足给定规则的部署的元件。如所提及，建议可以提示部署的管道的变化以使所述部署管道与企业实践相符或者解决不能正确发挥作用的部署管道中的问题。另外，LPT服务可以允许开发者在请求之后实施由建议部件1310提示的变化。

在另一种情况下，评估部件的结果可以与同手动配置的部署管道相关联的核准工作流整合。在这种情况下，核准工作流可以基于由管道分析1236识别的任何规则违反的可定制的严重级别而阻断部署管道。

报告部件1315提供软件元件，所述软件元件通常被配置成从由差异比较部件1300、规则评估部件1305和建议部件1310生成的信息构建报告。例如，图14示出了根据一个实施方案的呈现持续部署管道的LPT分析报告的示例界面1400。如所示，界面1400包括用于呈现由管道分析的报告部件1315生成的信息的一系列版块。如所示，界面1400包括服务数据版块1405，所述服务数据版块指示相关部署管道、相关联的生产服务和使用管道分析评估的LPT实例。在这个示例中，就图4所示的LPT实例的源代码对服务数据进行建模。

风险报告版块1410显示了在评定版块1405中识别的部署管道的实际配置的过程中由评估部件1305生成的一组结果。在这个特定示例中，风险报告指示US-East计算区域中的部署管道缺少生产阶段的回滚监控器，并且US-West计算区域中的部署管道在US-West计算区域中的两个可用区的一个中缺少γ阶段测试。严重程度版块1415指示在US-East计算区域中缺失回滚监控器对这个区域中的生产服务带来的风险比在US-West计算区域中的两个可用区的一个中缺失γ阶段测试更为严重。纠正版块1415显示可将建议的修复用于由管道分析1326识别的两种风险中的每一种。在这个特定示例中，建议的修复只是添加缺失的部件，即，将缺失的回滚监控器添加到US-East区域中的部署管道并且将缺失的γ阶段添加到US-West区域中的相关可用区。此外，界面1400包括“点击以修复”版块，所述版块允许开发者将建议的纠正应用于这些部署管道。如果使用的话，则可以使用上文论述的LPT合成技术来自动纠正由管道分析1326识别的规则违反。

除了可以呈现与部署管道未满足的规则相关联的风险的风险报告1410之外，差异报告版块1430用于显示两个应用定义之间的差异比较的结果。如所示，已将US-East区域中的部署管道的实际实例与用来构建这个部署管道的LPT实例进行了比较。另外，在这个示例中，实际配置匹配由LPT实例指定的配置。变化比较按钮1435可以用于选择哪些部署的管道、应用定义或LPT实例比较来生成差异报告1430。

图15是示出根据一个实施方案的用于评估部署管道的实时管道模板分析的数据流的概念图，所述部署管道用于部署生产计算服务。如所示，LPT引擎1515用于检查部署管道1530的部署好的配置。LPT引擎1515使用部署好的配置来构建描述部署好的配置的应用定义1510。进而，管道分析引擎1509可以对照一组规则评估表示部署好的配置的应用定义1510，并且将应用定义1510与其他应用定义进行比较。也就是说，在LPT分析过程期间，LPT引擎1515评定和检查被包括作为部署管道1530的一部分的服务和系统，以便于构建反映部署管道1530的实际配置状态的综合模型。另外，在确定之后，所得的应用定义1510可以使用各种方法来评估以识别与部署管道1530的配置状态有关的优点、弱点或者其他定性或定量度量。

在一个实施方案中，类似于在图5所示的LPT合成过程期间生成的应用定义510，在图15所示的LPT分析过程期间生成的应用定义1510可以被定义为暗指结构化文档(例如，JSON文档1512)的Ruby模型。使用由LPT合成过程使用的相同交换格式来将应用定义1510格式化可确保LPT引擎1515和管道分析引擎1509的软件部件可以处理不管是使用LPT合成过程还是使用LPT分析过程生成的应用定义，而不需进行任何翻译或转换。

JSON文档1512-名称为“DeployedApplication.LPT”-示出了经由LPT分析驱动器1517-1529从部署管道1530获得的应用定义的一部分。在图15的特定示例中，应用定义1512的所述部分包括一组“性能度量监控器”的配置信息，所述性能度量监控器用于监控为云计算区域(名称为“US-East”)中设置和部署的“生产”数据的一部分的虚拟机器主机的状态。当然，JSON文档1512中所含的信息的特定内容和结构可以根据应用定义中描述的相关叶系统的能力和特定情况的需求来定制。

如所提及，LPT引擎1515的输出基于被包括在部署管道1530中的叶系统的配置状态而提供部署管道1530的“基准”应用定义1510。在这个特定示例中，部署管道1530包括七个基础叶系统1532-1544，每个基础叶系统具有在应用定义1510中建模的单独配置。在一个实施方案中，LPT引擎1515包括Ruby内存中工作流，所述Ruby内存中工作流被执行来通过触发LPT分析驱动器1517-1529来查询对应的服务叶系统1532-1544而生成应用定义1510。工作流的步骤可以被配置成使得每个步骤声明工作流在给定LPT分析驱动器1517-1529开始运行之前可能要完成应用定义1510的哪些部分。例如，生成部署环境信息以包括在应用定义1510中的部署配置驱动器1519可能期望在运行之前管道驱动器1517已检查管道服务1532并且产生了应用定义1510。这在管道配置可能为由驱动器1519识别可在部署服务1534中访问哪些部署环境时可能是这种情况。在一个实施方案中，LPT引擎1515的依赖性解析器选择运行哪些LPT分析驱动器，直到所有叶系统1530受到全面检查为止。

在一个实施方案中，LPT引擎555包括一组LPT分析驱动器1517-1529。每个LPT分析驱动器517-529可以提供对应于叶系统1532-1544中的特定叶系统的一份软件。另外，每个LPT分析驱动器1517-1529可以访问部署管道1530中的对应的叶系统1532-1544并且检查所述叶系统的配置。基于检查，叶系统驱动器1532-1544构建应用定义1510中与特定LPT分析驱动器相关的部段(并且忽略其他部段)以构建对部署管道530的完整描述。

在图15的特定示例中，被包括在LPT引擎1515中的LPT分析驱动器1517-1529包括管道驱动器1517，部署驱动器1519，主机类、主机和自动缩放组(ASG)驱动器1521，网络和安全驱动器1523，身份和访问管理(IAM)驱动器1525，性能监控器驱动器1527以及警报监控驱动器1529。

管道驱动器1517可以确定管道服务1532的配置，所述管道服务用于在源代码存储库中监测应用的新版本并且开始经由部署管道1530将所述应用推向生产的过程。部署驱动器1519可以确定部署服务534的配置。例如，部署驱动器1519可以识别对一系列测试阶段的部署好的配置，所述测试阶段用于将应用传播到生产环境中。

主机类、主机和ASG驱动器(简称为主机驱动器1521)可以用于确定由部署管道1530使用的计算服务1536的配置。例如，主机驱动器1521可以确定由部署管道1530使用(或由部署管道1530所部署的生产服务使用)的VM实例、缩放组、主机类的配置。主机驱动器1521还可以确定由部署管道1530使用的各种其他计算服务1536 (或对应的生产服务)的配置，例如，诸如以下的服务：数据库服务、存储服务、消息服务、通知服务、工作流服务等。

网络和安全驱动器1523可以用于确定经由部署管道1530部署的网络服务，诸如IP和SSL服务1538的网络配置。例如，网络和安全驱动器1523可以识别由部署管道1530使用的IP地址的配置、域名信息、交换和路由信息、防火墙或流量整形规则、边缘服务器的位置或CDN的地址等。另外，网络和安全驱动器1523可以识别哪些安全证书，例如SSL证书已被部署在经由部署管道1530部署的VM实例和应用上。身份和访问管理(IAM)驱动器1525可以用于确定供应在部署管道1530上的身份服务1540的配置，例如VM实例上授权用户对部署管道1530的访问的用户账号、用户名、访问控制列表、访问规则等的配置。

性能监控器驱动器1527可以用于确定已针对部署管道1530配置了哪些性能监控器的配置。例如，性能监控器驱动器1527可以识别经由部署服务1534部署的每个生产前和生产测试阶段期间测量了哪些度量。类似地，警报监控驱动器1529可以确定基于由性能监控器驱动器1527配置的性能度量而在部署管道1530中配置了哪些性能警报和阈值的配置。

如所示，应用定义1510可以传递到管道分析引擎1509，所述管道分析引擎可以生成报告文档1508，所述报告文档列出了任何规则违反或介于应用定义1510与另一个应用定义之间的差异。在这个特定示例中，报告1508也使用交换格式(例如，JSON)来构建，从而允许由发布引擎1507消费所述报告。进而，发布引擎1507可以推送工作流服务1505和LPT服务控制台1506 (或发布由其读取的消息)。如所示，报告1508描述了与在US-East区域内生产测试阶段中“缺失”回滚监控器相关的规则违反。

在一个实施方案中，发布引擎1507可以是由云计算提供商托管的服务。这种服务将允许其他系统订阅接收与给定主题有关的消息或警报。在当前上下文中，发布引擎1507可以将报告1508提供到LPT服务控制台1506，所述LPT服务控制台可以生成将报告呈现给开发者的界面(例如，图14的界面1400)。工作流服务1505可以被配置成为一系列部署管道自动处理由发布引擎1507发布的报告，并且发送有关由企业使用的部署管道的总体“健康”的消息。当然，其他系统和服务可以消费由发布引擎1507发布的报告1508。例如，在一个实施方案中，被包括在报告1508中的违反可以被调度成由LPT引擎自动使用LPT合成过程来纠正(或路由到开发者团队以供审查和核准)。

应注意，虽然单独示出于图5和图15中，但是图5所示的LPT合成驱动器517-1529可以与图15所示的LPT分析驱动器1517-1529一起集成为组合式LPT叶系统驱动器，所述组合式LPT叶系统驱动器提供上文描述的LPT合成过程和LPT分析过程两者的功能。

在一个实施方案中，上文描述的LPT分析过程可以用于监控对部署管道作出的改变并就所述改变发出警报，或者根据需要或定期检查部署管道的配置。例如，图16示出了根据一个实施方案的使用LPT分析过程监控部署管道的方法1600。如所示，方法1600开始于开发者将用于监视监控器所涉及的持续部署管道的监控器实例化。例如，在使用实时管道模板部署之后，开发者可以配置监控服务来检测对被包括在部署管道中的叶系统作出的任何改变。在其他情况下，管道分析引擎可以被配置成定期执行批处理来识别和评估一个或多个部署管道的当前的配置。

在步骤1610处，监控器保持观察部署管道，直到检测到所监控的叶系统中的一个的变化为止。在叶系统中的一个的配置改变之后，则在步骤1615处，LPT引擎可以构建表示部署管道的当前配置的应用定义。在其他情况下，LPT引擎可以根据开发者的需要或定期(例如，在不存在对修改管道的请求或观察管道的监控器的情况下，或者作为对给定服务类型的所有部署管道的审查的一部分)针对给定部署管道构建应用定义。

在步骤1620处，可以使用反映持续部署管道的最佳实践或操作需求的一组规则来评估所得的应用定义。如所提及，规则可以基于部署管道中的配置的叶系统而指定如果-则条件语句，或者指定对部署管道的一般需求。在步骤1625处，LPT引擎可以将在步骤1615处生成的应用定义与另一个应用定义进行比较，诸如从用于构建在检测到的变化之前处在考虑中的部署管道的实时管道模板生成的应用定义。

在步骤1630处，管道分析引擎可以生成报告，所述报告指定了在步骤1620处识别的任何规则违反或者介于部署管道的当前配置与针对部署管道生成的参考配置之间的差异。如所提及，可以供发布服务(或其他系统)消费的交换格式生成报告。在步骤1635处，管道分析引擎可以生成对部署管道的变化的建议以解决在步骤1620处识别的规则违反。可选地，管道分析引擎可以被配置成自动重新配置部署管道的计算服务以解决任何规则违反(或向管理员发送请求来核准对部署管道的一组修改)。

在其他实施方案中，可以自动进行重新配置来实行给定部署管道的配置状态，而不管任何规则违反。也就是说，管道分析引擎可以被配置成自动使对被包括在给定部署管道中的计算服务作出的改变复原。例如，在检测到用于提供部署管道的计算服务中的一个的变化(即，叶系统中的一个的变化)之后，管道分析引擎可以从LPT实例构建应用定义，所述LPT实例用于提供对所述部署管道的权威配置。在构建之后，可以调用LPT合成驱动器来根据提供在应用定义中的全面指定的配置而重新配置计算服务。

图17示出了根据一个实施方案的使持续交付管道的配置和部署处于实时管道模板控制之下的方法1700。如所示，方法1700开始于步骤1705，其中LPT引擎构建对应于持续交付管道的应用定义。例如，LPT引擎可以对手动配置并由开发者部署的部署管道构建应用定义。

在步骤1710处，LPT引擎可以将如在步骤1705处生成的应用定义中所反映的考虑中的部署管道的特征与其他应用定义进行比较。用在比较中的其他应用定义中的每一个可以对应于实时管道模板，所述实时管道模板可以经由通用实例特定参数而专用于对考虑中的部署管道提供LPT实例。在其他情况下，已被完全专门化并用于构建部署管道的LPT实例可以被包括在步骤1710处执行的比较中。在一个实施方案中，比较的结果可以指示对从考虑中的部署管道生成的应用定义与其他应用定义中的给定应用定义之间的相似性或配合度的度量。在其他情况下，开发者可以指定匹配准则，所述匹配准则用于确定从考虑中的部署管道生成的应用定义与其他应用定义之间的比较的匹配度或配合度。

在步骤1715处，如果LPT引擎识别出配合的实时管道模板，则在步骤1720处，LPT引擎可以建议使用配合的实时管道模板来管理考虑中的部署管道。例如，开发者可以指定在步骤175处评估的匹配准则以识别配合的实时管道模板(例如，给定服务类型的部署管道或具有某些阶段、警报或开发过程的管道的匹配者)。在步骤1725处，如果选择匹配的实时管道模板来管理部署管道，则可以使用所述实时管道模板来使部署管道的配置处于源代码控制之下。为了做到这一点，可以提示开发者利用用于定义LPT实例的实例特定细节将与匹配的实时管道模板相关联的一个或多个基类实时管道模板专门化。所得的LPT实例可以用于使用LPT合成过程来重新配置部署管道。

图18示出了根据一个实施方案的用于托管本文论述的实时管道模板服务的部件的示例计算系统1800。如所示，计算系统1800包括但不限于中央处理单元(CPU) 1805、网络接口1815、存储器1820以及存储设备1830，每一者连接到总线1817。计算系统1800还可以包括I/O装置接口1810，所述I/O装置接口将I/O装置1812 (例如，键盘、显示器和鼠标装置)连接到计算系统1800。在本公开的上下文中，计算系统1800中所示的计算元件可以对应于物理计算系统(例如，数据中心中的系统)或者可以是在计算云内执行的虚拟计算实例。另外，虽然被示出为在单一计算服务器1800上运行，但是存储器1820和存储设备1830中的部件可以部署在多个计算服务器上。

CPU 1805检索存储在存储器1820和存储设备1830中的程序指令和应用数据。互连1817用于在CPU 1805、I/O装置接口1810、存储设备1830、网络接口1815和存储器1820之间传输程序指令和应用数据。应注意，CPU 1805被包括来表示单一CPU、多个CPU、具有多个处理核心的单一CPU等等，并且存储器1820通常被包括来表示随机存取存储器。存储设备1830可以是磁盘驱动器或快闪存储装置。虽然被示出为单一单元，但是存储设备1830可以是固定和/或可移动存储装置的组合，诸如固定盘驱动器、可移动存储卡、光存储设备、网络附加存储设备(NAS)或存储区域网(SAN)。

作为说明，存储器1820包括LPT引擎1822，所述LPT引擎自身包括LPT合成引擎1824、LPT分析引擎1826和评论引擎1828。另外，存储设备1830含有模板存储库1832和一系列实时管道模板1835。如所描述，LPT合成引擎通常可以允许开发者通过指定相对少量的程序源代码来构建实时管道模板1835，所述程序源代码指定了LPT模板的实例的服务特定数据。实时管道模板1835的其余部分封装最佳实践来对对应于实时管道模板的服务的类型的实例进行配置、部署和维护。在开发者指定实例特定细节之后，LPT实例的所得的源代码可以被编译和运行来构建应用定义，所述应用定义描述对由LPT合成引擎1824构建的部署管道的全面指定的配置。例如，如所描述，LPT合成引擎1824可以包括一组LPT合成驱动器，所述LPT合成驱动器各自读取应用定义的相关部段并且配置叶系统中的对应的叶系统。

在另一方向上，LPT分析引擎1826可以检查使用中的部署管道的配置并且生成表示无论什么配置状态都能被部署配置察觉的“基准”应用定义。在生成之后，评论引擎1828可以使用一组规则来评估“基准”应用定义，所述规则用于识别部署管道应该遵循的最佳实践或操作需求。

规则可适用于企业范围、服务类型特定的或以其他方式进行选择以适合具体情况的需要。此外，评论引擎1828可以将“基准”应用定义与模板库1832中的实时管道模板1835进行比较。如此行为可以为“基准”应用定义的建议的改变提供来源，用于防止持续部署管道中使用的叶系统被开发者直接修改，并且建议实时管道模板1835中可以用于使用于管理生产服务的部署管道处于实时管道模板的源代码控制之下的一个。

在前文中，对本公开中呈现的实施方案进行了参考。然而，本公开的范围不限于具体描述的实施方案。相反，无论是否涉及不同实施方案，以下特征和元素的任何组合都可预期用来实施和实践预期的实施方案。另外，虽然本文公开的实施方案可以实现优于其他可行解决方案或优于现有技术的优点，但是给定实施方案是否会实现特定优点都不会对本公开的范围进行限制。因此，以下方面、特征、实施方案和优点仅仅是说明性的，并且除非在权利要求中明确说明，否则它们不应被视作是随附权利要求的元素或限制。类似地，对“本发明”的提及不应被解释为对本文公开的任何发明主题的概括，并且除非在权利要求中明确说明，否则它不应被视作是随附权利要求的元素或限制。

本发明的各方面可以呈现纯硬件实施方案(包括固件、常驻软件、微代码等)或结合了在本文中通常可以全部称为“电路”、“模块”或“系统”的软件和硬件方面的实施方案的形式。另外，本发明的各方面可以呈现计算机程序产品的形式，所述计算机程序产品体现于上面体现了计算机可读程序代码的一个或多个计算机可读介质中。

可以利用一个或多个计算机可读介质的任何组合。计算机可读介质可以是计算机可读信号介质或计算机可读存储介质。计算机可读存储介质可以是例如但不限于：电子、磁、光、电磁、红外或半导体系统、设备或装置，或者以上各项的任何合适的组合。计算机可读存储介质的更具体的示例包括：具有一条或多条金属线的电子连接、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便携式压缩盘只读存储器(CD-ROM)、光存储装置、磁存储装置或以上各项的任何合适的组合。在当前上下文中，计算机可读存储介质可以是可以含有或存储程序的任何有形介质。

根据下列条款可以更好理解前述内容：

1. 一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令当在处理器上执行时执行操作来供应部署管道，所述操作包括：

接收对实时管道模板(LPT)的实例的定义，其中所述LPT的所述实例使用至少第一基本管道模板和第二管道模板来指定，其中所述第一基本管道模板对所述部署管道的一个或多个部署阶段指定一组配置参数，并且其中所述第二管道模板用所述部署管道的一个或多个实例特定参数对所述第一基本管道模板进行扩展；

从所述LPT的所述实例生成应用定义，所述应用定义提供对包括在所述部署管道中的多个计算服务的全面指定的配置；以及

通过以下方式在至少第一云计算区域中启动所述部署管道的第一实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述第一云计算区域中的所述计算服务中的一个。

2. 如条款1所述的计算机可读存储介质，其中第二管道模板的一个或多个实例特定参数包括以下至少一者：包括在部署管道中的计算服务中的一个的服务名称、管理者、运行时用户名。

3. 如条款1所述的计算机可读存储介质，其中管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

4. 如条款1所述的计算机可读存储介质，其中应用定义根据结构化交换格式来格式化。

5. 如条款1所述的计算机可读存储介质，通过以下方式在至少第二云计算区域中启动部署管道的至少第二实例：针对应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在应用定义中的全面指定的配置来配置第二云计算区域中的计算服务中的一个。

6. 如条款1所述的计算机可读存储介质，其中第一基本管道模板对至少第三管道模板进行扩展。

7. 一种系统，所述系统包括：

处理器；以及

存储器，所述存储器存储一个或多个应用，所述一个或多个应用当在所述处理器上执行时执行操作来生成对所述部署管道建模的应用定义，所述部署管道用于部署生产计算服务的变化，所述操作包括：

识别实时管道模板(LPT)的实例，其中所述LPT的所述实例用所述部署管道的实例特定参数使一个或多个基本管道模板专门化，

从所述LPT的所述实例构建应用目标，以及

调用所述应用目标来生成所述应用定义，其中所述应用定义提供对包括在所述部署管道中的多个计算服务中的每一个的全面指定的配置。

8. 如条款7所述的系统，其中所述操作还包括：

通过以下方式在至少第一云计算区域中启动所述部署管道的实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述第一云计算区域中的所述计算服务中的一个。

9. 如条款8所述的系统，其中管道合成驱动器以确定为满足管道合成驱动器之间的一种或多种服务依赖性的次序调用。

10. 如条款8所述的系统，其中第一云计算区域至少部分基于用于使一个或多个基本管道模板专门化的实例特定参数而选择。

11. 如条款7所述的系统，其中基本管道模板中的至少第一基本管道模板对部署管道的一个或多个部署阶段中的每一个指定配置参数。

12. 如条款7所述的系统，其中基本管道模板中的第二基本管道模板对基本管道模板中的至少第一基本管道模板进行扩展，并且其中第二基本管道模板指定对部署管道的与生产服务类型相关联的需求。

13. 如条款7所述的系统，其中实例特定参数包括以下至少一者：包括在部署管道中的计算服务中的一个的服务名称、管理者、运行时用户名。

14. 如条款7所述的系统，其中管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份访问和管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

15. 如条款7所述的系统，其中应用定义根据结构化交换格式来格式化。

16. 一种供应部署管道的由计算机实施的方法，所述方法包括：

确定可获得由对所述部署管道建模的应用定义引用的多个计算服务来托管所述部署管道的实例，其中所述应用定义从实时管道模板(LPT)的实例生成，所述实例用所述部署管道的实例特定参数使一个或多个基本管道模板专门化，并且其中所述应用定义提供对所述应用定义中引用的所述多个计算服务中的每一个的全面指定的配置；以及

通过以下方式启动所述部署管道的所述实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述计算服务中的一个。

17. 如条款16所述的方法，其中实例特定参数包括以下至少一者：包括在部署管道中的计算服务中的一个的服务名称、管理者、运行时用户名。

18. 如条款16所述的方法，其中管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

19. 如条款16所述的方法，其中部署管道的实例是用于部署生产计算服务的变化的持续部署管道。

20. 如条款16所述的方法，其中应用定义根据结构化交换格式来格式化。

还有以下条款：

1. 一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令当在处理器上执行时执行操作来维护部署管道，所述操作包括：

检测包括在实时管道模板(LPT)的实例的源代码中的多个管道模板中的一个的变化，其中管道模板中的至少第一管道模板用部署管道的实例特定参数使管道模板中的至少第二管道模板专门化，并且其中第二管道模板对部署管道的一个或多个部署阶段中的每一个指定配置参数；

从LPT的变化的实例生成应用定义，所述应用定义提供对包括在部署管道中的多个计算服务的全面指定的配置；以及

针对应用定义中引用的计算服务中的一个或多个调用相应的管道合成驱动器以根据提供在应用定义中的全面指定的配置来修改第一云计算区域中的计算服务中的对应的计算服务。

2. 如条款1所述的计算机可读存储介质，其中所述操作还包括：

识别包括在部署管道中的多个计算服务中的每一个的当前配置；

确定包括在部署管道中的一个或多个计算服务中的哪些具有的当前配置不同于提供在应用定义中的全面指定的配置；以及

其中调用相应的管道合成驱动器来配置第一云计算区域中的计算服务中的一个包括调用对应于计算服务中的所确定的一个或多个的相应的管道合成驱动器。

3. 如条款1所述的计算机可读存储介质，其中所述操作还包括：

针对应用定义中引用的计算服务中的一个或多个调用相应的管道合成驱动器以根据提供在应用定义中的全面指定的配置来配置第二云计算区域中的计算服务中的一个。

4. 如条款1所述的计算机可读存储介质，其中实例特定参数包括以下至少一者：包括在部署管道中的计算服务中的一个的服务名称、管理者、运行时用户名。

5. 如条款1所述的计算机可读存储介质，其中管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

6. 如条款1所述的计算机可读存储介质，其中部署管道是用于部署生产计算服务中的一个或多个应用的变化的持续部署管道。

7. 一种系统，所述系统包括：

处理器；以及

存储器，所述存储器存储一个或多个应用，所述一个或多个应用当在处理器上执行时执行操作来管理用于部署生产计算服务的变化的部署管道，所述操作包括：

通过以下方式配置部署管道：针对于对部署管道建模的应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在应用定义中的全面指定的配置来配置计算服务中的对应的计算服务，以及

启动元管道，所述元管道用于至少部分基于实时管道模板(LPT)的实例的检测到的变化而将更新传播到部署管道，其中LPT的实例用部署管道的实例特定参数使一个或多个基本管道模板专门化，并且其中应用定义从LPT实例生成。

8. 如条款7所述的系统，其中基本管道模板的第一基本管道模板对部署管道的一个或多个部署阶段指定一组配置参数。

9. 如条款8所述的系统，其中第二基本管道模板对至少第一基本管道模板进行扩展，并且其中第二基本管道模板指定对部署管道的与由第二基本管道模板指定的生产服务类型相关联的需求。

10. 如条款7所述的系统，其中元管道通过以下方式来更新部署管道：

检测LPT的实例的变化；

从LPT的变化的实例生成更新的应用定义；以及

通过以下方式更新部署管道：针对更新的应用定义中引用的计算服务中的一个或多个调用管道合成驱动器中的相应的管道合成驱动器以根据更新的应用定义来配置第一云计算区域中的计算服务中的对应的计算服务。

11. 如条款10所述的系统，其中管道合成驱动器以确定为满足管道合成驱动器之间的一种或多种服务依赖性的次序调用。

12. 如条款10所述的系统，其中检测LPT的实例的变化包括监测版本控制系统中提交到版本控制系统的LPT的实例的更新版本。

13. 如条款7所述的系统，其中实例特定参数包括以下至少一者：包括在部署管道中的计算服务中的一个的服务名称、管理者、运行时用户名。

14. 如条款7所述的系统，其中管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

15. 如条款7所述的系统，其中应用定义根据结构化交换格式来格式化。

16. 一种更新部署管道的由计算机实施的方法，所述部署管道用于部署生产计算服务的变化，所述方法包括：

检测提交到版本控制系统的实时管道模板(LPT)的实例的源代码的变化；

从LPT的实例的变化的源代码生成应用定义，所述应用定义提供对包括在部署管道中的多个计算服务的全面指定的配置；以及

针对应用定义中引用的计算服务中的一个或多个调用相应的管道合成驱动器以便于重新配置计算服务中的对应的计算服务以符合提供在应用定义中的全面指定的配置。

17. 如条款16所述的方法，其中管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

18. 如条款16所述的方法，其中部署管道是用于传播生产计算服务的变化的持续部署管道。

19. 如条款16所述的方法，其中LPT的实例的源代码包括至少第一管道模板，其中第一管道模板对部署管道的一个或多个部署阶段指定一组配置参数。

20. 如条款19所述的方法，其中LPT的实例的源代码还包括至少第二管道模板，并且其中第二管道模板用部署管道的多个实例特定参数对第一管道模板的源代码进行扩展。

还有以下条款：

1. 一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令当在处理器上执行时执行操作来评估部署管道，所述操作包括：

在部署到至少第一云计算区域时，生成应用定义来反映部署管道的当前操作状态，其中应用定义通过调用多个分析驱动器来生成，并且其中每个分析驱动器检查包括在部署管道中的相应的计算服务的配置；

使用一组一条或多条规则来评估应用定义，其中每条规则指定包括在部署管道中的计算服务中的一个或多个的配置的一个或多个条件；以及

生成报告，所述报告指示部署管道的当前操作状态满足一条或多条规则中的哪些并且部署管道的当前操作状态不满足一条或多条规则中的哪些。

2. 如条款1所述的计算机可读存储介质，其中所述操作还包括：

对于部署管道的当前操作状态不满足的规则中的至少第一规则，生成包括在部署管道中的计算服务中的一个或多个的满足第一规则所需的建议的修改。

3. 如条款2所述的计算机可读存储介质，其中所述操作还包括：

传播计算服务中的一个或多个的建议的修改。

4. 如条款1所述的计算机可读存储介质，其中分析驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

5. 如条款1所述的计算机可读存储介质，其中应用定义根据结构化交换格式来格式化。

6. 如条款1所述的计算机可读存储介质，其中部署管道是用于部署托管在第一云计算区域中的生产计算服务中的一个或多个应用的变化的持续部署管道。

7. 一种系统，所述系统包括：

处理器；以及

存储器，所述存储器存储一个或多个应用，所述一个或多个应用当在处理器上执行时执行操作来确定部署管道的当前配置状态，所述部署管道用于传播生产计算服务的更新，所述操作包括：

识别包括在部署管道中的多个计算服务，

针对每个识别的计算服务：

确定包括在部署管道中的计算服务中的相应的计算服务的当前配置状态；以及

生成对计算服务的当前配置状态的描述，以及

从所生成的描述生成第一应用定义，其中第一应用定义提供对部署管道的当前操作状态的全面指定的配置。

8. 如条款7所述的系统，其中确定包括在部署管道中的相应的计算服务的当前配置状态包括调用对应于相应的计算服务的管道分析驱动器，并且其中管道分析驱动器通过进行一个或多个API调用来检查相应的计算服务以确定相应的计算服务的当前配置状态。

9. 如条款8所述的系统，其中管道分析驱动器包括以下一者或多者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理(IAM)驱动器、性能监控器驱动器以及警报驱动器。

10. 如条款7所述的系统，其中所述操作还包括：

确定第一应用定义不满足至少第一规则，所述第一规则指定对部署管道的当前配置状态的需求。

11. 如条款10所述的系统，其中所述操作还包括：

确定应用于包括在部署管道中的计算服务中的至少第一计算服务的满足第一规则所需的修改。

12. 如条款11所述的系统，其中所述操作还包括：

调用至少第一合成驱动器来重新配置第一计算服务以符合提供在应用定义中对部署管道的全面指定的配置。

13. 如条款7所述的系统，其中所述操作还包括：

从第一应用定义确定与使用部署管道部署的生产计算服务相关联的服务类型；以及

基于至少所确定的服务类型而确定与部署管道相关联的实时管道模板，其中实时管道模板包括一个或多个基本管道模板的源代码。

14. 如条款13所述的系统，其中一个或多个基本管道模板包括第一基本管道模板的源代码，所述第一基本管道模板对部署管道的一个或多个部署阶段指定一组配置参数。

15. 如条款14所述的系统，其中一个或多个基本管道模板包括第二基本管道模板的源代码，所述第二基本管道模板对第一基本管道进行扩展，并且其中第二基本管道模板对部署管道指定多个服务类型参数。

16. 如条款14所述的系统，其中所述操作还包括：

接收指定实例特定参数的源代码，所述实例特定参数用于将实时管道模板专门化为实时管道模板(LPT)实例。

17. 如条款16所述的系统，其中部署管道的变化通过向版本控制系统提交第一基本管道模板、第二基本管道模板的源代码、或LPT实例的实例特定参数来进行。

18. 一种评估部署管道的由计算机实施的方法，所述方法包括：

通过调用多个分析驱动器来生成第一应用定义，其中多个分析驱动器中的每一个检查包括在部署管道中的相应的计算服务的配置，其中第一应用定义反映部署管道的当前配置状态；

接收对应于实时管道模板的源代码；

从实时管道模板生成第二应用定义，其中第二应用定义描述对用于提供第二部署管道的多个计算服务的全面指定的配置；以及

确定介于第一应用定义与第二应用定义之间的一组差异；以及

生成描述该组确定的差异的报告。

19. 如条款18所述的方法，其中对应于实时管道的源代码包括一个或多个基本管道模板。

20. 如条款18所述的方法，其中一个或多个基本管道模板包括第一基本管道模板，所述第一基本管道模板对部署管道的一个或多个部署阶段指定一组配置参数；以及第二管道模板，所述第二管道模板用与所确定的服务类型相关联的多个实例特定参数对第一基本管道模板进行扩展。

连同以下条款：

1. 一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令当在处理器上执行时执行操作来使部署管道的配置状态处于实时管道模板控制之下，所述操作包括：

通过调用多个分析驱动器来生成第一应用定义，其中多个分析驱动器中的每一个检查包括在部署在至少第一云计算区域中的第一部署管道中的相应的计算服务的配置，其中第一应用定义反映第一部署管道的当前配置状态；

生成一个或多个第二应用定义，其中每个第二应用定义从定义实时管道模板的源代码生成，并且其中每个第二应用定义反映部署管道的潜在配置状态；

将第一应用定义中反映的当前配置状态与一个或多个第二应用定义中反映的潜在配置进行比较；

至少基于比较而确定第二应用定义中的一个反映部署管道的与第一部署管道配合的潜在部署配置；以及

重新配置第一部署管道以反映如由所确定的第二应用定义所指定的潜在部署配置。

2. 如条款1所述的计算机可读存储介质，其中定义实时管道模板中的至少第一实时管道模板的源代码包括一个或多个基本管道模板。

3. 如条款1所述的计算机可读存储介质，其中一个或多个基本管道模板包括第一基本管道模板，所述第一基本管道模板对部署管道的一个或多个部署阶段指定一组配置参数。

4. 如条款1所述的计算机可读存储介质，其中部署管道是用于部署托管在第一云计算区域中的生产计算服务中的一个或多个应用的变化的持续部署管道。

5. 如条款1所述的计算机可读存储介质，其中所述操作还包括：

接收指定一组实例特定参数的源代码，所述实例特定参数用于将对应于所确定的应用定义的实时管道模板专门化。

6. 如条款5所述的计算机可读存储介质，其中所述操作还包括：

通过以下方式在至少第二计算区域中启动部署管道的实例：针对所确定的第二应用定义中引用的多个计算服务中的每一个调用相应的管道合成驱动器来配置第二云计算区域中的计算服务中的对应的计算服务。

7. 如条款1所述的计算机可读存储介质，其中第一应用定义和第二应用定义各自根据公共交换格式来格式化。

8. 一种系统，所述系统包括：

处理器；以及

存储器，所述存储器存储一个或多个应用，所述一个或多个应用当在处理器上执行时执行操作来监控部署管道的配置状态，所述操作包括：

识别对至少部分用于提供部署管道的至少第一计算服务的配置作出的改变，

从与部署管道相关联的实时管道模板(LPT)的实例生成应用定义，其中应用定义提供对包括在部署管道中的包括第一计算服务的多个计算服务的全面指定的配置，

将第一计算服务的配置的识别的改变与在应用定义中对第一计算服务指定的配置进行比较，以及

生成报告，所述报告描述介于第一计算服务的改变的配置与在应用定义中指定的第一计算服务的配置状态之间的差异。

9. 如条款8所述的系统，其中报告识别对部署管道或使用从所识别的改变获得的部署管道更新的生产计算服务的风险的度量。

10. 如条款9所述的系统，其中报告识别对部署管道的改变的配置的修改以降低风险度量。

11. 如条款8所述的系统，其中LPT的实例用部署管道的实例特定参数使一个或多个基本管道模板专门化，并且其中应用定义从LPT实例生成。

12. 如条款8所述的系统，其中基本管道模板中的第二基本管道模板对基本管道模板中的至少第一基本管道模板进行扩展。

13. 如条款12所述的系统，其中第一基本管道模板对部署管道的一个或多个部署阶段指定一组配置参数，并且其中第二基本管道模板指定对部署管道的与生产服务类型相关联的需求。

14. 如条款8所述的系统，其中部署管道是用于传播托管在第一云计算区域中的生产计算服务中的一个或多个应用的更新的持续部署管道。

15. 如条款8所述的系统，其中将第一计算服务的配置的识别的改变与在应用定义中指定的对第一计算服务的配置进行比较包括：

确定第一计算服务的当前配置状态；以及

生成对第一计算服务的当前配置状态的描述，其中应用定义和所生成的描述各自根据公共交换格式来格式化。

16. 一种维护部署管道的由计算机实施的方法，所述部署管道使用实时管道模板(LPT)的实例来供应，所述方法包括：

检测对用于提供部署管道的至少第一计算服务作出的改变，

从与部署管道相关联的LPT的实例生成第一应用定义，其中第一应用定义提供对包括在部署管道中的包括第一计算服务的多个计算服务的全面指定的配置；以及

针对至少第一计算服务调用对应的管道合成驱动器，其中管道合成驱动器根据提供在第一应用定义中的全面指定的配置来重新配置第一计算服务。

17. 如条款16所述的由计算机实施的方法，其中检测对用于提供部署管道的至少第一计算服务作出的改变包括：

通过调用多个分析驱动器来生成第二应用定义，其中多个分析驱动器中的每一个检查包括在部署管道中的计算服务中的相应的计算服务的配置；以及

将第一应用定义与第二应用定义进行比较以检测对第一计算服务作出的改变。

18. 如条款16所述的由计算机实施的方法，其中LPT的实例包括至少第一基本管道模板的源代码，所述源代码指定部署管道的一个或多个部署阶段的一组配置参数；源代码，所述源代码指定部署管道的一组实例特定参数。

19. 如条款16所述的由计算机实施的方法，其中部署管道是用于部署使用部署管道部署的生产计算服务中的一个或多个应用的变化的持续部署管道。

20. 如条款16所述的由计算机实施的方法，所述方法还包括：在调用用于重新配置第一计算服务的对应的管道合成驱动器之前，接收对实行在实时管道模板的实例中指定的部署管道的配置的确认。

虽然前文是针对本发明的实施方案，但是在不脱离其基本范围的情况下可以想出本发明的其他和另外的实施方案，并且本发明的范围由以上权利要求书确定。

Claims (18)

1.一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令当在处理器上执行时执行操作来供应部署管道，所述操作包括：

接收对实时管道模板的实例的定义，其中所述实时管道模板的所述实例使用至少第一基本管道模板和第二管道模板来指定，其中所述第一基本管道模板对所述部署管道的多个部署阶段指定一组配置参数，并且其中所述第二管道模板用所述部署管道的一个或多个实例特定参数对所述第一基本管道模板进行扩展；

从所述实时管道模板的所述实例生成应用定义，所述应用定义提供对包括在所述部署管道中的多个计算服务的全面指定的配置；

通过以下方式在至少第一云计算区域中启动所述部署管道的第一实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述第一云计算区域中的所述多个计算服务中的一个；以及

通过以下方式在至少第二云计算区域中启动所述部署管道的至少第二实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述第二云计算区域中的所述多个计算服务中的一个。

2.如权利要求1所述的计算机可读存储介质，其中所述第二管道模板的所述一个或多个实例特定参数包括以下至少一者：包括在所述部署管道中的所述多个计算服务中的一个的服务名称、管理者、运行时用户名。

3.如权利要求1所述的计算机可读存储介质，其中所述管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理驱动器、性能监控器驱动器以及警报驱动器。

4.如权利要求1所述的计算机可读存储介质，其中所述应用定义根据结构化交换格式来格式化。

5.如权利要求1所述的计算机可读存储介质，其中所述第一基本管道模板对至少第三管道模板进行扩展。

6.一种用于供应部署管道的系统，所述系统包括：

处理器；以及

存储器，所述存储器存储一个或多个应用，所述一个或多个应用当在所述处理器上执行时执行操作来生成对部署管道建模的应用定义，所述部署管道用于部署生产计算服务的变化，所述操作包括：

识别实时管道模板的实例，其中所述实时管道模板的所述实例用所述部署管道的多个部署阶段的实例特定参数使一个或多个基本管道模板专门化，

从所述实时管道模板的所述实例构建应用目标，

调用所述应用目标来生成所述应用定义，其中所述应用定义提供对包括在所述部署管道中的多个计算服务中的每一个的全面指定的配置；以及

通过以下方式在第一和第二云计算区域中启动所述部署管道的相应的第一和第二实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述第一和第二云计算区域中的所述多个计算服务中的一个。

7.如权利要求6所述的系统，其中所述管道合成驱动器以确定为满足所述管道合成驱动器之间的一种或多种服务依赖性的次序调用。

8.如权利要求6所述的系统，其中所述第一云计算区域至少部分基于用于使所述一个或多个基本管道模板专门化的所述实例特定参数而选择。

9.如权利要求6所述的系统，其中所述基本管道模板中的至少第一基本管道模板对所述部署管道的多个部署阶段中的每一个指定配置参数。

10.如权利要求6所述的系统，其中所述基本管道模板中的第二基本管道模板对所述一个或多个基本管道模板中的至少第一基本管道模板进行扩展，并且其中所述第二基本管道模板指定对所述部署管道的与生产服务类型相关联的需求。

11.如权利要求6所述的系统，其中所述实例特定参数包括以下至少一者：包括在所述部署管道中的所述多个计算服务中的一个的服务名称、管理者、运行时用户名。

12.如权利要求6所述的系统，其中所述管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份访问和管理驱动器、性能监控器驱动器以及警报驱动器。

13.如权利要求6所述的系统，其中所述应用定义根据结构化交换格式来格式化。

14.一种供应部署管道的由计算机实施的方法，所述方法包括：

确定可获得由对所述部署管道建模的应用定义引用的多个计算服务来托管所述部署管道的第一实例，其中所述应用定义从实时管道模板的实例生成，所述实例用所述部署管道的多个部署阶段的实例特定参数使基本管道模板专门化，并且其中所述应用定义提供对所述应用定义中引用的所述多个计算服务中的每一个的全面指定的配置；以及

通过以下方式在第一云计算区域中启动所述部署管道的所述第一实例并且在第二云计算区域中启动所述部署管道的第二实例：针对所述应用定义中引用的每个计算服务调用相应的管道合成驱动器以根据提供在所述应用定义中的所述全面指定的配置来配置所述多个计算服务中的一个。

15.如权利要求14所述的方法，其中所述实例特定参数包括以下至少一者：包括在所述部署管道中的所述多个计算服务中的一个的服务名称、管理者、运行时用户名。

16.如权利要求14所述的方法，其中所述管道合成驱动器包括以下至少一者：管道驱动器、部署驱动器、主机驱动器、网络驱动器、安全驱动器、身份和访问管理驱动器、性能监控器驱动器以及警报驱动器。

17.如权利要求14所述的方法，其中所述部署管道的所述实例是用于部署生产计算服务的变化的持续部署管道。

18.如权利要求14所述的方法，其中所述应用定义根据结构化交换格式来格式化。

Images