Methods and apparatus to update application deployments in cloud computing environments

Methods, apparatus and systems are disclosed to update application deployments in cloud computing environments. An example method disclosed herein includes identifying an update profile to promote across the plurality of deployment environments, the update profile to update a component of the application, in response to a notification of promotion of the update profile received at a first deployment environment. The example method also includes displaying a user-selectable control in a user interface, the user-selectable control to specify whether to apply the update profile to the component of the application deployed in the first deployment environment, based on selection of the user-selectable control, performing a compatibility check of the first deployment environment and the update profile, and based on an outcome of the compatibility check, applying the update profile to the component of the application deployed in the first deployment environment.

RELATED APPLICATION

Benefit is claimed under 35 U.S.C. 119(a)-(d) to Foreign application Serial No. 3122/CHE/2014 filed in India entitled “METHODS AND APPARATUS TO UPDATE APPLICATION DEPLOYMENTS IN CLOUD COMPUTING ENVIRONMENTS”, filed on Jun. 26, 2014, by VMware. Inc., which is herein incorporated in its entirety by reference for all purposes.

FIELD OF THE DISCLOSURE

This disclosure relates generally to virtualized computing environments, and, more particularly, to methods and apparatus to update application deployments in cloud computing environments.

BACKGROUND

“Infrastructure-as-a-service” (sometimes referred to as “IaaS”) generally describes a suite of technologies provided by a service provider as an integrated solution to allow for elastic creation of a fully virtualized, network, and pooled computing platform (sometimes referred to as a “cloud computing platform”). Enterprises may use IaaS as a business-internal organizational cloud computing platform (sometimes referred to as a “private cloud” or a “private cloud computing platform”) that gives an application developer access to infrastructure resources, such as virtualized servers, storage, and networking resources. By providing ready access to the hardware resources required to run an application, the cloud computing platform enables application developers to build, deploy, and manage the lifecycle of a virtual application (e.g., a web application, a networked application, etc.) at a greater scale and at a faster pace than before. To deploy an application, a developer, who understands the architecture of the application, must coordinate with a system administrator, who controls access to computing resources, to determine which computing resources (e.g., computing, networking, and/or storage) and/or software services (e.g., software packages) should be provisioned to support execution of the application.

DETAILED DESCRIPTION

Numerous tools exist to create and deploy applications in cloud computing environments. For example, application provisioning tools enable cloud computing designers to create and standardize application deployment topologies on infrastructure clouds. Some application provisioning tools include graphical user interfaces (GUIs) that enable designers to generate application deployment topologies called application blueprints. These application blueprints define the structure of an application, enable the user of standardized application infrastructure components, and/or include installation dependencies and/or default configurations for custom and packaged enterprise applications. Application blueprints specify logical deployment topologies that are portable across private IaaS clouds (e.g., an enterprise cloud based on VMware vSphere® Platform or any other suitable private cloud network) and across public clouds (e.g., Amazon Web Services (“AWS”) or any other suitable public cloud network). Cloud providers offer a cloud instance for deployment. The deployment environment provides an environment for the cloud provider.

Application designers (e.g., developers) can use the GUI provided by the application provisioning tools to create visual application blueprints. These blueprints standardize the structure of the application, including software components, dependencies, and configurations, for repeated deployments. After a blueprint is available, application designer teams (e.g., development teams, quality assurance teams, release teams, etc.) can repeatedly deploy a standard blueprint, customize configurations as allowed, and deploy within deployment environments (e.g., enterprise approved deployment environments).

Many applications are developed with a multi-tier architecture in which functions such as presentation, application processing, and data management are logically separate components. For example, an enterprise's custom banking application that has a multi-tier architecture may use a cluster of application server nodes (e.g., JBoss Application Servers) to execute in a scalable runtime environment, a database node (e.g., a relational database management system such as MySQL) to store account data, and a load balancer node to distribute network traffic for robustness. Deploying a multi-tiered application in a cloud computing environment may involve a cloud computing platform provider (e.g., VMware®) providing a deployment environment to provision virtual computing resources (e.g., virtual machines (VMs)) in which an enterprise (e.g., an organization, an agency, a corporation, etc.) can deploy its application. When the application is deployed, a large number of deployments of an application may be deployed. Further, if the components/nodes of an application are deployed across multiple deployment environments, making sure the components/nodes are up-to-date, for example, from security vulnerabilities, is a complex and daunting task for an enterprise. Further still, the multiple deployment environments may have different deployers (e.g., administrators) who are responsible for the resources in the deployment environment managed by the administrator. As such, some deployers may elect to update a component/node while other deployers may not update the component/node, resulting in different versions of the same application deployed across multiple deployment environments. Updating (or patching) an application can be a complex, risky, and time-consuming and may include periods of system downtime.

From an application blueprint, different application deployments can be created using deployment profiles to, for example, test prototypes or deploy critical multi-tier applications in production environments. From these saved blueprints, application deployers can generate execution plans for deploying the application to private and/or public clouds. In addition, an update process to scale clustered nodes of deployed applications and/or change the configuration or code of deployed applications when a new version is available may be initiated. Deployment settings (e.g., virtual computing resources' cluster size, CPU, memory, networks, etc.) and an execution plan of tasks having specified computing resources are provisioned and application components are installed, configured and started. The deployment profile provides an administrator with a process-oriented view of the application blueprint that indicates discrete steps to be performed to deploy the application. The deployment settings can be encapsulated in the deployment profiles, separate from the application blueprints. Different deployment profiles may be generated from a single blueprint to test prototypes (e.g., new application versions), to scale-out and/or scale-in deployments, and/or to deploy the application to different deployment environments (e.g., testing, staging, production). In addition, a deployment profile may be distributed as a local deployment plan having a series of tasks to be executed by virtual machines provisioned from a cloud computing environment.

For example, for a load balancer, if an administrator is deploying an application to a test environment, the administrator may select an internal network for two load balancer network NICs. In contrast, when the administrator creates a deployment profile for the production environment, the administrator may select an internal network for one load balancer NIC and an external network for the other load balancer NIC.

To protect their systems, enterprises may need to periodically update (or patch) an application or deployment. When a deployed application is updated, application provisioning tools may create an update profile that captures new values for the changes required for that update. Updates may also be rolled back to restore a previous update. Saved update profiles may be deployed multiple times to update existing deployments. An update profile may be created by scaling-in and/or scaling-out a cluster of a node or modifying the configurations of existing services and/or application components. Update profiles enable application designers to update the components/nodes of an application already deployed in the deployment environment. An update profile may be processed to update configuration properties of the components/nodes (e.g., modify the configurations and/or code of existing services in a deployed application e.g., a database node) or application components such as SQL, modify a port number, change passwords, certificates, scripts, change the tasks to be executed by the virtual machines, etc.). Update profiles may also be processed to scale-in a deployment (e.g., free resources from a virtual machine when workloads decrease at the computing node) or scale-out a deployment (e.g., allocating resources (e.g., virtual machines, networking resources, storage resources, etc.) for use by a virtual machine when workloads increase at the computing node).

