CN104246697A - 针对应用的版本管理 - Google Patents

Abstract

一种系统（100）包括应用模型（140）以表征用于部署在云（130）上的给定应用（110）。部署管理器（120）基于与所述给定应用（110）相关联的所述应用模型（140）和策略（150）来分析对于所述给定应用（110）的应用要求以和在所述云（130）中用来实现所述应用要求的基础设施资源（160）基本上匹配。版本控制管理器（164）在所述给定应用（110）的服务生命周期期间跟踪所述给定应用（110）中的改变并且依照所述改变来更新所述应用模型（140）或所述策略（150）。

Description

针对应用的版本管理

背景技术

云计算指的是可伸缩的和合并的计算、存储以及联网能力作为服务到终端接收者的网络的递送。名称来自云作为网络的复杂基础设施和可在云内操作的关联硬件的抽象的使用。例如，云计算通过网络为用户的数据、软件以及计算提供服务。这样的计算能力依靠资源的共享来通过网络（通常为因特网）实现规模与公用设施（例如电网）类似的相干性和经济。部署在支持云的资源上的应用目前常常不得不被手动地部署并且那消耗相当多的管理时间。部署应用的手动步骤包括基础设施的提供和安装。这需要从应用的安装或映像的部署链接到所部署的基础设施的完备知识。手动部署通常需要由试图部署应用的用户所通常启动的步骤的许多序列。

附图说明

图1图示了为云应用提供自动化版本控制、测试、管理以及部署的系统的示例。

图2图示了用于应用在云环境中的自动化测试、版本控制以及部署的测试管理器接口的示例。

图3图示了用于应用的自动化版本控制、部署以及监视的示例系统。

图4图示了对于应用的部署、版本控制、测试以及监视利用闭环反馈的示例系统。

图5图示了用于应用的自动化部署和版本控制的示例方法的流程图。

图6图示了用于云应用的自动化部署和版本控制的示例部署系统。

图7图示了使云的资源能力与应用的应用要求相匹配的部署管理器的示例。

具体实施方式

图1图示了促进云应用的自动化测试、管理、版本控制以及部署的系统100的示例。系统100能够通过利用部署管理器120以确定云基础设施130（也被称为云130）的基础设施能力并且同样通过使应用模型140和策略150与云基础设施资源相匹配而确定应用110的应用要求来提供应用110的自动化部署和生命周期管理。在这样的确定之后，部署管理器120能够自动地管理应用110在云130上的生命周期，其中匹配被识别（例如，理想的或尽力而为 - 最接近匹配）。基于匹配接近的量度和/或其他策略要求，匹配被选择并且能够提供/实例化基础设施。

根据云基础设施资源与应用要求的这样的匹配（例如，绝对匹配或最接近匹配），然后应用110的组件能够被部署在云130上。云130的基础设施能力能够经由与云相关联的资源供应或元数据160而被确定。例如，支持云130的多个服务提供商能够提供规定他们有什么类型的资源的文件和描述相应资源供应（例如，可用的三个服务器的资源供应，其中元数据规定存储器大小或处理器速度、负荷（如果已经实例化）、位置、租赁条款、服务级别协定（SLA）、调度维护等等）的感兴趣属性。

版本控制管理器164能够被编程为在给定应用的服务生命周期期间跟踪应用中的改变（例如，以检测版本改变），并且基于所检测到的改变，更新对于将应用部署在云中的应用要求。例如，版本控制管理器能够依照改变针对给定应用来更新应用模型140和/或策略150。可替换地，还能够手动地或者经由人们或系统能够实现的工具/逻辑过程执行模型和/或策略的这样的更新。一般而言，应用110常常通过许多版本、部署选项、修订版等等迁移。因此，应用、平台、服务以及策略全部形成服务生命周期的一部分。这个服务生命周期能够随着组成服务的每个工件的版本随着时间的推移而改变。版本控制管理器164促进了组件和应用110的组件之间的依赖性在服务生命周期过程中以切实可行的方式部署在云中。

除跟踪改变之外，版本控制管理器164能够对给定应用110的组件和工件之间的依赖关系进行建模，所述依赖关系然后能够基于检测到给定应用中的改变在应用模型140或策略150中被更新。例如，这样的依赖关系能够被建模为树、层级、数据库结构或其他形式。因此，当对应用110执行升级或其他改变时，版本控制管理器164跟踪应用的所有版本在服务生命周期过程中的改变。在另一示例中，应用版本的实时处理能够通过在需要时允许较旧的版本的实例化来促进与客户端的后向兼容性/与较旧的系统的交互/集成。例如，如果应用的较新的版本正被测试然而较新的版本的组件中的一个仅与较旧的测试或其他组件兼容，则能够实时地实例化较老的版本以支持较新的版本。

版本控制管理器164还能够随着版本的监视/跟踪并且随着组件鉴于这样的监视/跟踪在这样的阶段期间的实例化而被用于开发、生产和/或运营的各种阶段。这能够在跟踪分阶段版本中的改变并且鉴于这样的监视而发起自动化部署的同时包括阶段的监视和所部署的实例的经由闭环反馈的监视。经由更新的应用模型和策略的版本控制能够被应用于各种阶段以例如确保生产实例的相关应用版本的适当升级（例如，通过部署具有正确依赖性的新的版本和/或在需要时维护过去的版本以支持与旧客户端或其他应用的集成）。

能够提供测试管理器170，所述测试管理器170基于检测到给定应用中的改变（例如，由版本控制管理器164所检测到的）来启动对给定应用110的测试。附加地或可替换地，能够基于检测到对给定应用的组件和工件之间的依赖关系的改变而启动测试。测试管理器170能够根据在给定应用110中所检测到的改变经由部署管理器120从第一测试环境向第二测试环境重演（restage）对给定应用的测试。测试管理器170还能够基于检测到对给定应用的组件和工件之间的依赖关系的改变而实现这样的重演，其中依赖关系能够由版本控制管理器164确定。

