GB2516009A - Automated software deployment management - Google Patents

Abstract

An automated software deployment management system for the distribution of software objects/updates from one server to another server. The servers may sit on the same network or on separate networks. The system comprising a process to receive and store code for managing the software deployment, a process to schedule instructions for remote machines, a process for communication instructions to and from remote machines, a process for remote machines to download prerequisites, a process for the remote machines to process said software and log data relating to said process. The installation of software objects/updates on remote machines can be scheduled for immediate action or for a later time and date, for one or more machines. If an error occurs the installation process can be stopped, the system may also instruct the remote machines to complete various tasks e.g. reboot or delete log files. The system will optionally perform backups of the application and all data it is replacing if required. The performance and health of the remote machine(s) may be monitored by the deployment management system.

Description

DEscmPToN This nventwn reates to an automated software depovment management system In some computer environments, applications are hosted remotely from where the end user is located. When there are new versions, updates) patches, or changes of this software available, the software hosted at each of the servers hosting the application will need to be updated. The updating of these servers manually is time consuming, is usually complex, requires significant resources, and is very error prone.

Additionally, some of these components may rely on other components sitting on the same infrastructure, these components will all have to be updated at the same time, without bringing the entire system down.

These components may have to be updated in a certain order, to ensure that there are no errors while attempting to update or install the application, as the application's components have interdependencies.

Furthermore, if there are problems encountered on multiple servers, aggregating all the log files and attempting to analyse them is usually problematic.

To overcome these issues, this invention proposes automating and managing the software deployment to these systems, in order to speed up the deployment, to require fewer resources, and to drastically reduce the number of errors.

The Deployment Management Service (DMS) typically sits on its own server, but can sit on the same server to which it is publishing (called the client server). These systems should be able to communicate with each other, either over Local Area Network (LAN), Wide Area Networks (WAN), or over the Internet. The Deployment Management Service can sit on the same network as the client servers, or on separate networks, as long as there is a valid communications channel or link between them.

It should be noted that the steps below are not required to be performed in a specific order. Any of the steps below can be skipped, and the whole process can be abandoned at any point if the user wishes. The Deployment Management Service will come with workflow already provided, and the user can add, edit or remove any steps in the workflow as required. A workflow includes computer-executable code, for managing the deployment and other processes, and can include if-then-else statements, loops, references and other scripts or steps that are required to complete the deployment. In some situations for example the full and successful completion of one workflow is required before starting another, but not in all situations.

The Deployment Management Service can typically manage the deployment of code from two starting points: receiving human readable code (101), or receiving machine readable code (201). when human readable code is received (101), the Deployment Management Service will compile the code from human readable code to machine readable code (105), then the worlcflow for receiving machine readable code will be executed (201).

If the DM5 receives human readable code, and there is a configuration already set up, then the DM5 will build only the applications that are set up to be deployed through the DM5 (104).

when the DMS receives the machine readable code (201). additional information should be passed to it with the files, but this is not required for all cases. This additional information details which project this code refers to, as the DMS can manage deployments for multiple projects across multiple servers, in multiple geographic locations. There may be additional information, regarding the software version numbers, the authors, the change log (a list of all changes that were performed on the code), but again this is not necessarily required (206). The machine readable code may be compressed in a single file (203), containing multiple projects that require deployment, or the files may arrive singularly (205). The files received may include installation scripts, programs or executables, or they may just be the application files. The files also may contain environment specific configuration instructions (206).

Once the DM5 receives the machine readable code (be it over TCP or UDP connection, HTTP/HTTPS transfer, FTP, FHe Copy, or other methods), then the DM5 will communicate with the File Storage module (204), located typically in the DMS but potentially external to it, and store the machine readable code there, typically compressed in a single file (203), but it also may be stored singularly (205). The File Storage module may store the data locally on the same computer, on a different computer, on a virtual computer, or on another storage medium such as removable hard drives, flash drives, CD ROM drives, remote storage locations or cloud storage. Once this file is successfully uploaded, the user can elect to receive an optional email or other form of notification confirming that the file has been received successfully (207).

If the user has set it up before-hand, this deployment can be performed automatically once a file has been received in the File Storage module (301, 302). Otherwise, the user will login to the DMS (401), and choose which server or servers they wish to deploy this application to (402), and then schedule the deployment (404).

Optionally, the user can go to File Storage module (403), and choose to publish it to a server from this route (405). The user can also elect to publish the machine readable code from one DMS to another DMS (407), located in another location, such as a separate geographical region.

