Network application versioning

A system and method for managing application version changes on a network server. A backup is made of a deployed application version. When an update version of the application is to be deployed, a backup of the current application, including dynamic data, is performed. The update version is deployed and automatically monitored. If the update version is determined to be healthy, it is backed up. If it is determined to not be healthy, the previous version is automatically retrieved and deployed. An application skeleton may be automatically generated to facilitate comparison and backups of the application.

TECHNICAL FIELD

The present invention relates generally to computer systems, and, more particularly, to managing deployment of network applications.

BACKGROUND

A network server, such as a Web server, typically includes one or more network applications that provide services to remote users by way of a request and response mechanism. The requests may include requests for web pages, files, or various data. They may also include requests to store data, process data, facilitate e-commerce, or provide various other services. A network server may provide many of the functions required to implement a Web site or network service.

A network application may go through numerous versions in its lifetime. Typically, one or more developers create an update version of an application and the application is tested. If the application passes testing, it may then be installed on a network server. Installing an application may be a complex process, due to the many components and types of components that may be involved. In addition to code files, installing an application may include installing certificates, creating or changing system registry entries, and configuring a database, as well as installing or changing other content.

In some situations, a problem with a network application may not be discovered until after it is installed and begins running “live.” This may be due to inadequate testing, interaction with other components or a different configuration in the network server, or for other reasons. In some situations, an administrator may not become aware of the problem until after a lengthy period of time. The administrator may then attempt to restore the application by using backup files, manually changing some components or data, or other actions. In some situations, the problem version may have caused changes that are difficult to determine.

SUMMARY

Briefly, a system, method, and components operate to manage application version changes on a network server. The system performs a backup of a first version of a network application. In response to receiving an update version of the application, the system automatically performs a backup of the current network application, including dynamic data that may have changed since the prior backup, and automatically deploys the update version. After deploying the update version, a monitoring component automatically monitors the application to determine whether the application is healthy. If it is, the application is backed up. If it is not healthy, the previous version backup is retrieved and deployed. An application skeleton may be automatically generated to facilitate comparison and backups of the application.

In one aspect of the system, generating the skeleton includes determining a set of components of the network application, and the backup of the first version, as well as other versions, of the network application, is performed based on the determined set of components. The set of components may include static content and dynamic content, both of which may be backed up.

In one aspect of the system, generating the skeleton includes analyzing the network application to determine a set of dynamic components. This may be performed by extracting one or more database access commands, data fields, or other data references from the application. In one aspect of the system, the skeleton may be supplemented based on one or more update versions of the application.

In one aspect of the system, a user may provide a compare module that is used to perform comparisons of an application version with another version of the application. The user-defined compare module may specify a granularity of an application component and perform a comparison based on the granularity specification. A backup may be based on the granularity specification.

In one aspect of the system, a monitoring component monitors communications of the application and determines whether the application responses and actions are compliant with one or more specified criteria. The criteria may indicate an acceptable number of error messages of specified types, an acceptable time to respond, or other criteria. In one aspect of the system, a monitoring component performs active probing of the network application by sending one or more network requests, and monitors the application responses and actions. A user-defined monitor may be used to perform all or some of the actions of the monitoring component.

DETAILED DESCRIPTION

Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. Furthermore, the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment, although it may. Thus, as described below, various embodiments of the invention may be readily combined, without departing from the scope or spirit of the invention. Similarly, the phrase “in one implementation” as used herein does not necessarily refer to the same implementation, though it may, and techniques of various implementations may be combined.

As used herein, the term “user-defined” component refers to a component that is provided, configured, or developed by an application or system developer, administrator, content provider, or other entity to supplement the system. A user-defined component may supplement or replace a corresponding component of the system.

The components described herein may execute from various computer-readable media having various data structures thereon. The components may communicate via local or remote processes such as in accordance with a signal having one or more data packets (e.g. data from one component interacting with another component in a local system, distributed system, or across a network such as the Internet with other systems via the signal). Computer components may be stored, for example, on computer-readable media including, but not limited to, an application specific integrated circuit (ASIC), compact disk (CD), digital versatile disk (DVD), read only memory (ROM), floppy disk, hard disk, electrically erasable programmable read only memory (EEPROM), flash memory, or a memory stick in accordance with embodiments of the present invention.