测试模型能够由测试管理器170生成，所述测试模型描述了用于基于检测到改变在给定应用中被检测到而测试给定应用110的过程（例如，考虑到所检测到的改变最佳推荐的测试）。附加地或可替换地，能够生成测试模型以用于基于检测到对给定应用的组件和工件之间的依赖关系的改变而测试给定应用。测试管理器170能够使部署管理器120从给定应用110更新其他组件（例如，与应用一起操作的操作系统、模块、接口、例行程序）以便于基于这样的测试的结果来修复给定应用或其他组件中的检测到的问题。能够更新应用模型110和/或策略以反映对于所检测到的问题的测试要求，其进一步能够被版本控制管理器跟踪。

可移植性管理器174能够被提供来使部署管理器120基于检测到给定应用中的改变来部署与给定应用兼容的其他应用的版本。附加地或可替换地，能够命令部署管理器120基于检测到对给定应用的组件和工件之间的依赖关系的改变来部署其他应用的这样的版本。例如，基于由版本控制管理器164在应用110中检测到改变，可以安装操作系统或其他组件的不同版本以与应用110的特定版本一起操作（例如，安装要与应用的版本5兼容的操作系统的版本2）。在测试场景下，可以附加地安装（或者去除）多个不同的组件以促进应用110的测试（例如，安装要与由应用110所表示的客户端侧应用的当前版本兼容的服务器侧应用的多个版本）。

可移植性管理器174还能够使其他应用（待与应用110一起测试）作为更高或更低修订版被安装以便于与给定应用110兼容。可移植性管理器174还能够使部署管理器120基于（例如，由版本控制管理器164）在给定应用110中检测到的改变来执行应用实例的滚动升级。可移植性管理器还能够命令部署管理器基于检测到对给定应用的组件和工件之间的依赖关系的改变来执行这样的滚动的升级。在另一示例中，版本控制管理器164能够维护描述给定应用的版本、针对给定应用的部署配置或针对给定应用的测试推荐的模板。这样的模板还能够作为应用模型140和/或策略150的一部分被存储。

测试管理器170能够经由部署管理器120针对给定应用110来配置和启动应用部署的测试套件。测试管理器170能够为应用110配置多个不同的操作部署场景。能够跨越组织边界管理配置和结果的应用部署以适合各种组织需要。例如，部署可以具有一组需要并且生产可以具有单独的一组需要。在一些情况下，针对应用的公用部署被配置和启动，并且在其他情况下，诸如经由本地测试和储存器180所示出的专用部署被启动。在其他情况下，公用部署和专用部署的组合像由测试管理器170所配置的那样被启动并且经由部署管理器120部署。

例如，基于确定最佳匹配基础设施资源，测试管理器170使得能实现自动化部署测试、针对运营的开发以及应用安全部署。例如，这样的匹配能够包括使应用模型140和策略150与如由资源供应和关联的元数据160所规定的基础设施模型相匹配。然后能够选择和采用匹配基础设施来在也运行各种测试套件的同时并且在测试的不同阶段处测试或者促进生产。对于开发测试，测试管理器170允许开发者遵循在云130中具有测试的任何软件的开发，其中它们能够在多个部署场景中部署和运行软件并且在没有常见延迟和成本的情况下执行目标测试用例以建立部署和测试。在软件元件（例如，应用组件）的开发和测试之后，然后能够在生产中部署和操作它们。这使得能够测试应用110的安全方面，因为安全能够在安全的部署和生产环境中（诸如在本地测试和储存器180上）测试。漏洞、安全攻破以及其他检测到的事件的反馈能够被容易地监视并且反馈（例如，经由监视器组件和监听器）给开发代理诸如以用于诊断和修复。

测试管理器170和部署管理器120能够被采用来针对测试套件在由部署管理器120所提供和部署的部署上的配置和启动依照用户接口（UI）（例如，见图2）使测试自动化。这能够包括提供能够基于监视到编码器储存库中的改变而自动化的自动化应用编程接口（API）以及在由部署管理器120所提供和部署的部署上启动/运行测试套件。部署管理器120能够被用来从测试向生产移动，这能够由在位置（在生产区中）方面的策略改变和关于容量、延迟、服务质量（QoS）等等的其他生产准则发起。由测试管理器170所支持的其他测试场景能够包括能够通过基础设施的配置的监视和闭环反馈所支持的安全开发、运营开发以及质量保证。针对给定应用的这样的开发测试的结果能够被部署管理器120利用以用于针对给定应用的部署和生命周期管理。应用组件（例如，与它们被开发和存储在储存库中的现有应用集成在一起）的连续集成能够随着它们基于部署管理器120被开发而被支持。还能够基于部署管理器120的自动化动作来支持软件的连续递送。

测试管理器170提供用于完全在单个工作流内在应用团队内和跨越应用团队并且贯穿开发应用的完整过程进行管理和自动化的集中式应用管理平台。测试管理器170能够支持负责随着应用通过它们的生命周期进步而递送应用的利益相关者。它集中于从设计至准备就绪以用于递送给运营的核心生命周期。这能够包括要求管理、测试规划与功能测试、性能测试、开发者管理以及缺陷管理。这样的应用生命周期活动能够从工作流观点与公共管理控制台、项目跟踪和规划的层连接在一起，并且在包含具有支持的软件开发工具包（SDK）的一致储存库和开放式集成架构的公用软件基础上构建。