To more efficiently update a deployed application, as disclosed herein, an update profile may be promoted to notify multiple (e.g., all) deployments of the same application in the available deployment environments that an update is available for deployment. A deployer may promote an existing update profile to update any deployment across multiple deployment environments. For example, a deployer can apply a security-related configuration update to one or more components of an application on different deployments originating from the same application version. For example, an application designer can create an update profile and apply the update to a deployment in a deployment environment (e.g., a development deployment environment). If the application designer wishes to update other deployments of the application scattered across multiple deployment environments, the application designer may promote the update profile to selected ones of available deployment environments.

In some instances, it may be beneficial to rollback an update process. For example, if an update process fails to modify a configuration, performance problems develop in the updated deployment, etc., the rollback process may be initiated to restore that update to the last successful state in its timeline. When rollback of an update process is initiated, the rollback process is performed on the services and/or components the update process attempted to modify, and also on any dependent nodes.

Examples disclosed herein also create a master copy of the update profile to copy and make available (e.g., distribute) to the selected ones of the deployment environments. In addition, examples disclosed herein maintain a log of promoted update profiles including, for example, which update profiles were updated (e.g., a source update profile), which deployment environments were selected, which copies of the update profiles were made available to the deployment environments, which deployment environments accepted the updates, etc.

An application may be scattered across multiple deployment environments in which multiple administrators control the resources in the deployment environments managed by the respective administrators. Rather than forcing an update onto each of the deployment environments, examples disclosed herein enable each administrator of the selected ones of the deployment environments to accept or reject the updates identified in the promoted updated profile. Examples disclosed herein create a local update profile based on the promoted update profile at a deployment environment when the respective administrator accepts the update. In this manner, the administrator is provided control of the resources in the deployment environment managed by the administrator. The administrator may also edit the local update profile based on the needs known to the administrator.