If the user has provided an installation program with the code, then an instruction will be created for the target server in the DMS (406). This information will contain instructions such as when to execute, which server or servers this action should be performed on, and which files to download from the File Storage module. These instructions may optionally contain additional information such as specific configuration details, or additional steps that are required. If the user has not provided an installation program, then the DMS will require the user to detail the location on the remote servers where the files should be installed -this can be for each run of the installation, be set up before-hand, or will use the previously selected values unless they are changed. From here, a server instruction will be created, using the same method as described above.

The client server will be connected to the DMS, either via TCP or UDP connection, HTTP/HTTPS, FTP or other methods, and will periodically check for any new instructions for that client server (501). The remote server will identify itself to the DMS either by machine name, IP Address, a unique ID placed on the server, or by other means. The DMS will hold a corresponding record of the client server machine against its identifier, enabling the DMS to calculate which machine is requesting instructions. If there are any instructions for the server (502), then this will be transmitted to the remote server, along with all required information, such as the uniform resource locator (503) or paths to download or obtain the installation programs and or files, or where the remote server can ask for these locations, e.g. from a closer DMS or a closer File Storage Module.

If the user has specified that a backup is to be taken of the files that will be replaced (505), this is processed before any changes -these files will be backed up to the File Storage Module, in a separate container or location, detailing that they are back up files, from which server, taken at what time (506). Typically the files backed up are the ones replaced, but this may not always be the case, as the user can override what is to be backed up or not to be backed up. These backup files may be transmitted singularly, or as a compressed archive. Backups can be sent to either the same DMS and File Storage module, or a different one, if the user has configured it to do so. Alternatively, backup instructions may execute a specified third party program to perform the backup.

Once the remote server has these instructions and file locations, the remote server will then download all the files specified on to the local machine (504), into a folder specified in a configuration file, or alternatively use a randomly generated temporary location if no such pre-configuration exists. The remote server will then perform the instructions that it was passed, e.g. run this installation program (506) or install that website. The user can define any instructions that are to be processed prior or post the installation, and these will be executed automatically. Any and all log files resulting from the installation of files will be transmitted back to either the DMS (702) or another external service for storage (703), to be displayed to the user (705) for analysis (706), either automated or manual, in addition to these log files being maintained locally on the client server (707).

If an error occurs at any stage during the install process, and if configured to do so and depending on the severity of the error (602), then the installation process may be halted, and the backups restored, depending on the configuration. The user may opt to ignore any and all errors (601), to only ignore certain errors (603), or to ignore no errors (604), and may choose to restore full backups (607), only partial files from backups (606), or to not restore any files at all from backups, or to execute a different application or applications on errors (608). The user may optionally require that if the installation process has failed, to alert the user (609) via email, text message, or any other form of notification (611), and may require the execution of other applications, programs or other machine readable code, or third party applications (610).

The user, via the DMS, may instruct the remote servers to perform additional tasks, such as reboot the computer, or delete log files, by pushing commands or scheduling commands for the remote server to pick up.

These can be created and maintained by the user, by using the same mechanism as described above, and these instructions can either be already pre-installed on the remote server, or be instructed to be downloaded and executed as above.

The DM5 can also deploy applications as above, but instead of requiring the client servers to poll the DM5 for instructions, the DM5 can connect to the client server, and push instructions and files required for installation.

The DM5 may optionally interface with third party services to aid in the installation, update or maintenance of applications, to be run before, during, or after the above installation steps have finished executing.

The user can use the DM5 to monitor the performance of the servers and or the applications running on those servers (801), for example (but not limited to) the CPU usage, memory usage, disk usage and associated performance metrics. The user can set alerting in the DM5 to alert the user, or a third party, if any of the parameters being monitored exceed or miss defined limits (803). The user can optionally instruct the DM5 that if one or more of these alerts (or a specific number of them) is triggered (804), it is then to execute machine readable code (805). This code can be run on the remote server (802), the DM5 (801), or both, or be run against a third party, and there may be many configuration parameters set for each instruction, as there may be many instructions set for one configuration parameter.

Alternatively, the user may elect that the DM5 receives information from a 3rd party monitoring system (901), and act on the information and or alerting that it receives (902), again by setting limits (903) that will perform an action (as above) if the limits are exceeded or missed (904).

The user may choose to have a combination of monitoring from the DM5, and from third party monitoring systems, and act accordingly on these limits.