如将在下面关于图2所描述的那样，测试管理器170能够被编程为支持各种功能。这能够包括诸如具有用于加速安全且可靠的应用的递送的统一软件平台的应用生命周期管理（ALM）之类的功能。这包括为开发者、测试者以及商业分析递送应用之间的协作提供框架的开发管理功能。测试管理器170还能够使得能够针对相应的应用定义、管理并且跟踪软件要求。例如，这能够包括提供可重复的、可伸缩的、可自动化的功能以管理技术策略和可重用服务。能够经由接口组件支持合成应用以跨越生命周期管理高质量、可靠的且安全的合成应用。应用生命周期管理包括对于软件即服务（SaaS）的支持。对于应用和部署还能够支持质量管理功能。这包括性能验证，其中一组功能被提供来在基于项目的场景以及其他开发模式下测试应用性能。模块化测试工具也被提供用于为应用迅速地开发自动化功能测试套件。

使用测试管理器170，规定的应用要求指导应用的开发。应用开发者和所规定的要求能够被存储在存储器中以指导测试用例和测试套件的建立。例如，能够在配置、部署以及使用场景方面定义开发者和要求。不同的测试用例和场景能够作为应用模型140和策略150被捕获。代表性部署能够作为基础设施模板被捕获。能够一键完成（例如，经由指向模板、模型、策略、工件并且执行代码的web站点）在目标配置中自动地运行测试套件。周期性地或在改变已随着应用发生了之后，这样的改变能够经由测试管理器170（诸如调用API来传递新的工件并且运行测试）而自动化。安全测试还可以在开发的各种步骤处测试或者使得能实现安全挑战。能够通过改变策略以随着选择的或确定的部署迁移到生产环境来使得能实现开发运营。

可移植性管理器174能够被编程为规定可移植性指令，所述可移植性指令能够更新用于将给定应用110部署在云130上的策略150和/或应用模型140。在一个示例中，可移植性指令更新策略150和/或应用模块140以规定部署管理器120的部署。在另一示例中，例如，可以诸如通过能够由应用编程接口（API）所提供的命令将可移植性指令直接地（而不用更新策略或应用模型）供应给部署管理器120。可移植性管理器174能够被实现为包括应用编程接口（API）或图形用户接口（GUI），例如，以接收部署请求。部署管理器120能够基于如由可移植性管理器174所修改的策略150和应用模型140来修改给定应用110的部署。应用模型140能够被采用来诸如通过用于应用的各种组件的元数据描述来表征用于部署在云基础设施130上的给定应用110。

部署管理器120和可移植性管理器174能够经由存储在存储器中并且可由处理器执行的指令来实现以基于与给定应用相关联的应用模型140和策略150（或诸策略）来分析对于给定应用110的应用要求。如将在下面所描述的那样，策略150能够被提供来描述应用110的附加的操作上下文（例如，在午夜之后操作应用、使用仅东海岸服务器、维护服务器之间的负荷均衡等等）。部署管理器120然后能够确定在云基础设施中足以实现如由模型140和策略150所规定的应用110的应用要求的一组基础设施资源。部署管理器120还能够基于由可移植性管理器160向部署管理器120所发出的命令将部署从部署A改变为部署B。

系统100利用动态应用模型140的能力（例如，可在请求变更应用部署时改变）和还能够包括动态基础设施模板和动态绑定的策略150来跨越潜在异构的混合云130或资源池提供应用和工作负荷可移植性。还能够提供工作负荷管理（例如，基础设施资源的自动定标、按比例放大或缩小）。例如，基于云基础设施资源的加载，可以执行向外扩展/向内扩展操作或基于策略准则将应用移动到另一位置。应用模型140或策略150能够描述如何部署（或者拆除/取消部署）在针对给定应用的部署所利用的云基础设施的一部分中的应用。例如，应用模型140或策略150能够针对给定应用的部署或指令引退而从云基础设施130中识别基础设施资源和所需要的内容。可移植性管理器174能够针对应用110的部署并且基于请求170来改变策略160和/或应用模型140。即使云基于不同的API、网络资源等等，也能够在另一云配置上（例如，从A到B，或者反之亦然）实现部署中这样的改变以提供所期望的信息来在不同的配置上执行应用。用于跨越不同的部署移动应用110的示例原因举几个例子能够包括负荷均衡、从专用配置向公用配置移动或者反之亦然、增加或减少应用的资源以及跨越不同的基础设置资源将应用按比例放大或缩小。

将应用110从一个部署移动到另一部署能够包括经由部署管理器120将应用部署到不同的云配置（例如，或资源的池），其中策略150和/或应用模型140规定基础设施资源在不同云中的使用。在这样的示例中，能够经由可移植性管理器160来调整策略或应用模型以实现这样的改变。例如，如本文中所提到的那样，用于移动应用110的这样的规格和命令能够经由部署请求170发起，所述部署请求170能够包括经由API或GUI所接收到的请求。

作为另一个示例，应用110及其对应的当前部署能够由诸如能够被存储在储存库或数据库（未示出）中的实时服务模型（RTSM）识别。可移植性管理器174能够调用RTSM来识别用于所对应的当前部署的基础设施资源并且在已实现新的部署之后取消部署/指令引退应用和基础设施。例如，旧部署的这样的指令引退还能够由API请求或GUI请求发起。