FIG. 1is a block diagram of a computer network environment100in which mechanisms described herein may be implemented.FIG. 1is only an example of a suitable environment and is not intended to suggest any limitation as to the scope of use or functionality of the present invention. Thus, a variety of system configurations may be employed without departing from the scope or spirit of the present invention.

As illustrated, environment100includes data center101, which itself includes server102and database104. Data center101may include one or more servers that may be collocated or geographically distributed, though only one network server102is illustrated. Server102is a computing device having one or more processing units and associated components. Server102may include applications that provide services to remote clients or other servers.

As illustrated, data center101includes database104. Database104may be used to store and retrieve data used by server102. The data may include data pertaining to remote users, such as customer information. It may include data pertaining to a web site, business, or other entity. For example, database104may include a product catalog, a catalog of courses, maps, or any other data to be stored or accessed by data center101. Database104may reside on a single computing device or be distributed among multiple computing devices.

Data center101may include additional computing devices, such as data storage devices, switches, routers, firewalls, or the like. Multiple servers102may be in direct or indirect communication with each other. Each server102may have a corresponding database104, or multiple servers may share database104.

As illustrated, network environment100includes development device106. Development device106may be used by an application developer, web site developer, administrator, content provider, or other user who provides or maintains content such as applications or data for use by server102. In various configurations, development device106may be located within data center101or it may be external to it. Development device106may communicate directly or indirectly with server102via a direct connection, a local area network, a wide area network such as network108, a manual transfer of computer-readable media, or any other communications mechanism.

Server102may communicate with remote devices by way of a network108. Network108may include a local area network, a wide area network, or a combination thereof. In one embodiment, network108includes the Internet, which is a network of networks. Network108may include wired communication mechanisms, wireless communication mechanisms, or a combination thereof. Communications between server102and any other computing devices may employ one or more of various wired or wireless communication protocols, such as IP, TCP/IP, UDP, HTTP, SSL, TLS, FTP, SMTP, WAP, Bluetooth, WLAN, or the like.

Environment100may include any number of client devices110that communicate with server102. Client device110may be any computing device, including another network server that communicates with server102. Server102may provide services to client devices110. Services may include actions such as returning a web page or file, setting up an account, or access to various data.

FIG. 2illustrates a computing system200that may be employed with the mechanisms described herein. Computing system200includes a server202, which may be server102ofFIG. 1. Server202may be a web server, application server, or other server that provides services to remote users. Server202may refer to software that executes on one or more computing devices, electronic components that include program logic, a computing device, or a combination thereof. A computing device may be a special purpose or general purpose computing device. In brief, one embodiment of a computing device that may be employed includes one or more processing units, a mass memory, and a communications interface. Example computing devices include mainframes, servers, blade servers, personal computers, portable computers, communication devices, consumer electronics, or the like.

As illustrated, computing system200includes development system204. Development system204may include one or more development devices, such as development device106ofFIG. 1. In some configurations, development system204may include a test server, staging server, source code repository, or various development tools.

As illustrated, server202communicates with application database210. Application database210may be integrated with server202, reside on the same computing device, or it may reside on one or more separate computing devices. Application database210may be shared by multiple servers202. Application database210may include data storage media, user data, and program logic for accessing data. Application database210may include a structured database or unstructured data such as a file.

As illustrated, server202includes several components. Briefly, operating system232may be any general or special purpose operating system. The Windows® family of operating systems, by Microsoft Corporation, of Redmond, Wash., are examples of operating systems that may execute on server202.

As illustrated, server202further includes one or more applications208. Applications208may include one or more programs or program components that provide one or more of a variety of services as discussed herein, such as Internet or application services. As illustrated by arrow209, application208may communicate, directly or indirectly, with remote devices, such as remote devices110ofFIG. 1, via a network, such as network108. Though not illustrated, server102may include one or more protocol modules that facilitate communicating with one or more communication protocols, such as HTTP, FTP, SMTP, WAP, or the like.

As illustrated, server202includes deployment services component206. Deployment services component206may receive a version of an application or application components, and deploy it onto server202. As used herein, the term “application” refers to a computer program or a computer program and associated data. An application is made up of any combination of application components, which may include program instructions, data, text, object code, images or other media, security certificates, scripts, or other software components that may be installed on a computing device to enable the device to perform desired functions. Application components may exist in the form of files, libraries, pages, binary blocks, or streams of data. Application components may be distributed in various locations, and may be integrated with components of other applications or of the computer system. Examples of application components include object files, libraries, COM objects, code assemblies, global assembly cache components, markup language pages or templates, system registry entries, entries in configuration or system files, or the like. Components of an application are also referred to as application “content.” Application content may be static or dynamic. Generally, static content is content that may be changed by deployment of new versions of the content or by configuration of the application. Dynamic content refers to content that is changed during execution of the application. Some dynamic content may be changed by deployment of a new version of the content as well as by execution of the application.