In some examples, an update for a first version of an application may not be compatible with a second version of the application. Accordingly, examples disclosed herein also perform a compatibility check when an update identified in a promoted update profile is accepted. Some examples may include a check of whether the promoted update is compatible with the target application by checking, for example, whether updated components/nodes are present and executing in the deployment environment, whether updated properties or configurations are present in the target application, whether the deployment environment includes cluster nodes, whether the target application is executing compatible components/nodes (e.g., a Microsoft Windows® update is not being applied to a Linux® executing node, etc. If an update is determined not to be compatible with the target application, the update process may be cancelled and/or discarded.

As used herein, a node is a virtual machine and/or a cluster of virtual machines (also referred to as a “cluster node”). A virtual machine is a software stack comprising one or more operating systems, applications and/or services. As used herein, an application (also referred to herein as a “virtual application” or an “appliance”) is a logical deployment unit that defines the relationship between an operating system one or more application components and/or services dependent on the operating system. An application may also define the relationship between application components that can be distributed across multiple virtual machines. As used herein, an application component refers to services and/or code components. Code components are application-specific binaries, scripts, or processes, etc., usually written by a developer and packaged into one or more files, to provide logic (e.g., relationship definitions) for an application. In some examples, code components may be a type or format of scripting and application code. Example types of code components include Java Archive (JAR) files, Java Enterprise Archive (EAR) files, Java web application archive (WAR) files, Ruby Gem packages, SQL scripts, and other suitable modules of scripting logic.

Services, as used herein, are scripted software that provide a software infrastructure for an application. Services may be reused in multiple applications. Example services include application servers (e.g., Rails, Apache Tomcat, JBoss, etc.), database servers (e.g., GemFire, MySQL, SQLFire, MongoDB, Postgress, etc.), monitoring services (e.g., Hyperic, SpringInsight, etc.), web servers (e.g., Apache, VMWare vFabric Enterprise Ready Server, etc.), messaging services (e.g., RabbitMQ, etc.), middleware services, etc. As used herein, the term component generally refers to one or more of application components, code components, and/or services.

FIG. 1is a block diagram of an example cloud computing environment100. In the illustrated example ofFIG. 1, an example application102created by an example developer106is deployed for an example enterprise104in an example deployment environment112provided by an example cloud computing platform provider110(also referred to as a “cloud provider”). In the illustrated example, the cloud computing platform provider110ofFIG. 1provides multiple deployment environments112, for example, separate deployment environments may be used for development, testing, staging, and production of the application102. For example, an example development version102aof the application102is deployed in an example development deployment environment112a, an example testing version102bof the application102is deployed in an example testing deployment environment112b, an example staging version102cof the application102is deployed in an example staging deployment environment112c, and an example production version102dof the application102is deployed in an example production deployment environment112d. The example enterprise104may access services from the example cloud computing platform provider110, for example, via a client-server communication protocol such as representational state transfer (REST) application programming interfaces (APIs). In the illustrated example ofFIG. 1, the cloud computing provider110provisions virtual computing resources (e.g., example virtual machines114) to provide the respective deployment environments112in which the enterprise104can deploy the application102(e.g., a multi-tiered application).

In the illustrated example ofFIG. 1, the developer106uses an example application director116, which may be implemented by one or more virtual machines114, to orchestrate deployment of the application102into the deployment environments112. In the illustrated example ofFIG. 1, the application director116includes an example topology generator118, an example deployment profile generator120, an example deployment director122, an example profile promotion handler124, and an example cloud interface126.

In the illustrated example ofFIG. 1, the example topology generator118generates an example application blueprint128specifying a logical topology of the application102, which is to be deployed. The example blueprint128maps the structure of the application102as a collection of components/nodes (e.g., an example load balancer node130, an example application server (appserver) node132, and an example database node134). Applications, such as the application102ofFIG. 1, are typically developed with a multi-tier architecture in which functions such as presentation, application processing, and data management are logically separate components. For example, the topology generator118may generate a blueprint128(e.g., a topology map) for an online store application specifying a web application executing on an application server (e.g., an Apache Tomcat application server) that uses a data store as a database (e.g., a MongoDB). The example web application may be implemented by a Java web application archive (e.g., a “WAR” file) comprising dynamic web pages, static web pages, Java servlets, Java classes, and/or other properties, configuration information and/or resource files included in the Java web application. In the illustrated example, the blueprint128is an abstract representation of the structure of the application102including virtual machines and their corresponding application components, operating systems, dependencies and/or configurations. In some examples, the blueprint128standardizes the structure of an application for repeated deployments in multiple and/or diverse deployment environments. The application102may alternatively describe, for example, an entire online store application, including application server components and database components, rather than just the web application itself.

In the illustrated example ofFIG. 1, the topology generator118retrieves virtual computing resources from an example catalog120to assemble the blueprint128. For example, the catalog120may list virtual computing resources (e.g., virtual machines, networking resources, storage resources, etc.) that may be provisioned from the cloud computing platform provider110and corresponding application components (e.g., software services, scripts, code components, application-specific packages, etc.) that may be installed on the provisioned virtual computing resources. The example catalog120of the illustrated example is pre-populated with available virtual computing resources and/or application components. In some examples, an administrator108(e.g., an information technology (IT) administrator, a system administrator, etc.) customizes the catalog120by adding and/or modifying the available virtual computing resources and/or application components listed in the catalog120. For example, the administrator108may enter specifications, configurations, properties, custom tasks, etc. about each entry in the catalog120. The example blueprint128of the illustrated example includes an installation order for the application components during deployment. For example, the blueprint128may define dependencies between one or more of the application components that controls the installation order. For example, the developer104may specify a dependency from an Apache service (e.g., the example load balancer node130) to an application code package such as a web application (e.g., the example appserver node132). In some such examples, the dependency may be that the load balancer may not be configured until installation of the web application is complete.

In the illustrated example ofFIG. 1, the deployment profile generator120generates an example deployment profile136based on the blueprint128. The example deployment profile136includes deployment settings (e.g., state information such as virtual computing resource cluster sizes, processing resources, memory, networking resources, etc.) and an execution plan identifying tasks having an order in which virtual computing resources are provisioned and application components are installed, configured, and started. The deployment profile136of the illustrated example is a process-oriented view of the blueprint128. For example, the administrator108may follow discrete steps included in the deployment profile136to deploy the application102. In some examples, different deployment profiles136may be generated from a single blueprint128to test prototypes (e.g., new application versions), to update application versions, to scale (e.g., scale-out or scale-in) deployments, and/or to deploy the application102to different deployment environments (e.g., the development version102adeployed in the development deployment environment112a, the testing version102bdeployed in the testing deployment environment112b, the staging version102cdeployed in the staging environment112c, the production version102ddeployed in the production deployment environment112d, etc.). In the illustrated example, the deployment profile generator120stores deployment profiles such as the example deployment profile136in an example profile repository138. The example deployment profile generator120ofFIG. 1stores the deployment profiles for subsequent use (e.g., at a deployment-time) to deploy, for example, the application102.

In the illustrated example, the deployment profile generator120generates the deployment profile136in response to user input (e.g., from the developer106) to initiate a deployment process for the application102in a specified deployment environment112. In some examples, the deployment profile generator120allows the administrator108to insert one or more custom tasks in the deployment profile136. For example, custom tasks may be scripts that, when executed by a virtual machine, perform operations that facilitate deployment of the application102, including, for example, monitoring tasks, e-mail and alert notification tasks, operations that pre-configure a virtual machine, operations performed prior to provisioning a virtual machine, and other scripting operations.

The example deployment director122ofFIG. 1orchestrates execution of the example deployment profile136for the application102in coordination with the example virtual machines114included in the deployment. The example deployment director122communicates with the cloud computing platform provider110via the example cloud interface126to provision and configure the example virtual machines114in the deployment environments112, as specified by the deployment profile136. In some examples, the deployment director122separates the deployment profile136into local deployment profiles for each one of the virtual machines114. In the illustrated example, the deployment director122maintains a central state of the deployment process that specifies the dependencies at deployment-time between tasks to be performed across the virtual machines114in a specified order. For example, the deployment director122may send a message to one or more of the virtual machines114when deployment-time dependencies in their respective local deployment profiles are satisfied.

In the illustrated example ofFIG. 1, the cloud interface126provides a communication abstraction layer by which the application director116may communicate with, for example, a heterogeneous mixture of cloud provider(s)110and deployment environment(s)112. In the illustrated example, the deployment director122provides the virtual machines114with a series of tasks specific to the respective virtual machines114(e.g., a local deployment profile). The tasks may be scripts that are executed by the respective virtual machines114to install, configure, and/or start one or more nodes. For example, a task may be a script that, when executed by the virtual machines114, causes the respective virtual machines114to retrieve and install particular software packages from, for example, a Git repository, a package manager, and/or other application component resources.

In the illustrated example, the deployment director122coordinates with the virtual machines114to execute the tasks in an order that observes installation dependencies between the virtual machines114according to the deployment profile136. For example, in the development deployment environment112a, the example load balancer node130is executed by the virtual machine114a, and the appserver node132and the database node134are executed by the virtual machine114b. The virtual machine114aof the illustrated example is configured based on the deployment profile136to coordinate execution of tasks to deploy the load balancer node130to run in the development deployment environment112a. The virtual machine114bof the illustrated example is configured based on the deployment profile136to coordinate execution of tasks to deploy the appserver node132and the database node134to run in the development deployment environment112a. Although the appserver node132and the database node134are shown running on the same virtual machine114b, in other examples, separate virtual machines114in the development deployment environment112amay be provided to run a corresponding one of the appserver node132and the database node134.

To deploy such a multi-tier application, a developer106, who understands the architecture of the application102, must coordinate with a system administrator108, who controls access to the computing resources, to determine which computing resources (e.g., computing, networking, and storage) and software services (e.g., software packages) should be provisioned to support execution of the application102. At times, it may be necessary to update a deployed application such as the example application102. For example, a security vulnerability of an application may need to be patched. The developer106may create an update profile, as described herein, to update a deployed application. For example, using the deployment profile generator120, the developer106may create an example update profile140by modifying properties and/or configurations of a deployed application. For example, the update profile140may be created by changing a port number, changing a password, changing security certificates, changing tasks, increasing (e.g., scaling-out) the number of nodes in a node cluster, decreasing (e.g., scaling-in) the number of nodes in a node cluster, etc.

In the illustrated example, while creating the update profile140, the developer106inputs modifications to the deployment profile136in the development deployment environment112a. These modifications are stored in the update profile140. Once the update profile140is created, the developer106may apply the update profile140to the deployments in a deployment environment112ato update the application deployment. The developer106may also want to apply the update profile140to the one or more other deployment environments112in which the application is deployed.

In the illustrated example ofFIG. 1, the profile promotion handler124includes an example profile promoter146to enable a developer106to “promote” an update profile for deployments in a same deployment environment and/or across multiple deployment environments. In the illustrated example, the profile promotion handler124stores the update profile140in an example promotion repository144for subsequent use. When an update profile140is promoted, deployments of the same application (e.g., all other deployments) are notified of the update profile140.

The example profile promoter146ofFIG. 1facilitates managing update profiles. The example profile promoter146of the illustrated example enables a user to “promote” an update profile across multiple deployment environments. For example, after developing the update profile140in the development deployment environment112a, the developer106may wish to update the application102bin the testing deployment environment112busing the update profile140. For example, the testing deployment environment112bmay enable the developer106to more thoroughly test the update profile140than what is possible in the development deployment environment112asuch that the update can be validated prior to deployment to the production deployment environment112dor another deployment environment.

In the illustrated example ofFIG. 1, the profile promoter146stores a master copy142of the update profile140in the promotion repository144and then deploys the update profile140to selected ones of the deployment environments112. The example profile promoter146logs the promotion in a data structure such as a lookup table in the promotion repository144. In this manner, the profile promoter146maintains a log of which update profile140is deployed and into which deployment environment112the deployment has occurred, as well as a copy (e.g., the example master copy142) of the update profile140. “Promoting” an update profile140may include rolling back an update process of the deployed application102to a stable version. For example, when an update profile is applied to the deployed application102, the update process may result in a “bug” that was previously unknown to the developer106and render the deployed application102unusable in one of the deployment environments112. Once the update profile (e.g., the update profile resulting in the bug) was promoted and applied to the selected ones of the deployment environments and the bug is identified, the developer106may promote a previous version of the update profile or an alternative update profile so that the deployed application rolls back to a stable version that does not include bug.

In the illustrated example, the application director116(and/or component(s) of the application director116such as the profile promotion handler124) may be running in one or more of the virtual machines114and may be used by the developer106and/or the administrator108of a deployment environment112. When an update profile is “promoted” to the deployment environment managed by the administrator108(e.g., by the developer106), the administrator108of the deployment environment receives a notification of the update. To prevent malicious update profiles from being applied to deployments, the example profile promotion handler124also includes an example promotion deployer148to enable an administrator108to accept, review, apply or reject a received update profile prior to deployment of the update profile140in the deployment environment112managed by the administrator108. In this manner, an administrator108is able to maintain control over the deployments in the deployment environments112managed by the respective administrator108. For example, the administrator108may request more information about the update profile140before processing the update profile140. In other examples, the administrator108may manually apply the update profile140. In still other examples, the administrator108may accept the update profile140, but modify the update profile140prior to deployment in the deployment environment112managed by the administrator102. When the administrator108decides to review, apply and/or accept the update profile140, the promotion deployer148creates and stores a local copy of the update profile140. By storing a local copy of the update profile140, the update profile140may be edited (e.g., changed) without affecting the update profile140deployed to the other ones of the deployment environments112.

When the update profile140is reviewed, applied and/or accepted, the example promotion deployer148of the illustrated example performs a compatibility check to confirm that the virtual machines114in the deployment environments112in which the update profile is to be applied are eligible for (e.g., compatible with) the update profile140prior to deploying the deployment profile136to the respective deployment environment112. For example, the deployment profile136may include tasks to install, configure and start a database node that runs on a Microsoft Windows® operating system, while the virtual machines114in the deployment environment112execute a Linux® operating system. The example promotion deployer148alerts the user (e.g., the administrator108) via, for example, audio and/or visual notifications when the attempts to apply an incompatible deployment profile (e.g., the deployment profile136) to the deployment environment112.

As described above,FIG. 1depicts the example cloud computing environment100in which a deployed application can be updated across multiple deployment environments112. The example profile promoter148receives selection of the update profile140and identifies deployment environments112in which to deploy the update profile140. The example profile promoter148also maintains a log of update profiles140, including an identification of when the update profile140is updated, to which deployment environments112the update profile140is promoted, and which version (e.g., copy) of the update profile140was promoted.

When the update profile140is promoted, the example promotion deployer148at each of the selected ones of the example deployment environments112makes a decision on whether to accept, review, apply or reject the example update profile140independent of the other deployment environments112. For example, a developer106may develop the update profile140in the first deployment environment112and, using the example profile promoter146, the developer106may promote the update profile140to a second and third ones of the deployment environment112. The example profile promoter146logs the promotion including which version of the update profile140was promoted and to which deployment environments112the update profile140was promoted. The example profile promoter146stores a copy of the update profile140(e.g., the master copy142) in the promotion repository144when the update profile140is promoted. A first administrator108of the second deployment environment112may then accept and apply the update profile140to the deployments in the second deployment environment112while a second administrator108of the third deployment environment112may reject the update profile140. The example promotion deployer148for the example second deployment environment112performs a compatibility check with the example update profile140, and then stores a copy of the update profile140(e.g., a local copy of the update profile140) and applies the update profile140to the deployments in the second deployment environment112. In some examples, the promotion deployer148stores a local copy of the update profile140when the update profile140is promoted, regardless of whether or not the administrator108accepts, reviews, applies or rejects the update profile140.

While an example manner of implementing the application director116is illustrated inFIG. 1, one or more of the elements, processes and/or devices illustrated inFIG. 1may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example topology generator118, the example deployment profile generator120, the example deployment director122, the example profile promotion handler124, the example cloud interface126, the example profile promoter146, the example promotion deployer148and/or, more generally, the example application director116ofFIG. 1may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example topology generator118, the example deployment profile generator120, the example deployment director122, the example profile promotion handler124, the example cloud interface126, the example profile promoter146, the example promotion deployer148and/or, more generally, the application director116ofFIG. 1could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example topology generator118, the example deployment profile generator120, the example deployment director122, the example profile promotion handler124, the example cloud interface126, the example profile promoter146and/or the example promotion deployer148is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, the example application director116ofFIG. 1may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIG. 1, and/or may include more than one of any or all of the illustrated elements, processes and devices.

FIG. 2illustrates an example deployment profile generator graphical user interface (GUI)200that may be presented by the example deployment profile generator120ofFIG. 1. The example deployment profile generator GUI200displays a representation of the example deployment plan136for a three-tiered application. In the illustrated example ofFIG. 2, the deployment profile generator GUI200includes a canvas202presenting the example virtual machine114a, including the example load balancer node130, the example virtual machine114b, including the example app server node132executing a web application (e.g., “bank_app”), and an example MySQL database node134, which represent the different virtual machines and nodes of the example application102ato be deployed to the deployment environment112a. In the illustrated example, each node130,132,134includes tasks (e.g., an example task204A, an example task204B, an example task204C, an example task204D and an example task204E) representing action scripts to be executed on the corresponding virtual machines114a,114b.

As discussed above, when the example developer106(FIG. 1) develops the application blueprint128for the application102, the developer106may specify one or more dependencies between application components to declare a relationship between the application components. Dependencies may be used to plan deployment of the application102by defining a deployment order for application components (e.g., that indicates whether deployment tasks for one item will wait to run until the tasks for the other item has finished).

Dependencies are identified by the developer106by, for example, defining them in the catalog120. A dependency may be an intra-node dependency or an inter-node dependency. A dependency between application components may be defined between application components in the same node (e.g., an “intra-node” dependency) to represent that, at that node, tasks for one application component are performed after tasks for the other application component. In the illustrated example, intra-node dependencies are illustrated by solid directional lines between two tasks. Alternatively, dependencies between application components may be defined between application components in different nodes (e.g., “inter-node” dependencies) such that tasks for an application component at a first node are performed after tasks of an application component at a second node have been completed. In the illustrated example, inter-node dependencies are illustrated by dashed directional lines between two tasks.

In the illustrated example ofFIG. 2, the deployment plan136ofFIG. 2specifies that a task does not begin execution until a preceding task, as indicated by solid directional lines206, has been completed. For example, a virtual machine (labeled as “database”) executes action scripts for installing (e.g., “MySQL-INSTALL”), configuring (e.g., “MySQL-CONFIGURE”), and starting (e.g., “MySQL-START”) a MySQL database service. Because of the dependency implied between the MySQL database and SQL script (e.g., the SQL script may not be executed before the MySQL database is deployed), the example task204B for executing the “init_db_script” SQL script (e.g., “init_db_script-INSTALL”) is placed after the last task for deploying the MySQL database (e.g., “MySQL-START”) (e.g., the example task204A) has been completed. Similarly, the example task204D for deploying the bank application (e.g., “Bank_App-INSTALL”) is placed after the last task for deploying the application server (e.g., “JBossAppServer-START”) (e.g., the example task204C) has been completed.

In the illustrated example ofFIG. 2, the deployment plan136also specifies inter-node dependencies between the nodes, as indicated by a dashed directional line208. For example, since a load balancer usually cannot be configured until a web application is running, in the three-tiered application102ofFIG. 2, the example deployment plan136specifies that the example task204E for deploying the load balancer (e.g., “Apache_LB-INSTALL”) does not begin execution until the example task204D for deploying the web application (e.g., “bank_app-INSTALL”) is completed.

A single appserver node132in the illustrated example represents a cluster of appserver nodes132. For example, the example appserver node132ofFIG. 2is a cluster node including two sub-nodes (e.g., “app_server[0]” and “app_server[1]”). In some examples, the sub-nodes may include additional sets of deployment-time dependencies. For example, the deployment plan136may indicate that the task204D (e.g., “Bank_App-INSTALL”) complete in all sub-nodes (e.g., “app_server[0]” and “app_server[1]”) before the task204E (e.g., “Apache_LB-INSTALL”) may begin. Alternatively, each node in a cluster of the nodes may be represented by a separate virtual machine114.

FIG. 3depicts an example profile promoter GUI300that may be presented by the example profile promoter146ofFIG. 1. The example profile promoter GUI300is presented by the example profile promoter146to enable users (e.g., the developer106) to manage update profile promotions. In the illustrated example, the profile promoter GUI300is populated with information about an example update profile302(e.g., UPR1_Webserver_to_90) that is installed in several deployment environments (e.g., the example deployment environments112ofFIG. 1) and that may be promoted. In the illustrated example, the profile promoter GUI300is provided with a user-selectable ‘Manage Update Promotion’ GUI control304that is displayed to allow a developer106to specify whether the update profile302is to be promoted across one or more deployment environments. In the illustrated example, when the ‘Manage Update Promotion’ GUI control304is selected in the example profile promoter146by a user, the profile promoter146detects the selection (e.g., via a flag that is set, a value that is set to one, etc.) of the ‘Manage Update Promotion’ GUI control304and enables the update profile302to be promoted to one or more deployment environments112. The ‘Manage Update Promotion’ GUI control304of the illustrated example is a linked selectable icon. Alternatively, the ‘Manage Update Promotion’ GUI control304may be a text box, a check box, etc.

FIG. 4depicts another example profile promoter GUI400that may be presented by the example profile promoter146ofFIG. 1. The example profile promoter GUI400is presented by the example profile promoter146to enable users (e.g., the developer106) to select example available deployment environments402to promote the update profile302ofFIG. 3. When a user of the example profile promoter146selects the ‘Manage Update Promotion’ GUI control304in the profile promoter GUI300ofFIG. 3, the profile promoter GUI400presents the user with information about an available update profile404(e.g., UPR1_to_2000) that may be applied to the update profile302. For example, the update profile404may be for the same component and/or service as the update profile302. In such instances, when the update profile404is available for promotion, selecting the ‘Manage Update Promotion’ GUI control304in the profile promoter GUI300ofFIG. 3results in presenting the information about the update profile404. The profile promoter GUI400displays a listing of the example available deployment environments402selectable by the user of the example profile promoter146to promote the selected update profile404. In this manner, administrators of the selected deployment environments402can be notified of the update profile404and that a deployment in the deployment environment managed by the respective administrators is eligible for an update. In some examples, the deployment environments402may include the example deployment environments112ofFIG. 1. In the illustrated example, a human interface device pointer406is shown selecting an available one of deployment environments402such that the selected one of the example deployment environments402displayed in the profile promoter GUI400is added by a user to the listing of the selected deployment environments408in which the selected update profile404is to be promoted.

The profile promoter GUI400of the illustrated example is provided with an example single addition control410aand an example multiple addition control410bto add ones of the selected deployment environments402in which the selected update profile404is to be promoted. When a user of the example profile promoter146selects the example single addition control410a, the selected one of the available deployment environments402is moved to the listing of the selected deployment environments408. When the user selects the example multiple addition control410b, the selected ones of the available deployment environments in the example listing of available deployment environments402are moved to the example listing of the selected deployment environments408.

The example profile promoter GUI400includes an example single removal control412aand an example multiple removal control412bto remove selected ones of the deployment environments from the example listing of selected deployment environments408. When the user selects the example single removal control412a, the selected one of the deployment environments from the example listing of selected deployment environments408is removed from the example listing of the selected deployment environments408and moved to the example listing of the available deployment environments402. When the example user selects the multiple removal control412b, the selected ones of the deployment environments in the example listing of selected deployment environments408are removed from the example listing of the selected deployment environments408and moved to the example listing of the available deployment environments402.

A user of the example profile promoter146may use the human interface device pointer406to select an example update promotion ‘Submit’ control414such that selected ones of the example deployment environments included in the example listing of selected deployment environments408in the profile promoter GUI400are the deployment environments in which the selected update profile404is to be promoted. Alternatively, the user may use the human interface device pointer406to select an example ‘Cancel’ control416to cancel the manage update promotion process. In the illustrated example, when the update promotion ‘Submit’ control404is selected, the deployment environments included in the listing of selected deployment environments408are stored in a data structure such as a lookup table in the example promotion repository144. In some examples, when the update promotion ‘Submit’ control404is selected, the deployment environments included in the listing of selected deployment environments408are stored with the selected update profile404.

FIG. 5depicts an example promotion deployer GUI500presented by the example promotion deployer148ofFIG. 1. The example promotion deployer GUI500is presented by the example promotion deployer148to notify users (e.g., the administrator108) of example deployments in the deployment environment managed by the user (e.g., the administrator108) that have a promoted update profile that is available to be applied. The example promotion deployer GUI500displays example deployment information502for nine example deployments included in the user's deployment environment. The example promotion deployer GUI500includes an example notification control504to notify a user when an update profile (e.g., an example update profile identified in information block503) has been promoted and is available for deployment in the user's deployment environment. In the illustrated example, a human interface device pointer506is shown selecting the notification control504. In the illustrated example, selecting the notification control504causes a selected one of the deployments identified in the example deployment information502displayed in the example promotion deployer GUI500to be identified as the deployment with an available update profile that the user wants to review, accept, and apply the update profile503or reject the update profile503.

FIG. 6depicts another example promotion deployer GUI600presented by the example promotion deployer148ofFIG. 1. The example promotion deployer GUI600is presented by the example promotion deployer148to allow a user to accept, review, apply or reject an update profile identified in profile label602. The example update profile identified in profile label602includes information about the update profile such as a creator identified at creator label603. In the illustrated example, the promotion deployer GUI600includes a user-selectable ‘Accept and Apply Update’ control604that is displayed to allow a user to specify that the update profile identified in the profile label602is to be applied to deployments in the deployment environment. In some examples, when the user selects the ‘Accept and Apply Update’ control604(e.g., via human interface device pointer606), the promotion deployer148initiates a compatibility check to determine whether the update profile identified in the profile label602is compatible with the deployments in the deployment environment. In the illustrated example, when the user selects the ‘Accept and Apply Update’ control604, the promotion deployer148creates a local copy of the update profile identified in the profile label602that may be used to apply the update profile, modify the update profile, etc. In the illustrated example, the promotion deployer GUI600includes a user-selectable ‘Reject’ control608that is displayed to allow a user to specify that the update profile identified in the profile label602is not to be applied to deployments in the deployment environment. For example, the administrator108may not know and/or trust the source of the update profile and/or the creator of the update profile and may elect to reject deployment of the untrusted update profile.

FIG. 7Ais a block diagram700illustrating an example flow for promoting an update profile. In the illustrated example ofFIG. 7A, an example update profile702(“SUP1”) is promoted704from the example development deployment environment112ato the example testing deployment environment112b. When the example update profile702(“SUP1”) is promoted, the update profile702is a source profile and a copy profile (e.g., a copy of the master profile) is made available to the testing deployment environment112b. In the illustrated example, the copy profile is renamed as update profile706(“AUP1”) and applied at the testing deployment environment112b. At a later time, the update profile706may be promoted to one or more additional deployment environments. For example, in the illustrated example, the update profile706is promoted708ato itself (e.g., the testing deployment environment112bto, for example, re-apply the update profile in the testing deployment environment112b) and is promoted708bto the staging deployment environment112c. Copies of the update profile706are made available to the testing deployment environment112bto apply and to the staging deployment environment112cto apply.

FIG. 7Bis an example data table720representing update profile promotions that may be stored by the example profile promoter146ofFIG. 1in the example promotion repository144ofFIG. 1. The example data table720identifies an entry identifier722, a source profile identifier724, a copy profile identifier726, and a deployment environment identifier728. In the illustrated data table720, the entry identifier722identifies an entry number in the data table720. The source profile identifier724identifies the update profile (e.g., the example update profile140ofFIG. 1) that is being promoted. The copy profile identifier726identifies the copy of the master copy (e.g., the example master copy142ofFIG. 1) made available to deployment environments. The deployment environment identifier728identifies the corresponding deployment environment the copy of the master copy was made available.

The data table720ofFIG. 7Bcorresponds to the example flow diagram700ofFIG. 7A. For example, row730of the data table720indicates that the update profile (“SUP1”) (e.g., the update profile702) was promoted to the testing deployment environment and a copy profile (CUP1) of the source profile was made available to the testing deployment environment. Example rows732and734indicate that the update profile (“AUP1”) (e.g., the update profile706) was promoted to the testing deployment environment and the staging deployment environment, and that a copy profile of the source profile (“CUP2”) was made available to the testing deployment environment and the staging deployment environment, respectively. In the illustrated example, the copy profile (“CUP2”) is the second copy made and identified accordingly.

FIG. 8Ais a block diagram800illustrating an example flow for promoting an update profile. In the illustrated example ofFIG. 8A, during a first promotion, an example update profile702(“SUP”) is promoted from the development deployment environment112ato the testing deployment environment112b(e.g., promotion704), and during a second promotion, the update profile706(“AUP1”) is promoted from the testing deployment environment112bto the testing deployment environment112b(e.g., promotion708a) and the staging deployment environment112c(e.g., promotion708b), as illustrated inFIG. 7A. In the illustrated example, a third promotion includes promoting the update profile706(“AUP1”) a second time (e.g., promotions802a,802b, and802c). When the update profile706(“AUP1”) is promoted the second time, the update profile706(“AUP1”) is treated as the source profile and a copy profile (e.g., a copy of a master profile) is made available to the testing deployment environment112b(e.g., promotion802a), and the production deployment environment112d(e.g., promotion802b). However, during the third promotion, the update profile706is withdrawn from the staging deployment environment112c(e.g., promotion802c) as indicated by the dashed line of802c. In some examples, when the update profile706is withdrawn from the staging deployment environment112c(e.g., promotion802c), the application deployment in the staging deployment environment112c“rolls back” to a previous update profile.

FIG. 8Bis an example data table810representing update profile promotions that may be stored by the example profile promoter146ofFIG. 1in the example promotion repository144ofFIG. 1. The example data table810identifies an entry identifier812, a source profile identifier814, a copy profile identifier816, and a deployment environment identifier818. In the illustrated data table810, the entry identifier812identifies an entry number in the data table810. The source profile identifier814identifies the update profile (e.g., the example update profile140ofFIG. 1) that is being promoted. The copy profile identifier816identifies the copy of the master copy (e.g., the example master142ofFIG. 1) made available to deployment environments. The deployment environment identifier818identifies corresponding deployment environment the copy of the master copy was made available, respectively.

The example data table810corresponds to the example flow diagram800ofFIG. 8A. For example, rows820,822and824correspond to the third promotion802a,802b,802c(e.g., the second promotion of the update profile706(“AUP1”). Example rows820and822indicate that the update profile (“AUP1”) (e.g., the update profile706) was promoted to the testing deployment environment (e.g., the testing deployment environment112b) and the production deployment environment (e.g., the production deployment environment112d) and that a copy profile of the source profile (“CUP3”) is made available to the testing deployment environment and the production deployment environment, respectively. In the illustrated example, the copy profile (“CUP3”) is the third master copy made and identified accordingly. Row824indicates that the second copy profile (“CUP2”) was withdrawn from the staging deployment environment112c, corresponding to the update profile (“AUP1”).

FIG. 9is an example data table900representing local update profile promotions that may be stored by the example profile promoter146when an update profile is accepted and/or applied to a deployment environment. The example data table900identifies an entry identifier902, a local update identifier904, a promote identifier906and a deployment identifier908. For example, rows910and912ofFIG. 9indicate that during a first promotion, the master copy was accepted and/or applied in a first deployment environment (“D1”) and a second deployment environment (“D2”). Rows910and912also indicate that first and second local copies of a promoted update profile (“LUP1” and “LUP2”) were made in the first deployment environment (“D1”) and the second deployment environment (“D2”), respectively. Row914indicates that the second promotion was accepted and/or applied in a third deployment environment (“D3”) and that a third local copy of a promoted update profile (“LUP3”) was made in the third deployment environment (“D3”).

Flowcharts representative of example machine readable instructions for implementing the profile promotion handler124ofFIG. 1are shown inFIGS. 10 and 11. In this example, the machine readable instructions comprise a program for execution by a processor such as the processor1212shown in the example processor platform1200discussed below in connection withFIG. 12. The program may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Bin-ray disk, or a memory associated with the processor1212, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor1212and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowcharts illustrated inFIGS. 10 and 11, many other methods of implementing the example profile promotion handler124may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

The example program ofFIG. 10begins at block1002at which the example profile promotion handler124(FIG. 1) displays the user-selectable ‘Manage Update Promotion’ control304in the example profile promoter GUI300(FIG. 3). At block1004, the example profile promoter146(FIG. 1) determines whether the ‘Manage Update Promotion’ control304has been selected. If, at block1004, the example profile promoter146determines that the ‘Manage Update Promotion’ control304has not been selected, then control returns to block1002to display the user-selectable ‘Manage Update Promotion’ control304. At block1006, the example profile promoter146displays the user-selectable deployment environments available to promote the update profile140and the user-selectable update promotion ‘Submit’ control414in the example profile promoter GUI400. At block1008, the example profile promoter146determines whether the update promotion ‘Submit’ control414has been selected. If, at block1008, the example profile promoter146determines that the update promotion ‘Submit’ control414has not been selected, then control proceeds to block1022to determine whether there is another update profile available to manage.

If at block1008, the example profile promoter146determines the update promotion ‘Submit’ control414has been selected, then, at block1010, the profile promoter146stores an example master copy142of the promoted update profile140. At block1012, the example profile promoter146logs the promotion of the update profile140in the example promotion repository144(FIG. 1). For example, the profile promoter146may record entries in a data structure (e.g., the example data table720ofFIG. 7B, the example data table810ofFIG. 8B) identifying the source update profile (e.g., the update profile promoted), identifying a copy identifier of the master copy, and identifying the ones of the deployment environments112selected for applying the promoted update profile140(e.g., the listing of selected deployment environments408ofFIG. 4). At block1014, the example profile promoter146notifies the selected ones of the deployment environments408of the promoted update profile140. At block1016, the example profile promoter146determines whether a local copy of the update profile140is made at the selected ones of the deployment environments408. For example, the profile promoter146may obtain a message indicating whether the update profile140was reviewed, accepted and applied or rejected at the selected ones of the deployment environments408. If, at block1016, the example profile promoter146determines that the selected ones of the deployment environments408created a local copy of the update profile140(e.g., the administrator108of the selected ones of the deployment environments408selected to review, accept or apply the update profile140), then, at block1018, the profile promoter146logs the local update profile promotion in a data structure (e.g., the example data table900ofFIG. 9) in the example promotion repository144.

If, at block1016, the example profile promoter146determines that a local copy of the update profile140was not made at the selected ones of the deployment environments408or the profile promoter146has logged the local update profile promotion in a data structure at block1018, then, at block1020, the profile promoter146determines whether there is another selected deployment environment408to notify of the promoted update profile140. If, at block1020, the profile promoter146determines that there is another selected deployment environment408to notify, control returns to block1014to notify the selected ones of the deployment environments408of the promoted update profile140. If at block1008, the profile promoter146determines that the update promotion ‘Submit’ control has not been selected (e.g., a user has selected the ‘Cancel’ control416ofFIG. 4) or the profile promoter146has determined that there is not another selected deployment environment408to notify at block1020, then, at block1022, the profile promoter146determines whether there is another update profile to manage. For example, the profile promoter GUI300may display another update profile with the user-selectable ‘Manage Update Promotion’ control304. If, at block1022, the profile promoter146determines that the there is another update profile to manage, then, control returns to block1004to determine whether the ‘Manage Update Promotion’ control304has been selected fir another update profile. Otherwise, if, at block1022, the profile promoter146determines there is not another update profile to manage, the example process1000ofFIG. 10then ends.

The example program ofFIG. 11begins at block1102when the profile promotion handler124(FIG. 1) displays the user-selectable ‘Notification’ control504in the example promotion deployer GUI500ofFIG. 5. For example, the promotion deployer148(FIG. 1) of a deployment environment may obtain a notification of a promoted update profile for an application deployed in the deployment environment.

At block1104, the example promotion deployer148determines whether the ‘Notification’ control504is selected. For example, using the example human interface device pointer506(FIG. 5), the administrator108may select the ‘Notification’ control504to review the example update profile503included in the list of deployments502.

If, at block1104, the example profile deployer148determines that the ‘Notification’ control504is not selected, then control returns to block1102to display the example promotion deployer GUI500ofFIG. 5.

If, at block1104, the example profile deployer148determines that the ‘Notification’ control504is selected (e.g., a user wishes to review the update profile), then, at block1106, the example profile deployer148displays additional information about the update profile (e.g., the example update profile identified in profile label602ofFIG. 6), the example ‘Accept and Apply Update’ control604and the example ‘Reject’ control608in the example promotion deployer GUI600ofFIG. 6. For example, the additional information about the update profile identified in profile label602may include the creator identified at creator label603(FIG. 6). Using the example human interface device pointer606, a user may then select the ‘Accept and Apply Update’ control604to accept and apply the update profile identified in profile label602, or may select the ‘Reject’ control608to reject applying the update profile identified in profile label602. In some examples, the promotion deployer GUI600may include a user-selectable control to enable the administrator108to accept the update profile identified in profile label602and modify the update profile identified in profile label602locally (e.g., at the deployment environment) prior to applying the update profile identified in profile label602and/or the modified update profile identified in profile label602.

At block1108, the example promotion deployer148determines whether the administrator108selected the ‘Accept and Apply Update’ control604. If, at block1108, the example promotion deployer148determines that the administrator108did not select the ‘Accept and Apply Update’ control604(e.g., the administrator108selected the ‘Reject’ control608), then control proceeds to block1120to determine whether there is another promoted update profile to review, accept and apply or reject.

If, at block1108, the example promotion deployer148determines that the administrator108selected the ‘Accept and Apply Update’ control604, then, at block1110, the promotion deployer148stores a local copy of the update profile identified in profile label602at the deployment environment. For example, the promotion deployer148may obtain a copy of the promoted update profile identified in profile label602from the example profile promoter146(FIG. 1) and store a copy of the promoted update profile identified in profile label602in a local repository (e.g., the example promotion repository144(FIG. 1)).

At block1112, the example promotion deployer148notifies the example profile promoter146that a local copy of the promoted update profile identified in profile label602was created and stored in the deployment environment.

At block1114, the promotion deployer148performs a compatibility check between the deployment environment (e.g., the deployed application, the virtual machines included in the deployment environment, etc.) and the update profile identified in profile label602. For example, the promotion deployer148may check whether the virtual machines114(FIG. 1) deployed in the deployment environment are able to execute the components of the update profile identified in profile label602. If, at block1116, the promotion deployer148determines that the deployment environment is compatible with the update profile identified in profile label602, then, at block1118, the promotion deployer148applies the update profile identified profile label602to the deployed application (e.g., all of the instances of the application deployed in the deployment environment).

If, at block1116, the promotion deployer148determines that the deployment environment is not compatible with the update profile identified in profile label602, or after the promotion deployer148applies the update profile identified in profile label602at block1118, then, at block1120, the promotion deployer148determines whether there is another promoted update profile to review, accept and apply or reject. If, at block1120, the promotion deployer148determines that there is another promoted update profile, control returns to block1102to display the promotion deployer GUI500ofFIG. 5including the user-selectable ‘Notification’ control504for the promoted update profile. Otherwise, if at block1120, the promotion deployer148determines there is not another promoted update profile, the example process1100ofFIG. 11then ends.

FIG. 12is a block diagram of an example processor platform1200capable of executing the instructions ofFIGS. 10 and 11to implement the profile promotion handler124ofFIG. 1. The processor platform1200can be, for example a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, or any other type of computing device.

The processor platform1200of the illustrated example includes a processor1212. The processor1212of the illustrated example is hardware. For example, the processor1212can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.

The processor1212of the illustrated example includes a local memory1213(e.g., a cache). The processor1212of the illustrated example is in communication with a main memory including a volatile memory1214and a non-volatile memory1216via a bus1218. The volatile memory1214may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory1216may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory1214,1216is controlled by a memory controller.

The processor platform1200of the illustrated example also includes an interface circuit1220. The interface circuit1220may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices1222are connected to the interface circuit1220. The input device(s)1222permit(s) a user to enter data and commands into the processor1212. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

The processor platform1200of the illustrated example also includes one or more mass storage devices1228for storing software and/or data. Examples of such mass storage devices1228include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The coded instructions1232ofFIGS. 10 and 11may be stored in the mass storage device1228, in the volatile memory1214, in the non-volatile memory1216, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that the above disclosed methods, apparatus and articles of manufacture update application deployments in cloud computing environments, while enabling administrators of the cloud computing environments an opportunity to reject the update. Disclosed examples update deployed applications within a deployment environment. An update may additionally be promoted to other deployment environments. Accordingly, examples disclosed herein facilitate updating large numbers of application deployments within a cloud computing environment in an efficient and synchronized manner.