例如，除将应用从一个部署移动到另一部署之外，可移植性管理器174和部署管理器120能够协作以管理云部署的其他相关方面，包括工作负荷管理、拷贝和指令引退给定应用。工作负荷管理能够包括用于给定应用的部署的所关联的基础设施资源的按比例放大或按比例缩小/工作负荷管理。工作负荷管理还能够由针对给定部署来调整工作负荷（例如，经由GUI请求或API请求）的请求产生。除工作负荷管理之外，部署（例如，应用组件的移动、拷贝、指令引退）能够被用于给定应用的生命周期管理。例如，与部署管理器120或可移植性管理器174分离的组件或系统能够在当前应用部署由于生命周期操作而从它们的初始部署改变的情况下对生命周期操作进行调度。例如，作为调度的生命周期操作的一部分，能够经由可移植性指令发起部署以移动、拷贝或者指令引退给定应用（或其关联的组件/工件）作为生命周期操作的一部分。附加地或可替换地，能够基于检测到事件（例如，经由反馈）触发生命周期操作。

能够在部署管理器120中提供附加的逻辑以处理从监视器接收到的事件（例如，见图4）。这样的监视逻辑因此能够检测事件的发生并且触发用于对应部署的资源参数的调整。作为结果并且去为了按比例放大，例如，针对给定应用110的云部署能够被移动到较少负荷的环境。应用110的新的实例能够被部署在云环境内的不同部署中。为了按比例缩小，能够取消部署/指令引退应用的旧实例，诸如可以经由上面所描述的RTSM来识别并且基于修改的应用模型140和策略150重新部署。策略150和/或应用模型140还能够请求改变或者重新配置业务实例并且对改变进行定标。如果需要（例如，由管理员期望/请求或作为监视的结果）工作负荷可移植性能够包括将完整的一组应用移动到新的云。

能够跨越可以全部为异构的基础设施、云或池提供应用可移植性。这能够包括基于一个或多个硬件（HW）和/或软件（SW）配置的实施方式。还能够在一个或多个HW/W配置上识别系统100中的模块。还能够为软件即服务（SaaS）和关于在HW和/或SW上和在云130上的虚拟化版本提供支持。

在已基于匹配部署了应用之后，部署管理器120进一步能够管理应用的生命周期的其他方面。例如，部署管理器120能够监视反馈，并且基于这样的反馈来调整基础设施资源。附加地或可替换地，部署管理器120能够基于这样的反馈或其他检测到的事件动态地调整应用模型和对应的策略。类似地，这还能够包括指令引退应用组件（例如，代码、中间件（MW）、数据库、操作系统（OS）等等）的较旧的版本并且安装组件的新的版本以使得能实现应用在云基础设施130中的继续部署。

云130可以是混合的以便使得它可以是传统数据中心的组合，所述传统数据中心被做出成表现得像基础设施资源、专用云（在内部开发的云技术）、公用云（由服务提供商提供）以及受管理云配置（内部或在公用云/虚拟专用云中管理）。如本文中所使用的那样，术语应用适用于组件的合集。此外，应用能够针对其组件中的每一个由一组工件（例如，安装程序、可执行文件、配置等等）和被安装并且与彼此交互的一组组件（例如，代码、中间件（MW）、数据库、操作系统（OS）等等）来表征。并且，如本文中所使用的那样，术语确定能够包括编译、枚举以及匹配。

如本文中所使用的那样，术语“基本上”旨在指示虽然正被修改的术语的功能或结果是期望的或计划中的结果但是一些变化能够产生。在这个上下文中，例如，术语“基本上匹配”或其变体描述了结果得到的分析和比较被执行以识别为相同的资源的情形；然而，在实践中匹配能够对应于充分地类似于使得能实现部署（上面识别为绝对匹配或尽力而为匹配）的一组资源。在一个以上这样的一组资源可能对应于匹配时，部署管理器能够选择最佳匹配的一组可用资源。能够利用用于选择这样的匹配的其他方法。

应用模型140能够被采用来诸如通过用于应用的各种组件的元数据描述来表征用于部署在云基础设施130上的给定应用110。部署管理器120能够经由可由处理器执行的指令或可由处理器读取的数据来实现以基于与给定应用相关联的应用模型140和策略150（或诸策略）来分析对于给定应用110的应用要求。如将在下面所描述的那样，策略150能够被提供来描述应用110的附加的操作上下文（例如，在午夜之后操作应用、使用仅东海岸服务器、维护服务器之间的负荷均衡、部署在给定网络域内、确保负荷在服务器上的规定限制之间、确保在给定窗口内不存在即将到来的维护等等以及匹配的“测量接近”的技术）。部署管理器120然后能够确定在云基础设施中足以实现如由模型140和策略150所规定的应用110的应用要求的基础设施资源。

在一个示例中，部署管理器120能够基于对应用110的应用要求与如由资源供应和元数据160所规定的云的能力的匹配自动地将给定应用110部署在云基础设施130上。如本文中所使用的那样，术语“应用”（例如，包括应用110）能够包括将被安装和执行的一组组件。这样的组件的示例包括除用来安装和配置或卸载这样的组件的代码之外的多个分层逻辑、用户接口（UI）、中间件（MW）、数据库（DB）、操作系统（OS）。因此，应用110指的是还能够包括这样的组件和工件的储存库的组件和工件的这些集合。应用110还能够由包括单独的指针或一组组件的指针的组件和工件的指针来识别。在另一示例中，部署管理器120能够生成关于如何将给定应用110部署在云基础设施130上而通知系统（或用户）的指令。在任何一个示例中，部署管理器120能够自动地使如由模型140和策略150所规定的应用110的要求与如由资源供应和元数据160所规定的云130的能力相匹配。