Examples of applications include an application that implements a web site by providing web pages, scripts, media, or data. Other examples of applications include search engines, mapping programs, mail programs, e-commerce applications, or the like. Deploying an application may include creating directory structures, copying one or more files into the correct locations, entering or modifying data in a system registry or database, modifying the contents of one or more files, executing scripts, or other actions to facilitate execution of the application.

Deployment services component202may also receive a version of an application from backup/restore component216and use the received version to revert an application to a previous state. This may occur, for example, if a problem is discovered with an executing application. Deployment services component206may retrieve a prior version of the application and restore the application to the prior version. This process is discussed in further detail herein.

Backup/restore component216may be used to back up versions of applications208. As illustrated, backup/restore component216includes skeleton generator218. In one implementation, skeleton generator218may examine application208, including all of its component parts, and generate a skeleton of the various subcomponents. A skeleton is a set of data that identifies the components of an application. The skeleton may include a list of files or data together with the corresponding location or access mechanism for each subcomponent. For example, a file may have a corresponding path to access the file. A registry key may have a key name that identifies a data value and is used to access the data value. Identifying data may include a universal resource identifier, a data access command, or other type of identifier. Skeleton generator218may retrieve data to generate the skeleton from multiple sources. The skeleton generator may retrieve data that is sent from the development system204to deployment services component206, the data indicating application components. In one implementation, skeleton generator218may analyze program code that is sent with an application version to extract references to data, such as registry keys, database fields, configuration file entries, or the like. A database access command, such as a connection string, may be extracted, indicating data referenced by the application, where the data is located, or mechanisms for accessing the data. Program code may include static declarations that indicate data references. Program code may also include references to data objects that are not included in static declarations. Any one or combination of these may be retrieved by the skeleton generator218to generate a skeleton.

After generating an initial skeleton, in response to receipt of a subsequent application version by deployment services component206, skeleton generator218may perform additional analysis such as described above to determine additional items to supplement the skeleton. In one configuration, a user-defined skeleton generator220may be used in conjunction with, or instead of, skeleton generator218to perform the actions of skeleton generator218, or a portion thereof. User-defined skeleton generator220may include logic to customize the actions of generating a skeleton for application208. This may include logic to identify or locate type definitions, data structures, data access commands, data fields, or the like.

In one implementation, backup/restore component216may use a skeleton generated by skeleton generator218to identify and retrieve the subcomponents of applications208. The subcomponents may be stored in repository230. Repository230may store one or more versions of each subcomponent or the application in its entirety in any of a variety of ways. For example, an incremental backup may include changes since a previous backup, while a complete backup may include the entire application. Though skeleton generator218is illustrated as a component of backup/restore component216, in some configurations, it may be a separate component. Repository230may reside on one or more computing devices distinct from server202. In one configuration, repository230, or a portion thereof, may reside on server202.

As illustrated, server202may include smart compare module212. Smart compare module212may be used to perform a comparison between two different versions or states of an application, generating data describing the differences. The smart compare module212may be configured by specifying a granularity to use when performing a comparison. For example, in one configuration, the difference data may indicate files that are different in the compared versions. In another configuration, the difference data may indicate specific lines or words of a file that are different, or it may include the differences. In one implementation, the difference data may include data that is sufficient to transform one of the compared versions to be equivalent to the other compared version.

In one implementation, smart compare module212may include logic that indicates the files or data to examine for differences. It may also include logic or data that facilitates accessing the application. For example, the smart compare module212may include logic to examine certain registry keys, database fields, a database schema, certificates, or various other components of applications208. The examined content may include static content or dynamic content such as database entries. In one implementation, smart compare module212may include one or more user-defined compare modules214with additional logic corresponding to one or more of applications208. In one implementation, a developer or administrator of applications208may provide user-defined compare module214to facilitate the operation of smart compare module212. A user-defined compare module214may include program logic that identifies one or more structures, type definitions, or properties of a file, data field, or other application component. This logic may be used to perform a comparison based on knowledge of the specific content. For example, the program logic may identify content as including a string that is case-insensitive, enabling a case-insensitive comparison to be performed. The user-defined compare module214may also include logic to specify a granularity to use when performing comparisons. The user-defined compare module214may include program logic to perform a comparison, or instructions to enable the smart compare module212to perform a comparison. In some implementations, the smart compare module212may perform a byte-level comparison of a file's contents or metadata, without employing specific knowledge of the file type or structure.