与常规系统的手动过程相反系统100利用策略和模型驱动方法来使部署自动化。系统100能够基于表征它们在基础设施属性方面的要求的模型140和策略150来动态地（或静态地）优化基础设施资源（由元数据属性来表征）并且将基础设施资源绑定到应用110。这能够包括使应用元数据与资源元数据相匹配以及考虑策略和上下文使应用和它们的组件/依赖性在云130上的优化的或优选的/标记的部署自动化而同样无需手动部署步骤。在一个示例中，系统100允许实例的跟踪同时也支持这样的实例的自动化管理（例如，在下面所描述的自动化监视和反馈）。不同的技术被提供来吸入、创造和设计还能够描述基础设施模板、应用模型以及策略的元数据。这样的实例能够连同应用110、应用模型140以及策略150一起存储在数据库或储存库（未示出）中。

系统100能够对于监视应用采用闭合反馈回路（见图4）。这样的监视应用能够被利用来例如按比例放大或者按比例缩小应用执行要求，以及利用来通知适当的接收者，诸如用户或其他系统应用。在一个示例中，监听器能够被安装在各种组件中以从监视捕获事件。由监听器所接收到的事件能够触发处理机，所述处理机能够在系统100上生成生命周期管理操作。一些生命周期管理操作的示例包括按比例放大、按比例缩小、移动、取消提供、向用户或系统报警，或者运行另一可执行文件，其可以牵涉本文中所描述的系统和其他应用的合成。

能够在一个硬件平台上或跨越多个硬件平台实现系统100，其中能够在一个平台上或跨越多个平台执行系统中的模块。这样的模块能够在云技术（各种形式/和混合云）上运行或者作为能够被实现在云上或云之外的SaaS（软件即服务）提供。能够在需要的基础设施资源上自动地部署复杂应用，而同样无需用户理解如何执行这样的操作。策略150为帮助管理员减轻部署错误的操作指导方针提供自动化指令。元数据还能够通过识别应用的类型（例如，经由UI或API）与应用相关联，然后用户不必理解应用特性。这个方法对于应用基于它们与元数据的关联而允许“最佳实践”、推荐的或以其他方式强加的部署模型。

策略同样允许使应用特性与其他上下文考虑事项（例如，关于用户、关于应用、关于基础设施、关于上下文、关于该特定用户、关于特定应用等等）分离。这促进应用模型跨越许多应用的再使用。还能够经由策略实现特殊化（例如，为一个应用或其给定版本与另一版本的关系规定特定的一组策略）。这可以是由系统利用来强制实行特定的一组特性值对于给定应用或版本来说为固定的一个方法。例如，系统能够对于web应用应用通用应用模型，然而在另一情况下，为模型的属性显式地规定不同的模型或特定值。还能够从混合云提供资源（例如，一些资源从本地数据库或服务器提供而一些资源从因特网服务提供）。

出于说明的简化目的，在图1的示例中，系统100的不同的组件被图示和描述为执行不同的功能。然而，本领域的普通技术人员应理解和了解，所描述的组件的功能能够由不同的组件执行，并且能够在单个组件上组合和执行数个组件的功能性。组件能够被例如实现为计算机可执行指令、硬件（例如，专用集成电路或处理单元），或者实现为两者的组合。在其他示例中，组件能够跨越网络分布在远程设备之中。在一个示例中，能够定义拓扑，其中应用模板能够包括应该部署哪些组件（例如，什么组件要被部署在哪一个位置处）的拓扑模型。在另一示例中，部署管理器120能够提供有拓扑模型并且然后确定和它匹配的最好的基础设施资源。在又一个示例中，在资源的提供和应用组件的部署之后，能够创建拓扑实例。如本文中所公开的那样，拓扑实例能够被存储和用于以后的管理、监视。

图2图示了用于应用在云环境中的自动化测试、版本控制以及部署的测试管理器接口200（也被称为接口200）的示例。接口200包括选择窗格（pane）210，所述选择窗格210使得能实现源代码修改和设计、测试套件的构建和启动、释放和部署选项、多平台编排（例如，在应用组件之间使事件同步）以及管理、运行并且使应用环境安全。例如，如本文中所描述的这样的选择窗格还能够经由应用编程接口（API）而暴露于其他应用。服务和支持选项214包括服务治理（例如，金融协定、容量、厂商信息等等）。服务和支持选项214中的服务市场选项包括服务商店、产品商店或对实现、使用数据以及拒付信息的目录请求。选项214中的支持中枢能够包括用例交换和应用管理细节。选项214还能够包括协作式用例管理，诸如针对应用的事故、问题、缺陷、要求、改变以及释放数据的报告和跟踪。信息数据库220能够存储/交换到/来自本文中关于接口200所描述的组件中的每一个的数据。

应用生命周期管理器224能够包括用于对包括合成或混合应用的应用进行设计、建模、构建和测试的选项。服务实现组件230使得能实现服务设计合成和实现、应用建模、部署和工作负荷管理，以及基础设施设计和实现。应用性能模块（APM）使得能实现所部署的应用的性能测试、分析以及分级。服务操作和桥接组件240使得能实现事件处理、监视、分析和报告以及与实时服务模型（RTSM）储存库的交互。基础设施管理组件250提供了用于定义/搜索系统组件、网络组件以及存储组件的选项。这包括用于处理/分析故障、分析应用、网络和/或系统性能并且提供用于配置选项的各种配置接口的选项。资源窗格260包括用于规定应用如何将被部署的选项，包括用于部署在公用云、受管理云、专用云、虚拟运营以及传统部署上（例如，根据标准部署场景）的选项。

接口200和本文中所描述的关联的测试管理器（例如，图1的测试管理器170）使得开发测试者和安全开发者能够对于测试用应用和关联的测试套件的部署具有全自动化。这包括基于模型的自动化，其进一步促进并且加速开发过程。接口200促进待以此采用的模型和配置的创建。这能够包括混合递送模型，其中测试可以在专用云、公用云上，或者测试可以部分地在专用云和公用云上（例如，在测试容量需要（例如，以用于负荷测试）时的突发）。测试能够被从专用云自动地移动到公用云并且能够自动相反地移动。

同样给运营开发者提供了用于应用从开发和测试到生产的部署的全自动化。这包括生命周期管理在运营下的全自动化。基于模型的自动化使得能够构建和再使用从类似的应用创建和/或在开发与测试时使用的模型。这同样包括包括有公用和/或专用云部署的混合递送模型的测试以及如先前所描述的测试。这能够包括监视源储存库以检测改变并且以自动地启动测试。这也还能够包括用于周期性手动的和调度的测试的选项。

图3图示了用于应用的自动化部署、版本控制以及监视的示例系统300。系统300包括用于应用的自动化部署的执行引擎310。这样的引擎还能够包括用于与服务提供商建立服务级别协定的提供管理器并且能够包括上面所描述的部署管理器。事件处理器和调度器314能够被用于处理应用事件并且对与应用相关联的任务进行调度。如本文中所公开的那样，能够定义和安装监听器/处理机以用于监视事件。这能够包括对提供/部署和后续生命周期管理运营进行调度（例如，今夜或部署持续接下来2个星期）。配置监视器320和规则引擎能够被用于配置从应用提供反馈的监视器组件324并且用于应用用于执行该应用的规则和策略。

例如，系统300包括能够包括应用模型、基础设施模型以及工件指针的模型数据库330。实例数据库334能够被采用来存储应用的实现的目标实例。应用用户接口340能够被采用来设计应用并且配置用于操作该应用的元数据，然而基础设施用户接口244能够被采用来规定用于将应用部署在云中的基础设施要求。例如，部署组件350能够包括诸如可以经由部署秘诀（recipe）所规定的部署应用编程接口（API）和指令。一个或多个调出（call-out）354能够为给定应用规定定制的操作指令。提供组件360能够包括用于与各种云基础设施组件交互的提供API和插件。

系统300能够作为设计者工具被利用来构建/部署基础设施和应用模板。它同样允许应用开发者、测试者或其他管理员或设计者构建应用模型。类似地，它们能够为应用的执行和部署设计策略和规则。基础设施和应用数据中的一些或全部能够被吸入到分别作为数据库330和340所示出的储存库中。可替换地，这样的基础设施或应用数据能够经由API来传递。应用工件（代码、可执行文件、安装包等等）能够经由数据库或API被同样吸入或参考。例如，API或入口用户接口340和344能够被用来联合或者上传请求以在也规定要使用的应用模板和策略的同时进行匹配和部署。这样的API和用户接口能够作为设计者工具的一部分被实现来定义元数据并且使元数据与基础设施相关联（例如，经由基础设施模板和拓扑）。

能够提供代理和监视工具的准备和建立以便使得应用能够发现实例（其已被仪表化并且如果需要具有代理）。这能够在将应用及其关联的组件绑定到基础设施资源之后经由利用来部署基础设施和应用元件的指令/秘诀来实现。事件/报告允许闭合反馈回路，所述闭合反馈回路能够被用来（基于策略）按比例放大/按比例缩小或者如果策略允许则针对将来的改变来更新上下文/策略以及通知适当的方或系统（见图4和下面的描述）。如上面所指出的那样，云和资源池可以是其中一些资源被在本地服务而一些被远程地服务的混合实体。对于能够支持自动定标、工作负荷管理以及保证/监视事件的处理的云或硬件资源，应用可以是自我管理的。这样的自我管理例如利用反馈来确定性能，变更应用要求，并且视情况而定生成警报。

图4图示了利用闭环反馈来促进应用的可移植性、测试、版本控制、部署以及监视的示例系统400。系统400包括执行来自存储器414的指令的处理单元410（例如，处理器）。存储器414包括被配置用于存储与计算机相关联的计算机可执行指令的存储介质（例如，易失性的或非易失性的）。处理单元410和存储器420能够作为部署工具420的一部分被提供，所述部署工具420像由可移植性管理器454所命令的那样经由部署管理器450将应用430部署在云基础设施440上。如所示，反馈460从所部署的应用430被接收并且由监视组件470处理。这样的反馈460可以是来自所部署的应用430的指示应用如何在执行的状态或事件。在一个示例中，反馈460能够被采用来调整所部署的应用430的操作参数，其已根据先前确定的应用要求被设置。例如，可以调整前台任务以便使得任务在与目前正在执行的不同数目的微秒期间操作。这能够包括按比例放大或缩小所部署的应用430的操作要求。在另一示例中，反馈460可以被采用来调整云的操作基础设施440。例如，服务级别协定可以与云基础设施服务提供商自动地重新协商以增加或者减少可用资源以适当地满足所部署的应用430的操作需要。

计算机480能够操作一个或多个接口484和测试管理器486以对应用模型490进行编程并且存储在数据库494中。测试管理器486还能够像关于图1先前所描述的那样与部署管理器450和可移植性管理器454一起操作。计算机还能够与部署工具420交互以变更和促进应用的生命周期管理。接口484还能够配置基础设施模板，变更操作要求，配置监视组件470，并且与在系统400内所生成的事件和警报交互。如先前所指出的那样，连同在云上执行一起，所部署的应用430能够跨越不相关云传播或者作为混合应用的一部分被提供。例如，能够部分地在云基础设施440上和部分地在作为与云不同的实体（例如，本地服务器数据库对网络数据库）的数据库494上执行所部署的应用430。