In one implementation, backup/restore component216may use the comparison data generated by smart compare module212to perform an incremental backup of application208. Based on a configuration, an incremental backup may include files that are changed or data within files that are changed. In one configuration, backup/restore component216may perform a complete backup of application208, including portions that have not changed.

As illustrated, server202may include health monitor224. Health monitor224may automatically perform various actions to determine whether an application is “healthy.” The actions and criteria for determining an application's health may be implemented in a variety of ways. For example, in one configuration, health monitor224may monitor communications between application208or server202and a remote device and determine whether the communications or results are compliant with specified criteria. Monitoring may include examining whether responses by application208or server202are successful or not, as well as the type of error messages returned. Some errors may indicate that the application is not properly functioning due to program or data errors. Some errors may indicate that the application is properly functioning. A configuration may specify an acceptable rate of errors for various types of errors. A configuration may also specify an amount of time or a number of transactions to monitor. For example, one configuration may specify that two or more high priority errors occurring within the first 100 transactions is considered unhealthy, and that 100 transactions with less than two such errors is considered healthy. One type of health criteria may specify an acceptable response time, based on an average, a maximum, or other statistical analysis. Health monitor224may be configured with one or more criteria for determining health.

In one implementation, health monitor224may be configured to actively probe server202or application208. For example, health monitor224may send specified types of requests or messages to server202, and examine the responses as described above. A configuration may include data indicating responses that are expected based on specified data. For example, in one configuration, health monitor224may send a request for data and verify that the expected data is received, or is received within a specified period of time. In another example, health monitor may perform a login of the application and expect a successful response within a specified response time. In one configuration, health monitor224may be configured with specifications of responses that may be inconsistent, indicating that the application is not healthy. In one implementation, health monitor224may directly or indirectly query the application database to examine and analyze data. For example, after the application receives N requests to create new records, and the application has returned N success status values, health monitor224may query the application database to determine whether there are N new records or to otherwise verify that the requests have been handled properly.

In one configuration, one or more user-defined health monitors226may be integrated or employed with health monitor224. User-defined health monitor226may include logic that is specifically designed to monitor one or more applications208. User-defined health monitor226may be provided by a developer or administrator of applications208. User-defined health monitor226may employ any of the monitoring techniques discussed with respect to health monitor224, or other techniques. Typically, user-defined health monitor224includes logic that is customized to the application, and may perform more application-specific monitoring. In one configuration, a user-defined health monitor224may be deployed as a component of application208and may be updated along with application revisions. Health monitor224may include an API that enables a user-defined health monitor226to perform monitoring functions and report results to health monitor224.

In one implementation, in response to an application208being updated by the deployment of an update version, health monitor226may automatically monitor the executing application. If the application is determined to be unhealthy, backup/restore component may automatically restore a previous version of the application. Further details of the operation of the components ofFIG. 2are described inFIG. 3and elsewhere herein.

In one implementation, deployment services206may perform actions to initiate, control, or synchronize the actions of the various components ofFIG. 2, or the actions of process300ofFIG. 3, or a portion thereof. In some implementations, another component may perform control actions, or each component may initiate actions in direct response to another component. As used herein, description of performing an action “in response’ to a triggering event includes such action regardless of the controlling component.

FIG. 2also illustrates timer234. In one implementation, timer234may be used to trigger a backup of a current application version at a specified time interval.

As illustrated inFIG. 2, the various components discussed herein reside on server202. In various configurations, one or more of these components may reside on a separate computing device or be combined, divided, duplicated, or otherwise distributed among multiple computing devices.

FIG. 3is a flow diagram illustrating a process300for deploying an application, in accordance with an embodiment of the invention. Process300may be performed in conjunction with process400ofFIG. 4, as described herein. Process300may be employed by a server, such as server202ofFIG. 2, or by another computing device. Process300may be employed in environment100ofFIG. 1, or in another computing environment.