图5图示了用于应用的自动化部署和版本控制的示例方法500。在510处，方法500包括处理对给定应用进行建模的应用元数据（例如，经由图1的部署管理器120）。方法500包括在520处处理描述用于云执行给定应用的资源的资源元数据。在530处，方法500包括基于使应用元数据与资源元数据相匹配以便于执行测试的套件来将给定应用部署在云中。在540处，方法500包括在给定应用的服务生命周期期间跟踪给定应用中的改变并且以依照改变来更新应用元数据。方法500还能够包括基于检测到给定应用中的改变自动地启动测试并且自动地安装与改变兼容的其他组件。方法500还能够包括自动地将给定应用部署在公用云或专用云中的至少一个上。方法500还能够包括监视针对储存库中的给定应用的改变并且基于改变的检测自动地启动测试的套件。

方法500能够作为诸如图1或4中所描绘的示例之类的系统的一部分被自动地执行。系统能够包括用于存储与计算机相关联的计算机可执行指令的存储器和用于访问存储器、执行计算机可执行指令并且从而执行方法500的处理单元。计算机可执行指令能够包括存储在存储器中以表征用于部署在云基础设施上的给定应用的应用模型，其中该应用模型能够由应用元数据来描述。存储在存储器中的部署管理器能够分析给定应用的应用元数据和与给定应用相关联的策略以确定云基础设施中的基础设施资源。基础设施资源能够被规定为资源元数据。部署管理器能够自动地使应用元数据与资源元数据基本上相匹配（例如，识别最接近匹配）以实现应用要求。版本控制管理器能够在给定应用的服务生命周期期间跟踪给定应用中的改变并且依照改变来更新应用模型或策略。系统还能够包括存储在存储器中以基于检测到给定应用中的改变经由部署管理器针对给定应用来配置和启动云中的应用部署的测试套件的测试管理器。

图6图示了用于云应用的自动化部署和版本控制的示例部署系统600。系统600包括应用模块610以表征用于部署在诸如上面关于图1所示出的云基础设施上的给定应用620。部署管理器630基于与给定应用相关联的应用模型610和策略640来分析对于给定应用620的应用要求来确定在云基础设施中用来实现该应用要求的基础设施资源。版本控制管理器650能够在给定应用的服务生命周期期间跟踪给定应用620中的改变并且以依照改变来更新应用模型610或策略640。

图7图示了用于使云基础设施730的资源能力720与应用的应用要求740相关联的可移植性管理器708和部署管理器710的示例。如先前所描述的那样，上面所描述的版本控制管理器和测试管理器能够与可移植性管理器708和部署管理器710部署在一起采用并且合作以用于测试、部署、版本控制以及管理。可移植性管理器708与部署管理器710合作来改变如上面关于图1所描述的云基础设施730上的部署。资源能力720能够包括资源供应750，所述资源供应750可以来自由支持云730的多个资源提供商所提供的资源供应的池。例如，这样的资源供应能够包括云服务（例如，可经由对应的应用程序接口（API）访问）、能够激活并且提供这样的服务的现有系统、或现有外部合成物（具有功能调用的参数化工作流/合成脚本）中的一个或多个。资源供应750能够由资源提供商编译/从资源提供商吸入。

资源能力720同样包括与表征资源的感兴趣属性的每个资源供应相关联的资源元数据760。能够例如基于资源供应（诸如在其吸入下）生成资源元数据。例如，这样的元数据760能够规定除其他规格、容量、SLA、调度的维护、工作负荷（如果已经在部分使用中）外的位置/拓扑（例如，针对合成资源）、硬件、CPU、存储器、所包括或支持的操作系统、其他软件方面以及标签。资源元数据760能够与由资源设计或吸入过程所设计或添加到资源池的任何资源相关联。描述应用模型和资源供应的元数据能够经由设计者（例如，工具、入口UI或API）来捕获以描述元数据。包括秘诀（例如，与用于诸如取消部署和监视之类的部署和其他生命周期管理功能的指令相对应）的元数据能够构成资源模板。由元数据所规定的资源元数据760和所关联的资源供应750能够作为能够被其他应用利用的模板（例如，元数据和供应的数据文件）的一部分被提供。

给定应用的执行要求740能够经由能够在应用设计时或在应用设计之后定义的应用元数据770规定。这能够包括待个别地部署的组件（例如，多个层中的多个应用）。应用元数据760还能够规定关于资源的要求/偏好。这能够包括作为工作流或过程（异步的或同步的）的通用部署脚本。部署脚步能够进一步包括用于每个组件的部署指令（例如，用来在分配的资源上运行的脚本、服务的指令等等）。这能够包括用来部署代理或者为监视和/或管理做好准备的关联指令。能够跨越组件应用指令。例如，应用元数据770能够表示上面关于图1所描述的应用模型。给定应用模型能够被存储在存储器中并且由多个应用利用来促进其部署。如先前所指出的那样，应用能够包括提供有被部署脚本利用的应用的多个合作组件和工件（例如，源或可执行的和可安装的）。

如所示，能够提供适用于应用/基础设施并且参考用于操作应用的上下文的附加策略780。例如，策略可以规定应用的位置（例如，仅在东海岸服务器上操作）、时间（例如，在午夜之后并且在上午6点之前操作）、处理要求（例如，所规定的处理速度和存储器需要）和/或负荷均衡要求（例如，无服务器将在超过50%负荷情况下操作）、SLA、可用性要求（例如，在接下来x天内无调度的维护）、安全（例如，特定网络域或安全域）。如本文所公开的那样，策略可以是可编程的并且诸如基于请求（例如，部署请求或基于检测到一个或多个事件而触发的请求）被修改。

应用能够由部署管理器710像由可移植性管理器708通过检索所关联的元数据770并且基于最佳匹配（如果例如由策略强加则可以是确切标记）和资源池中可用的资源供应750匹配所命令的那样来部署。资源元数据760与应用元数据770的匹配可以是根据严格规格的（例如，处理器必须在1 GHZ下操作）或者能够根据阈值规格（例如，在500 MHZ之上操作的任何处理器都是可接受的）被匹配。因此，匹配在该匹配是最佳拟合或接近于所期望的匹配准则情况下可以是绝对匹配或者可以是基本匹配。秘诀能够由部署管理器710处理并且指的是用于应用部署的代码/工件。例如，这样的秘诀能够经由已知储存库位置变得可用或者经由秘诀的指针来参考。例如，对应于应用的合成资源的拓扑能够被部署管理器710保存为新的资源类型以用于诸如在类似的应用元数据被另一应用使用情况下再使用。相同的应用或类似的应用的多个版本能够再使用相同的应用元数据和应用模型，但是，例如，其中的每一个都可以采用不同的策略来为每个相应的应用建立操作上下文。

上面已描述的是示例。当然，不可能描述组件或方法的每个可想象到的组合，但本领域的普通技术人员应认识到，许多另外的组合和排列是可能的。因此，本发明旨在包含落入本申请（包括所附权利要求）的范围内的所有这样的变更、修改和变化。附加地，在本公开内容或权利要求记载“一”、“一个”、“第一”或“另一”元件或其等同物情况下，它应该被解释成包括一个或一个以上这样的元件，既不要求也不排除两个或更多个这样的元件。如本文中所使用的那样，术语“包括”意指包括但不限于，并且术语“包括有”意指包括有但不限于。术语“基于”意指至少部分地基于。

Claims (15)

1.一种系统，其包括：

应用模型，被存储在存储器中，以表征用于部署在云上的给定应用；

部署管理器，与可由处理器执行的指令相对应，以基于与所述给定应用相关联的所述应用模型和策略来分析对于所述给定应用的应用要求以和在所述云中用来实现所述应用要求的基础设施资源基本上匹配；以及

版本控制管理器，与可由所述处理器执行的指令相对应，以在所述给定应用的服务生命周期期间跟踪所述给定应用中的改变并且以依照所述给定应用中的所述改变来更新所述应用模型或所述策略中的至少一个。

2.根据权利要求1所述的系统，其中所述版本控制管理器将进一步对所述给定应用的组件和工件之间的依赖关系进行建模，所述依赖关系基于在所述给定应用中检测到的改变在所述应用模型或所述策略中被更新。

3.根据权利要求2所述的系统，进一步包括测试管理器以基于检测到所述给定应用中的改变或者基于检测到对所述给定应用的所述组件和工件之间的所述依赖关系的改变对所述给定应用启动测试。

4.根据权利要求3所述的系统，其中所述测试管理器将命令所述部署管理器从所述给定应用更新其他组件以在测试之后修复所述给定应用或所述其他组件中的检测到的问题。

5.根据权利要求4所述的系统，其中所述应用模型或所述策略被更新以反映对于所述检测到的问题的测试要求。

6.根据权利要求1所述的系统，其中所述应用模型和所述策略中的至少一个响应于输入被更新，所述输入由手动过程、工具或逻辑过程提供。

7.根据权利要求1所述的系统，其中所述版本控制管理器使得组件的较旧的版本能够被实时地实例化以支持较新的应用修订版。

8.根据权利要求1所述的系统，进一步包括可移植性管理器，所述可移植性管理器基于检测到所述给定应用中的改变或者基于检测到所述给定应用的组件和工件之间的依赖关系中的改变来使所述部署管理器部署与所述给定应用兼容的其他应用的版本。

9.根据权利要求8所述的系统，其中所述可移植性管理器使所述其他应用作为更高或更低修订版被安装以便于与所述给定应用兼容。

10.根据权利要求8所述的系统，其中所述可移植性管理器基于检测到所述给定应用中的改变或者基于检测到对所述给定应用的所述组件和工件之间的所述依赖关系的改变来使所述部署管理器执行应用实例的滚动升级。

11.根据权利要求1所述的系统，其中所述版本控制管理器维护描述所述给定应用的版本、针对所述给定应用的部署配置或针对所述给定应用的被所述部署管理器用于部署的测试推荐的模板。

12.一种方法，其包括：

由计算机处理用来对给定应用进行建模的应用元数据；

由所述计算机处理用来描述用于云执行所述给定应用的资源的资源元数据；

由所述计算机基于使所述应用元数据与所述资源元数据相匹配将所述给定应用部署在所述云中；以及

在所述给定应用的服务生命周期期间跟踪所述给定应用中的改变并且依照所述改变来更新所述应用元数据。

13.根据权利要求12所述的方法，进一步包括基于检测到所述给定应用中的所述改变自动地启动测试应用并且自动地安装与所述改变兼容的其他组件。

14.一种系统，包括：

存储器，其用于存储与计算机相关联的计算机可执行指令；以及

处理单元，其用于访问所述存储器并且执行所述计算机可执行指令，所述计算机可执行指令包括：

　　应用模型，其被存储在所述存储器中以表征用于部署在云上的给定应用，其中所述应用模型由应用元数据来描述；

　　部署管理器，其被存储在所述存储器中以分析所述给定应用的所述应用元数据和与所述给定应用相关联的策略来确定所述云中的基础设施资源，其中所述基础设施资源被规定为资源元数据并且所述部署管理器自动地使所述应用元数据与所述资源元数据相匹配以实现应用要求；以及

　　版本控制管理器，与可由所述处理单元执行的指令相对应，以在所述给定应用的服务生命周期期间跟踪所述给定应用中的改变并且以依照所述改变来更新所述应用模型或所述策略。

15.根据权利要求14所述的系统，进一步包括测试管理器，所述测试管理器被存储在所述存储器中以基于检测到所述给定应用中的改变经由所述部署管理器针对所述给定应用来配置和启动所述云中的应用部署的测试套件。