As used herein, a version of an application may refer to an application, or any subset of one or more components of application, in which any of the components may be a variation of a previous version of the component. A version may include components that are the same or a variation of a previous version. A revised version of a component may be deployed to an application, causing the entire application to be considered a new version. For illustrative purposes, components of an application are assigned a version number when they differ from a previous version, and an application is labeled by the version number of its most recently changed or added component. For example, when an application version1(V1) receives a component that is labeled version2(V2), the application is labeled as version2(V2). Similarly, an application may be labeled with a version number to indicate the current state of its static and dynamic components, even though a new component version has not been installed. For example, an application version1that has been executing for a time may be considered to be application version1.1and may have dynamic data that differs from the time of the most recent deployment. A version of an application may, but does not necessarily contain differences from a previous version. There exist many ways to label versions of an application or its components. The labels used herein are to assist in description, and are not intended to limit the invention. Further, a label of first version (V1) is used to identify and distinguish a version, and does not necessarily indicate that there have not been prior versions.

As shown inFIG. 3, after a start block, at block302, a first version (V1) of an application is received. In one configuration, application V1may be received from development system204ofFIG. 2or another application content provider. Application V1may be received by deployment services component206.

Process300may flow to block304, where, in response to receiving V1of the application, V1of the application may be deployed. The actions of block304may include one or more of: moving or copying files into a designated location; setting keyword-value pairs in a registry; setting or modifying data in various system files, structures, or objects; translating or processing application components; invoking various system functions; or other deployment actions as part of an installation or configuration of the application.

Process300may flow to block306, where a skeleton of the application V1may be generated. As discussed herein, a skeleton may include data corresponding to each component that indicates a location of the component, a keyword, command, or other mechanism for accessing or modifying the component. The actions of block306may include analyzing the program code or other components of application V1to retrieve component references and using the retrieved references to generate the skeleton.

Generating a skeleton may include examining the various components of the application, as well as links or references to other components. An application may include data, such as a skeleton, that is used by a skeleton generator. In one configuration, skeleton generator218may perform some or all of the actions of block306.

Process300may flow to block308, where a backup of the application V1may be performed, based on the skeleton. In one configuration, backup/restore component216may perform some or all of the actions of block308. In one configuration, the actions of block308may include copying the application components to repository230. In one implementation, if a previous backup of the application has been performed, the backup of the application V1may be an incremental backup or a complete backup.

In one embodiment, each of the actions of process300may be triggered and performed automatically, so that manual intervention is not required. In one implementation, in response to receipt of the application V1, deployment of the application may be automatically performed. In response to deployment of the application V1, generation of the skeleton and the backup of the application V1may be automatically performed. In one embodiment, deployment of the application V1, as shown in block304, may occur after or concurrently with performing the backup of application V1, as shown in block308.

Process300may then flow into process400ofFIG. 4.FIG. 4is a flow diagram illustrating a process400for deploying an application, in accordance with an embodiment of the invention. Process400may be performed by server202ofFIG. 2, or by another computing device. Process400may be employed in environment100ofFIG. 1, or in another computing environment.

Process400may occur after process300has been performed. In one situation, process400may be performed after application V1has executed for some period of time, which may be any time period from seconds to years.

As illustrated, after performing process300, at block402, an application V2, or a portion thereof, is received for deployment. As used herein, the term “application portion” refers to an entire application or any portion thereof. Application V2may be referred to as “update application” V2, in that it is to be deployed to update a prior version. Similarly, the term “update application portion” refers to the portion of the application that is received for deployment. Update application portion V2may be received from development system204ofFIG. 2, from another development system, or from another content provider. Application portion V2may be received by deployment services component206.

Process400may flow to block404where, in response to receipt of application portion V2, the current version of the application may be compared with the previously backed up application version V1. The current version is the version that is currently installed. It is labeled as application V1.1for illustrative purposes. Application V1.1may be a version that differs from application V1due to dynamic data that has been created or modified since deployment of application V1. In some environments, differences may include static content. The actions of block404may result in data descriptive of the differences between application V1and application V1.1. In various implementations or configurations, the granularity of the difference data may vary. For example, in one configuration, the difference data may indicate files that differ; in another configuration, the difference data may indicate fields or portions within a file that differ. Similarly, the granularity of database difference specifications may differ. This may include specification of whether a database schema is to be compared, or whether the content of database fields is to be compared.

Process400may flow to block406, where a backup of the current application V1.1is performed. Depending on a configuration, the backup may be an incremental backup based on the determined differences, or it may be a complete backup. Thus, in some implementations, the comparison of block404may be skipped. In some configurations, the granularity of an incremental backup may differ from the granularity of the differences determined at block404. In one implementation, actions of block406may include copying the application components to repository230.

Process400may flow to block408, where a temporary backup of application V2may be performed. The backup is considered temporary because it is not yet known whether the application V2is a successful version. However, if the version is considered successful, this backup may later be converted into a permanent backup version. It is to be noted that, though block408is illustrated prior to block410, some or all of the actions of deploying the application V2as described for block410may be performed prior to, or in conjunction with, performing the backup of block408.

Process400may flow to block410, where the application V2is deployed. The deployment of application V2may include any of the actions described above for the deployment of application V1at block304, though they are not necessarily the same. For example, the deployment of application V1may include creating an entry in a structure, and the deployment of application V2may include changing or deleting the same entry. The actions of block410may include employing the deployed application as a “live” application.

Process400may flow to block412, where, in response to deploying application V2, monitoring of the current application (now V2) may be automatically performed. In one implementation, monitoring of the current application (V2) may be performed by health monitor224. User-defined health monitor226may perform some or all of the monitoring tasks.

As described herein, monitoring the current application may include monitoring communications between the current application and remote devices. This may include examining status or other return values, such as HTTP status values, or status values of other network protocols. The actions of monitoring may include examining data other than communications with remote devices, such as logged data, records in a database, the creation or deletion of files, files with dynamic data, or other effects of the execution of application V2. In one implementation, the actions of monitoring may include performing one or more probing actions, such as sending a request or command to the application V2, and examining the result. In one implementation, monitoring may include timing behaviors or events, to determine whether the application is functioning within specified constraints. For example, one such behavior that might be timed is the amount of time between receiving a network request and sending a response.

The process may flow to block414, where a determination is made of the health of the current application (V2), based on the actions of block412and specified criteria. The criteria may include a number or rate of errors or other type of status values, a maximum allowable time to perform certain actions, expected responses to requests by remote devices or from monitor probes, expected database values, file configurations, or the like.

The process may flow to decision block416, where the process flow may be based on the determination of block414, and specifically, whether the application is considered to be healthy. If the application is considered to be healthy, the process may flow to block418. In one implementation, at block418, a previously generated skeleton corresponding to the application may be supplemented by performing additional analysis, as described herein, of program code or other components of the application V2. Also at block418, in response to determining that the application is healthy, the temporary backup of the application V2, as discussed at block408, may be converted to a permanent backup. After the actions of block418, the system may be in a state similar to the state prior to process400, as described. Another application version (V3) may be received, and process400may be repeated with the backed up application V2, or a subsequent variation (V2.1), being the base application for the new application version V3.

If, at decision block416, it is determined that the application is not healthy, the process may flow to block420, where, in response to determining that the application is not healthy, an intervention may be performed. In one implementation, as part of the intervention, the previously backed up application version V1.1may be automatically retrieved and deployed. The temporary backup of the application V2, as discussed at block408, may be discarded. In one implementation, the intervention may include sending a status message to an administrator. This may be sent by email, text message, or any other communication mechanism. In one implementation, instead of automatically reverting to the backed up application version V1.1, a status message is sent and an administrator may manually elect to revert to a backed up application version.

In one embodiment, each of the actions, though not necessarily all of the actions, of process400may be automatically triggered and performed, so that manual intervention is not required. In one implementation, in response to receipt of the application V2, a backup of the current application V1.1may be automatically performed. The deployment of application V2may be automatically performed in response to receiving the application V2. Monitoring the current application V2and determining the health of the current application may be automatically performed in response to deployment of the application V2. Retrieving and deploying the previous application V1.1may be automatically performed in response to determining that the application V2is not healthy, and a backup of the current application V2may be performed in response to determining that the application is healthy.

It is to be noted that the health of an application does not necessarily indicate that the application is bad or the cause of a problem. In some configurations, a problem with other software or hardware on the server may be triggered by the application, resulting in a determination of unhealthy.

It will be understood that each block of the flowchart illustrations ofFIGS. 3 and 4and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These program instructions may be provided to a parallel processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in the flowchart block or blocks. The computer program instructions may be executed by a parallel processor to cause a series of operational steps to be performed by the processor to produce a computer implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified in the flowchart block or blocks. The computer program instructions may also cause at least some of the operational steps shown in the blocks of the flowchart to be performed in parallel. In addition, one or more blocks or combinations of blocks in the flowchart illustrations may also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the invention.