WO2020091592A1

WO2020091592A1 - A self-learning method and system for automatically performing application packaging and deployment for a hosting environment

Info

Publication number: WO2020091592A1
Application number: PCT/MY2019/050079
Authority: WO
Inventors: Siow Fhang CHEAH; Soon Hin LEE
Original assignee: Mimos Berhad
Priority date: 2018-10-30
Filing date: 2019-10-25
Publication date: 2020-05-07

Abstract

A self-learning method and system for automatically performing application packaging and deployment for a hosting environment has been disclosed. The system comprises a plurality of node interrogator modules which are integrated in each of the hosting environments where the application is deployed, to monitor the environment and raise an application request on learning of at least one issue in the environment, a package learning and approval module which remotely communicates with each one of the node interrogator modules for receiving, processing and approving the application request based on inputs from the corresponding environment's deployment history, a confidence score and a self-regulated deployment policy; and a packaging module which communicates with the package learning and approval module and an organization project repository to prepare an application package for deploying at a corresponding hosting environment in the event a deployment approval is received from the package learning and approval module.

Description

A SELF-LEARNING METHOD AND SYSTEM FOR AUTOMATICALLY PERFORMING APPLICATION PACKAGING AND DEPLOYMENT FOR A

HOSTING ENVIRONMENT

FIELD OF THE DISCLOSURE

The disclosures made herein relate generally to the field of application packaging and deployment and, more particularly, to a method and system for automatically learning and performing application packaging and deployment for a hosting environment.

BACKGROUND

Application packaging is a process of compiling all necessary files, fixes and upgrades and preparing a new application package for a customer. The package once tested is then deployed at the customer’s one or more hosting environments. Each time a new application upgrade is available, a request for deploying the upgrade at a customer’s hosting environment is raised, accordingly an application development team creates or updates an application package based on the updates stored in a central project repository. Post creation or updation of the application package, an application release team retrieves the relevant application package from the repository and pushes the package to a customer’s hosting environment for deployment. Thereafter, the application release team keeps track of the application package deployed for each customer.

Typically, the application packages are well planned, documented and controlled in the project repository during the packaging stage but the control is lost once the application package is deployed for the customer. As a result, several limitations are faced while packaging or scheduling an application release for a customer.

One of the first limitations is that application packages are packaged and pushed from project repositories to customer as soon as an upgrade is ready, without or with very little insights into customer’s configuration of the hosting environment. Configuration mismatch, if any, such as device driver mismatch is only discovered much later after a deployment is made and if the application does not function as expected.

Another limitation is that there is no feedback in terms of assessment or approval or reporting, received from existing hosting environment(s) for an existing application deployment, hence this results in incomplete or incorrect application packages being pushed for deployment. For instance, if the hosting environment was upgraded then a feedback is not sent to the corresponding release teams to verify if an upcoming application package is compatible with such upgrades or configuration changes. These inconsistences and absence of feedback from the hosting environment leads to lack of systemic and centralized control in managing hosting environment variables from different customers, resulting in alteration of application packages in an ad hoc manner and only catering to specific customer’s needs. Ad hoc or runtime changes are not ported back to the project repositories causing inconsistency or re- development effort for subsequent application packages produced.

There is therefore felt a need for a method and a system which learns a customer’s hosting environment’s configuration or variables and accordingly prepares an application package for deployment. There is also felt a need for a system and method that receives feedback and accordingly centrally manages and monitors a customer’s hosting environment specific variables to eliminate inconsistencies while selection of an application package for deployment.

SUMMARY

The conventional deployment systems do not consider configuration or environmental variable changes of a hosting environment while preparing an application upgrade for deployment. Also, once an application is deployed there is no means to get or to record feedback from the hosting environment in terms of deployment inconsistencies or configuration mismatches. There is also dearth of deployment systems that centrally record and monitor deployed applications and their corresponding release specific or environment specific configuration changes so that they may be reused for other similar customer hosting environments.

These drawbacks led the present disclosure to provide a system and a method with self-learning capabilities for automatically performing application packaging and deployment for a hosting environment.

The technical problem being addressed by the present invention is the dearth of a system and method which can (i) automatically monitor a deployed environment for issues related to deployment such as runtime errors, configuration mismatches and the like, (ii) learn and assess the issues and raise a request for application deployment along with the fixes needed for the hosting environment, (iii) centrally track the request, check for availability, obtain an approval and then package an application release for all customer / client environments and (iv) obtain feedback after deployment of the application package, with no or minimal human intervention.

According to the disclosure, the system comprises a plurality of node interrogator modules, each of which are integrated with discrete hosting environments where the application is deployed, to monitor the environment and raise an application package request on learning at least one issue in the environment. The application request is sent to a package learning and approval module which remotely communicates with each one of the node interrogator modules for receiving, processing and approving the application request based on inputs from the corresponding environment’s deployment history, a confidence score and a self-regulated deployment policy. Once the application request is approved, an approval is sent to a packaging module which communicates with an organization project repository to prepare an application package for deploying at a corresponding hosting environment. The prepared application package is transmitted to the package learning and approval module which then triggers the node interrogator module, which had raised the application request, to automatically download and install the application package in its hosting environment.

Further, the package learning and approval module incorporates a package deployment matrix which records incoming application package requests and assigns a package request ID. The package deployment matrix then checks if the issues reported in the request have been fixed in any existing application packages available in the organization project repository. If the application package request is new and a fix is not available then package deployment matrix generates a request for a new application package else an application package approval request is generated.

The package learning and approval module also includes a deployment policy creation module which self-regulates a deployment policy based on parameters including an environment type, frequency of deployment, magnitude (size) of change requested, severity of change, priority of change and type of target environment and generates an upper control limit and lower control limit for each parameter. The calibrated policy is sent to a decision engine of the package learning and approval module which parses the policy and calculates a confidence score to approve an application deployment request if the confidence score for the parameters falls within the upper control limit and lower control limit.

Still further, the packaging module includes a metadata engine which creates metadata (if not available) for producing an application package which meets a desired hosting environment criterion. The metadata is generated either release specific or environment specific based on the pattern of the issue learned by the node interrogator module. Then a package builder module of the packaging module uses the metadata to locate the required application related data from an organization project repository to create an application package for the hosting environment.

Furthermore, the package learning and approval module receives the application package and triggers the node interrogator module to download and deploy the application package onto the hosting environment. According to the present disclosure, the node interrogator module obtains the deployment status and updates the package deployment matrix with the status.

The technical advancements or advantages of using the system and method provided by the present disclosure include: • preventing pushing of application packages for deployment in a hosting environment if the package request does not meet the approval criteria and thus in turn does not take into consideration environment variables and fixes required;

• obtaining feedback on the deployment across environments on parameters including assessment on application package identity, deployment status, and configuration compatibility to ensure a right application package is deployed correctly;

• facilitating recording of: (i) incoming application package request, (ii) the changes made to an application in response to the application package request; and (iii) feedback received after deployment of an application package to the package deployment matrix results in systemic and centralized control in managing different versions of the application package for different hosting environments. This also facilitates consistency and reproducibility of the application package requested.

Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

FIGURE 1 illustrates an exemplary network architecture in which or with which the proposed system can be implemented in accordance with an embodiment of the present disclosure. FIGURE 2 illustrates a block diagram for a self-learning system which displays the overall process flow for automatically performing application packaging and deployment for a hosting environment implemented in accordance with an embodiment of the present disclosure.

FIGURES 3a - 3d are flow diagrams representing working of the release controller module of the node interrogator module in accordance with an embodiment of the present disclosure.

FIGURE 4 is a flow diagram representing working of the pattern analyzer in accordance with an embodiment of the present disclosure.

FIGURES 5a - 5c are flow diagrams representing working of the package deployment matrix of the package learning and approval module in accordance with an embodiment of the present disclosure.

FIGURE 6 is a flow diagram representing working of the decision engine in accordance with an embodiment of the present disclosure.

FIGURE 7 is a flow diagram representing working of the deployment policy creation module in accordance with an embodiment of the present disclosure.

FIGURE 8 is a flow diagram representing working of the metadata engine in accordance with an embodiment of the present disclosure.

FIGURE 9 is a flow diagram representing working of the package builder module in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

In accordance with the present disclosure, there is provided a self-learning method and a system for automatically performing application packaging and deployment for a hosting environment, which will now be described with reference to the embodiment shown in the accompanying drawings. The embodiment does not limit the scope and ambit of the disclosure. The description relates purely to the exemplary embodiment and its suggested applications. The embodiment herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiment in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiment herein may be practiced and to further enable those of skill in the art to practice the embodiment herein. Accordingly, the description should not be construed as limiting the scope of the embodiment herein.

The description hereinafter, of the specific embodiment will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify or adapt or perform both for various applications such specific embodiment without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation.

Various terms as used herein are defined below. To the extent a term used in a claim is not defined below, it should be given the broadest definition persons in the pertinent art have given that term as reflected in printed publications and issued patents at the time of filing.

Definitions:

Project Repository: A data storage or database or computing memory for storing programming instructions, data files, metadata, and other related information about an application to facilitate compilation of an application package. It can hold and store information both temporarily and permanently, and can be internal or external to a computer, server or any similar physical or virtual computing device.

Hosting environment: Any computing hardware or virtual machine or a cloud-based computing setup providing the necessary network, hardware, software and firmware support for installation and execution of an application. The expression ‘decision engine’, ‘metadata engine’, ‘node interrogator module’, ‘package learning and approval module’, ‘packaging module’, ‘package builder module’, and ‘deployment policy creation module’ used hereinafter in the specification refer to units adapted to execute one or more functions or operations. The aforementioned ‘modules’ and ‘engines’ may be implemented in a form of hardware or software embodied in machine readable media or as a combination of hardware and software or as a cloud-based service.

Issues: Any runtime error or alerts or failure or inconsistencies experienced or captured in any one of the hosting environment or deployment application logs.

Application Package: A compilation of programmable instructions or computer software code and necessary data files and components, when hosted on any physical or virtual computing device uses the computational capabilities of the device for performing a desired task or operation.

Packaging: A process of compiling or combining programmable instructions or computer software code and necessary data files and components into a single executable application.

Package Deployment Matrix: Any data storage or data storage structure compiled in terms of data stored in a table form (matrix), a lookup table or in a multi-dimensional array format in a computer memory. The Package Deployment Matrix may also incorporate at least one processing engine or computational means to facilitate easy addition / updation and retrieval of information from its matrix structure.

Package Dictionary: A data store or data structure compiled in terms of data stored in a table form (matrix), a lookup table or in a multi-dimensional array format in a computer memory. Package dictionary holds keywords for various error terms found in error logs and the classification (configuration issue or code issue) for the keywords. The present disclosure attempts to bridge the gap between adhoc application deployments and proactive application deployments which take into consideration a hosting environment’s configuration, variables and fixes.

As will be appreciated by one skilled in the art, the present disclosure may be embodied as a system, method or computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware or programmable instructions) or an embodiment combining software and hardware aspects that may all generally be referred to herein as an“engine,”“module,” or“system.”

The present disclosure thus proposes a self-learning method and system which learns, assesses and collects feedback on application deployment across environments to ensure the right deployment is made correctly.

Referring to the accompanying drawings, FIGURE 1 illustrates an exemplary architecture (100) in which or with which proposed system can be implemented in accordance with an embodiment of the present disclosure. Before describing the operation of architecture in more detail, a brief overview of the system (100) is provided in order to enhance understanding.

As illustrated, in an architecture (100) that is represented in FIGURE 1 , the proposed system includes at least one node interrogator module (102) which is integrated in the hosting environment where an application is deployed. The system also includes a packaging module (1 12); and a package learning and approval module (104) which remotely communicates with each one of the node interrogator modules (102) and the packaging module (1 12) to facilitate application packaging and deployment.

According to one aspect of the present disclosure, each of the node interrogator modules (102) monitor the hosting environment, raise and transmit an application package request on learning at least one issue in the environment to the package learning and approval module (104). The package learning and approval module (104) receives, processes and approves the application request based on inputs learned from the corresponding hosting environment, existing application packages available in its package deployment matrix (106) and at least one self-regulated deployment policy, and transmits the approval to the packaging module (1 12). The packaging module (1 12) communicates with an organization project repository (118) to prepare an application package and further transmit the package to the package learning and approval module (104), wherein the package learning and approval module (104) triggers the node interrogator module (102), which raised the application request, to automatically download the application package in its hosting environment and transmit a feedback for updating the package deployment matrix (106).

According to an embodiment, the package learning and approval module (104) and the packaging module (112) may or may not necessarily exist as a physically separate unit as suggested in FIGURE 1. Also, network is the medium used to provide communications links between the various components connected together in the system (100). Network may include connections, such as wired, wireless communication links, or fiber optic cables.

Referring to FIGURE 2, which represents a block diagram showing various components and sub-components of the system (100) and the overall process flow of the system (100).

Those skilled in the art would appreciate that, although the system (100) includes a number of distinct modules, as illustrated in FIGURES 1 and 2, it should be recognized that some modules may be combined, and/or some functions may be performed by one or more modules. Therefore, the embodiment of FIGURES 1 and 2 represents the major components of the self-learning system for automatically performing application packaging and deployment, but these components may be combined or divided depending on the particular design without limiting the scope of the present disclosure.

Referring back to FIGURE 2, according to an aspect of the present disclosure, each of the node interrogator modules (102) comprises a release controller (200) and a pattern analyzer (202) which are integrated as a part of the application deployment environment. The release controller (200) enables the node interrogator module (102) to detect issues logged in the hosting environment by parsing various logs maintained in the environment including a build log, a system log, a database log, a network log, and a data packet log. Once an issue has been detected the release controller (200) triggers the pattern analyzer (202) to study the issue reported and determine if the issue is related to the hosting environment (or configuration factor) or to the application release (software code factor). The pattern analyzer (202) differentiates the issue and accordingly sends a feedback to the release controller (200).

The release controller (200) based on the feedback generates an application package request and transmits it to the package deployment matrix (106) component of the package learning and approval module (104) along with (i) feedback received from the pattern analyzer (202), (ii) the current environment configuration of the hosting environment and (iii) an identifier associated with the node interrogator module (102) (for example: a hardware certificate).

According to another aspect of the present disclosure, the package learning and approval module (104) includes the package deployment matrix (106), a deployment policy creation module (108), and a decision engine (1 10). The package deployment matrix (106) receives and analyzes the issue reported in the application deployment request. The package deployment matrix (106) checks if the reported issue has already been fixed, if yes, then in which application package it has been fixed. Accordingly, the package deployment matrix (106) triggers the decision engine (1 10) for approving the application deployment request.

According to yet another aspect of the present disclosure, if an application package which includes the reported fix has been identified in the matrix (106) then the decision engine (1 10) sends a policy request to the deployment policy creation module (108). The deployment policy creation module (108) self-regulates at least one deployment policy, for instance an environment promotion policy, and an application package approval policy and sends a tailored policy to the decision engine (1 10). The decision engine (1 10) parses the at least one deployment policy to calculate a confidence score for the identified application package and sends a feedback to the package deployment matrix (106). If the application package has been approved then the package deployment matrix (106) relays the application package request to the packaging module (1 12). The packaging module (1 12) includes a metadata engine (1 14) and a package builder (116). The metadata engine (1 14) parses the application package request against its registered metadata, differentiates release specific metadata and environment specific metadata and forwards the relevant metadata to the package builder (1 16). The package builder (116) builds and loads the requested application package to the package deployment matrix (106).

The package deployment matrix (106) on receiving the application package triggers the release controller (200) to download the application package to the target environment. The package deployment matrix (106) maintains deployment details of the application package for all environments in order to achieve systemic and centralized control in managing hosting environment variables from different customers.

Working and process flow of each of the major components / sub-components will now be explained in detail hereinafter.

Node Interrogator Module

Each node interrogator module (102) may be integrated with a discrete hosting environment and includes at least one release controller (200) and a pattern analyzer (202).

The release controller (200) learns about a customer’s hosting environment to detect issues logged in the environment by parsing at least one error log including a build log, a system log, a database log, a network log, and a data packet log which are maintained in the hosting environment. Further, if any issue is detected by the release controller (200) it triggers the pattern analyzer (202) to classify the issue as configuration or software code related issue. Thereafter, the release controller (200) identifies static and dynamic configuration related parameters for the detected issue to construct an application deployment request. The static configuration includes but is not limited to hardware specification of the hosting environment such as number of processor cores and the memory size or size of the file storage available in the hosting environment. The dynamic configuration includes software-based specification such as details on the database driver and its version which is installed in the hosting environment, and Secure Shell (SSH) connection agent and its version in the hosting environment.

Further, the application deployment request is supplemented by information including the detected issue, classification of the issue (configuration or code related), the current state and the desired state information for the detected issue and the corresponding node interrogator module’s (102) identifier.

The application package request is sent to the package learning and approval module (104) which upon approval and availability of a suitable application package triggers the requesting release controller (200) of the node interrogator module (102) to download the application package and subsequently provide feedback on the deployment.

Referring to FIGURES 3a to 3d, which are flow diagrams representing working of the release controller (200) in accordance with an embodiment of the present disclosure.

According to FIGURE 3a which is a flow diagram (1000) representing working of the release controller (200) for detecting at least one issue and triggering the pattern analyzer (202) for the issue analysis. According to an embodiment, at block (1010) the release controller (200) is triggered by a scheduler to read every log entry logged in the environment where the Node Interrogator module (102) is installed. The error log may be one of a build log, a system log, a database log, a network log, and a data packet log which are maintained in the hosting environment. At block (1020), the release controller (200) continues to read log entries to identify if any valid issue is found. Further, at block (1030) once a valid issue is detected, the release controller (200) adds the detected issue into an issue message. The issue message encompasses details such as subject, process, date, time, error and input of the detected issue. At block (1040), the release controller (200) continues to append every valid issue detected from the log entry to the issue message. Subsequently, at block (1050) if at least one valid issue is constructed in the issue message and reading of all log entries is completed, the release controller (200) sends the constructed issue message to the pattern analyzer (202) for analysis. If no valid issue is detected from the current log entry being read, the release controller (200) skips to next entry of the same log type until completion (block 1020) before continuing with the other log type (block 1040). The process continues by the release controller (200) being triggered by the scheduler to perform log entry reading at scheduled intervals.

FIGURE 3b is a flow diagram (1 100) representing working of the release controller (200) for constructing an application package request in accordance with an embodiment of the present disclosure. At blocks (1 1 10, 1 120) the release controller (200) is triggered to parse and analyze issue classification input received from the pattern analyzer (202). At block (1130), the issue analysis conclusion or classification received is parsed and analyzed one by one. Further, at block (1 140) on every issue analysis, current state information of the issue is collected based on the parameter involved which is, either static or dynamic and desired state information of the issue is generated. The issue analysis conclusion received from the pattern analyzer (202) is fully analyzed until a full set of current state information and its desired state information is constructed. At block (1 150), once a full set of current state information and its desired state information is constructed, an application package request is constructed together with the node interrogator module’s (102) identifier. Still further, at block (1160), the application package request is sent to the package deployment matrix (106) of the package learning and approval module (104) to request for a new application release package. Once the application package request is received by the package deployment matrix (106), an application package request ID number is returned to the release controller (200), at block (1 170).

FIGURE 3c is a flow diagram (1200) representing working of the release controller (200) for downloading an application package and sending a feedback on the deployment in accordance with an embodiment of the present disclosure.

At Block (1210) a deployment request associated with the application package request ID is received at the release controller (200) from the package deployment matrix (106). The release controller (200) verifies if the application package request ID is valid and matches it with the ID received at the release controller (200). The deployment request is rejected in case an invalid ID is received, see block (1280). At block (1270), a feedback is then sent to the package deployment matrix (106). If a valid ID is received, the application package is downloaded at block (1210) and a download operation is triggered to download a new application package and its associated configuration, see block (1220). Further, at block (1230), once the download operation is complete, a deployment is triggered or installation is started as per a received configuration. At block (1240), if a deployment is successful then a package dictionary which is bundled with the application package is downloaded for the Pattern Analyzer (202). Typically, the package dictionary contains developer centric keywords which are used to classify issues as logged in any output log as seen in TABLE 1 . TABLE 1 illustrates a structure of the package dictionary in accordance with one embodiment of the present disclosure.

TABLE 1 : Exemplary information captured in a package dictionary

At block (1250), once deployment or installation is completed, a deployment report is generated to indicate if the deployment or installation was successful or if the deployment or installation was unsuccessful with deployment errors. The deployment report is sent to the package deployment matrix (106) for its matrix update. At block (1260) in the event that deployment is unsuccessful, the release controller will abort the deployment or installation and trigger a rollback to restore the deployed application to its previously stable state. Block (1270) sends a feedback to the package deployment matrix (106) if the deployment was unsuccessful or aborted or rejected. FIGURE 3d is a flow diagram (1300) representing working of the release controller (200) for sending status of a current deployment in accordance with an embodiment of the present disclosure.

The release controller (200) receives an application package comparison request from the package deployment matrix (106). At block (1310), the release controller (200) collects the current state information, (1320) based on the application package comparison request. Once the current state information is collected completely, the state information is forwarded to the package deployment matrix (106) for its matrix update, (1330).

FIGURE 4 is a flow diagram (1400) representing working of the pattern analyzer in accordance with an embodiment of the present disclosure.

At block (1410), the pattern analyzer (202) is triggered to study at least one issue detected in the target or hosting environment once an issue message is received from the release controller (200). Further, at block (1420) the issue message is parsed one by one for every issue logged in the issue message. Thereafter, at block (1430) every issue logged is classified based on inputs from the package dictionary.

According to this invention, the package dictionary is bundled with or compiled along with the application package and is downloaded as a part of the pattern analyzer (202) upon successful deployment. The package dictionary contains developer centric keywords which are used to classify the detected issue as either a configuration issue, a code issue or as unknown. Further at block (1440), a list of parameters both static and dynamic is identified. Accordingly, an issue analysis or classification is sent to the release controller (200) in order to construct the application package request, see block (1450).

Package Learning and Approval Module The package learning and approval module (104) primarily includes three components a package deployment matrix (106), a decision engine (1 10) and a deployment policy creation module (108).

The package deployment matrix (106) performs the functions of analyzing the application deployment request reported from each of the node interrogator modules (102) and verifies if the issue reported has been fixed and in which application package they have been fixed. The package deployment matrix (106) also triggers the decision engine (110) for approval of an application deployment request. Further, the package deployment matrix (106) sends an application package request to the packaging module (1 12). Lastly, the package deployment matrix (106) maintains its matrix with any applications being deployed and in which hosting environments.

According to an embodiment, the package deployment matrix consistently updates its matrix each time (i) it receives a new application package and its configuration update from the packaging module (1 12), (ii) receives an application package request or deployment status update from the release controller (200) and, (iii) receives an application package approval from the decision engine (110).

FIGURES 5a - 5c are flow diagrams (2000, 2100 and 2200) respectively representing working of the package deployment matrix (106) of the package learning and approval module (104) in accordance with an embodiment of the present disclosure.

Referring to FIGURE 5a which represents working of the package deployment matrix (106) when it receives an application deployment request.

At block (2010), once an application package request is received from the release controller (200), an application package request ID is generated and returned to the release controller (200), (2020, 2030). Thereafter, at block (2040) the package deployment matrix (106) analyzes the application package request against its own matrix and checks if the same request is recorded and in which application package it has been fixed. At block (2040) the package deployment matrix (106) updates its existing matrix if the application package request is new or if the application package request has been addressed by an existing registered application package. At block (2050), the package deployment matrix (106) creates a new matrix and an application package request ticket if the application package request is new. A sample matrix entry for an application deployment can be seen in Table 2. Thereafter, an application package approval request is sent to the decision engine (1 10) for its approval, block (2060).

TABLE 2: Matrix maintained by the Package Deployment Matrix

FIGURE 5b represents working of the package deployment matrix (106) on receiving an approval for the application deployment request in accordance with an embodiment of the present disclosure. At block (21 10), once status for approval is returned by the decision engine (1 10) based on a verified application package request ID. If the application package request is new to the Matrix, then the request is forwarded to the packaging module (1 12), block (2130). Accordingly, the approval status is sent to the release controller (200). Alternatively, at block (2150) if the application package request has been addressed by an existing registered application package, then the package deployment matrix (106) updates its matrix with the identified application and a download request and approval status are sent to the release controller (200), blocks (2160, 2140). Further, in the event that the application package request is disapproved then the package deployment matrix (106) updates its matrix and requests for manual approval, block (2120).

FIGURE 5c represents various scenarios in which the package deployment matrix (106) updates its matrix in accordance with an embodiment of the present disclosure. The package deployment matrix (106) at block (2230) consistently updates its matrix in each one of the following scenarios:

• each time the package deployment matrix (106) receives a new application package and its configuration update from the package builder (116), block (2210);

• each time the package deployment matrix (106) receives an application package request or deployment status update from the release controller (200), block (2240); and

• each time the package deployment matrix (106) receives an application package approval from the decision engine (1 10), block (2220).

FIGURE 6 is a flow diagram (2300) representing working of the decision engine in accordance with an embodiment of the present disclosure.

According to the present disclosure, the decision engine (1 10) accepts an approval request from the package deployment matrix (106) and at least one tailored policy from the deployment policy creation module (108). The decision engine (110) based on the at least one deployment policy calculates a confidence score for the deployment request to either recommend or block the deployment.

Referring to FIGURE 6, at block (2310), the decision engine (1 10) receives an approval request for the application package from the package deployment matrix (106). Further, the decision engine (1 10) sends a policy request to the deployment policy creation module (108) based on the environment type retrieved from the approval request, block (2320). Thereafter, at blocks (2330 and 2340) the decision engine (1 10) receives at least one tailored policy and parses the application package request against the at least one policy received from the deployment policy creation module (108). For instance, if two tailored policies are received from the deployment policy creation module (108) then the decision engine (110) parses the application package request against each of the received policies to allow or reject the application package request. Thereby, if the application package request is within the compliance threshold (not lower than the lower-spec control limit, not higher than the upper-spec control limit), the deployment is approved by the decision engine (110), block (2350). If the application package request is out of the compliance threshold, the deployment is rejected, block (2360). In either case, at block (2370), the decision engine (1 10) sends an approval status to the package deployment matrix (106).

In accordance with this disclosure, the package deployment matrix (106) stores and maintains systemized deployment policies, which include at least one environment promotion policy and at least one application package approval policy. It is known to a person of ordinary skill in the art that the deployment policies are not limited to the environment promotion policy and the application package approval policy. Thereby, the package deployment matrix (106) can store additional deployment policies as required by the decision engine (1 10) in order to allow or reject an application package request.

FIGURE 7 is a flow diagram (2400) representing working of the deployment policy creation module in accordance with an embodiment of the present disclosure.

According to the present disclosure, the deployment policy creation module (108) facilitates in self-regulating a deployment policy based on feedback received from the package deployment matrix (106) via the node interrogator module (102). In an example, an environment promotion policy and an application package approval policy are used for regulating a deployment policy. The deployment policy creation module (108) considers criticality of certain functions of the application and thereby assigns higher thresholds for such aspects. The deployment policy creation module (108) also considers impact of at least one of the following parameters including magnitude of changes to the application, environment type, frequency of deployment, size of change, severity of change, priority of change while regulating the at least one deployment policy. Referring to FIGURE 7, the deployment policy creation module (108) receives a policy request from the decision engine (110). In response the deployment policy creation module (108) requests a latest matrix of the stored policies from the package deployment matrix (106) block (2410). The deployment policy creation module (108) then calibrates at least one stored deployment policy with data collected from the latest matrix, block (2420). The at least one policy is calibrated based on parameters such as environment type, frequency of deployment, magnitude (size) of change, severity of change, priority of change and target environment. For instance, the hosting environment may be any one of the following environment types including a development environment, an Integration Test (IT) environment, a System Test (ST) environment, a System Integration Test (SIT) environment, an User Acceptance Test (UAT) environment, a Provisional Acceptance Test (PAT) environment, a Staging environment, and a Production environment. The development environment carries lowest risk because this is where applications are tested for self-verification purposes. The deployment risks increase dramartically when the deployment traverses to IT environment, ST environment and SIT environment respectively in its order. The deployment risk is at its highest when it’s a deployment in the production environment because end users are using this environment and any failure in this environment results in great financial, market positioning and rework cost. Thereby, the deployment policy creation module (108) calibrates the environment promotion policy based on the different risks associated with each environment type and calculates the necessary thresholds accordingly.

At block (2430), the deployment policy creation module (108) executes a statistical process control to calculate and update Lower Control Limit (LCL) and Upper Control Limit (UCL) for each policy. In an example, policies including environment promotion policy and application package approval policy are updated per environment type, at block (2440). A person skilled in the art would appreciate that the policies may not be limited to environment promotion and application package approval policies. At blocks (2450, 2460), the deployment policy creation module (108) analyzes the application package request to tailor the request based on the below analysis:

• Environment data from the latest matrix is retrieved to identify the applicable Environment Promotion Policy based on environment type; and • Application policy request is analyzed for the application domain, magnitude of changes, criticality of the changes to apply the Application Package Approval Policy.

To elaborate further, the application package approval policy can be tabled based on application domain, magnitude of change, type of change. The deployment policy creation module (108) while calibrating the application package approval policy assesses criticality of the application domain and sets a higher threshold for highly critical software such as healthcare, aviation domain or the like. The deployment policy creation module (108) also assesses update to change coverage for application package metadata and sets a higher threshold for more / wider of metadata impacted. The ‘type of change’, ‘coverage of change’ and ‘severity of change’ is assessed to determine the impact of any update to software packages metadata. Accordingly, a higher threshold is set for logic change / critical and major changes, rather than GUI /front end based minor changes.

The deployment policy creation module (108) sends the tailored policy to the decision engine (110), at block (2470).

Packaging Module

The packaging module (1 12) includes a metadata engine (1 14) and a package builder (1 18). The metadata engine (1 14) performs the functions of generating and sending metadata for an application package request to the package builder (1 16) in response to an application package request received from the package deployment matrix (106). The metadata engine (1 14) parses the application package request against registered metadata to analyze if new release specific metadata and / or environment specific metadata is required and accordingly sends the metadata to the package builder (116).

FIGURE 8 is a flow diagram (3000) representing working of the metadata engine (114) in accordance with an embodiment of the present disclosure.

The metadata engine (1 14) receives the approved application package request from the package deployment matrix (106), block (3010). At blocks (3020, 3030), the metadata engine (1 14) parses and analyzes the application package request with existing metadata registered under the hosting or target environment. The current state is analyzed to retrieve release specific and environment specific metadata of current state, (block 3032). The desired state is also analyzed to retrieve release specific and environment specific metadata of the desired state (block 3034). Subsequently, the metadata engine (1 14) assesses magnitude of change between release specific and environment specific metadata and generates a release specific delta report and an environment specific delta report, blocks (3040 - 3044).

The metadata engine (114) generates metadata for a new application package if a release specific delta report exists and the metadata engine (114) generates environment metadata for an application package if environment specific delta report exists, blocks (3050 - 3060). Further, at block 3070, the metadata engine (1 14) detects if there are any changes to the metadata, if changes are detected then the metadata engine (1 14) registers new metadata else if no change is detected on metadata then refers to existing metadata registered (block 3080).

The application package request along with the registered metadata is sent to the package builder (1 16), block (3090).

FIGURE 9 is a flow diagram (3100) representing working of the package builder module in accordance with an embodiment of the present disclosure.

The Package Builder (1 16) performs the function of building a new application package. The package builder (1 16) receives an application package request from the metadata engine (1 14) along with the relevant environment or release specific metadata. The package builder (1 16) retrieves inputs from the organization project repository (1 18) based on the metadata and builds an application package. The package is loaded to the package deployment matrix (106) which further deploys it on the hosting environment.

Referring to FIGURE 9, at block (31 10) the package builder (1 16) receives an application package request along with registered metadata from the metadata engine (1 14). The package builder (1 16) parses the application package request and its metadata required, (3120). Each required input (ingredient) is identified and each required input (ingredient) is assessed if it could be sourced from the project repository (1 18), (3130). Subsequently, if all required inputs (ingredient) are found then the package builder (1 16) proceeds to build the application package, (3140), else build failed feedback is sent to the package deployment matrix (106), (3170).

If the build process is successful, then the application package is uploaded to the package deployment matrix (106) along with configuration files and the package dictionary and build success feedback is sent to the Package Deployment Matrix (106), see blocks (3150-3180).

In accordance with a further aspect, the present disclosure can take the form of a self-learning method for automatically performing application packaging and deployment for a hosting environment. The method comprises the steps of: (i) detecting at least one issue logged in the hosting environment and generating and transmitting an application deployment request based on the at least one detected issue; (ii) receiving the application deployment request and searching a package deployment matrix (106) for identifying or requesting a suitable application package corresponding to the application deployment request, approving the identified or requested application package based on regulated deployment policies; (iii) transmitting the approved application package to the hosting environment associated with the application deployment request, for deployment; installing the application package in the hosting environment and generating a deployment report indicating the status of the deployment; and updating the deployment report in a corresponding matrix of the package deployment matrix.

Typically, the step of detecting at least one issue logged in the hosting environment, generating and transmitting an application deployment request, includes: (i) parsing at least one error log including a build log, a system log, a database log, a network log, an application log and a data packet log at scheduled intervals to detect an issue; (ii) creating an issue message encompassing details including subject, process, date, time, error and input of the detected issue, in the event that an issue has been detected; (iii) comparing the detected issue with inputs from a package dictionary to classify the detected issue as at least one of a configuration issue, an application code issue or as unknown; (iv) identifying static and dynamic configuration related parameters for the detected issue to construct a current state and a desired state information; and (v) generating the application deployment request by compiling information including the detected issue, classification of the issue, the current state and the desired state information for the detected issue and an identifier associated with the hosting environment.

According to the present disclosure, the step of receiving said application deployment request and searching a package deployment matrix for identifying a suitable application package, includes: creating a new matrix and an application package request ticket in the package deployment matrix (106) if a suitable application package does not exist in the package deployment matrix.

Further, the step of approving the identified application package based on stored deployment policies, includes: (i) obtaining at least one stored deployment policy and information accompanying the application deployment request stored in the package deployment matrix (106), wherein the deployment policy is selected from the group consisting of an environment promotion policy and application package approval policy;(ii) calibrating the deployment policy and the information accompanying the application deployment request based on at least one parameter including environment type, frequency of deployment, magnitude, size of change, severity of change, priority of change and target environment; (iii) executing a statistical process control to calculate Lower Control Limit, LCL and Upper Control Limit, UCL for the at least one policy; (iv) updating the policy based on the calculated LCL and UCL; (v) using the updated policy obtained in step (iv) for parsing the application package request; and (v) approving the identified application package if the application package request is within the compliance threshold (LCL UCL).

Additionally, the method further includes the step of packaging the identified application package in the event the identified application has been approved, includes:

i. receiving an approved application package request in the event that the application package request is new;

ii. generating metadata for the approved application package request;

iii. sourcing inputs required for building an application package from a project repository and building the application package; and

iv. uploading the application package to the package deployment matrix. Still further, step of generating metadata for the approved application package request includes:

i. parsing and analysing a current state and a desired state of the hosting environment and the application release accompanying the approved application package request, using existing metadata registered under the hosting environment;

ii. assessing and generating release specific delta report and an environment specific delta report based on magnitude of change between release specific and environment specific metadata;

iii. generating release specific metadata for a new application package if a release specific delta report exists;

iv. generating environment specific metadata for an application package if environment specific delta report exists, (3060); and

v. registering new metadata if changes are detected, (3070).

Furthermore, the step of transmitting the application package build to the hosting environment includes updating the package deployment matrix with details of the approved application package for a particular hosting environment.

In accordance with an additional aspect, the present disclosure can take the form of a computer program product accessible from a machine-readable media providing programming code for use by the system (100). The software and/or computer program product can be hosted in the environment of FIGURE 1 to implement the teachings of the present disclosure.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise.

The terms "comprises," "comprising,"“including,” and“having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.

The use of the expression“at least” or“at least one” suggests the use of one or more elements, as the use may be in one of the embodiments to achieve one or more of the desired objects or results.

The process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously, in parallel, or concurrently.

Embodiments of the present disclosure may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, fixed (hard) drives, magnetic tape, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, semiconductor memories, such as ROMs, PROMs, random access memories (RAMs), programmable read-only memories (PROMs), erasable PROMs (EPROMs), electrically erasable PROMs (EEPROMs), flash memory, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic instructions (e.g., computer programming code, such as software or firmware).

Various methods described herein may be practiced by combining one or more machine-readable storage media containing the code according to the present disclosure with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present disclosure may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the disclosure could be accomplished by modules, routines, subroutines, or subparts of a computer program product.

While the foregoing describes various embodiments of the disclosure, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof. The scope of the disclosure is determined by the claims that follow. The disclosure is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the disclosure when combined with information and knowledge available to the person having ordinary skill in the art.

Claims

CLAIMS:

1. A self-learning method for performing application packaging and deployment for a hosting environment, characterized by the steps of:

i. detecting at least one issue logged in the hosting environment and generating and transmitting an application deployment request based on the at least one detected issue;

ii. receiving said application deployment request and searching a package deployment matrix for identifying or requesting a suitable application package corresponding to said application deployment request, (2040); iii. approving the identified or requested application package based on regulated deployment policies, (2350);

iv. transmitting the approved application package to the hosting environment associated with the application deployment request, for deployment, (2140);

v. installing the application package in the hosting environment and generating a deployment report indicating the status of the deployment, (1250); and

vi. updating the deployment report in a corresponding matrix of the package deployment matrix, (1270).

2. The method as claimed in claim 1 , wherein the step of detecting at least one issue logged in the hosting environment, generating and transmitting an application deployment request, includes:

i. parsing at least one error log including a build log, a system log, a database log, a network log, an application log and a data packet log at scheduled intervals to detect an issue, (1010);

ii. creating an issue message encompassing details including subject, process, date, time, error and input of the detected issue, in the event that the issue has been detected, (1030);

iii. comparing the detected issue with inputs from a package dictionary to classify the detected issue as at least one of a configuration issue, an application code issue or as unknown; iv. identifying static and dynamic configuration related parameters for the detected issue to construct a current state and a desired state information; and

v. generating the application deployment request by compiling information including the detected issue, classification of the issue, the current state and the desired state information for the detected issue and an identifier associated with the hosting environment.

3. The method as claimed in claim 1 , wherein the step of receiving said application deployment request and searching a package deployment matrix for identifying a suitable application package, includes: creating a new matrix and an application package request ticket in the package deployment matrix (106) if a suitable application package does not exist in the package deployment matrix.

4. The method as claimed in claim 1 , wherein the step of approving the identified application package based on stored deployment policies, includes:

i. obtaining at least one stored deployment policy and information accompanying the application deployment request stored in the package deployment matrix (106), (2410), wherein the at least one deployment policy is selected from the group consisting of an environment promotion policy and application package approval policy;

ii. calibrating the at least one deployment policy and the information accompanying the application deployment request, (2420);

iii. executing a statistical process control to calculate Lower Control Limit, LCL and Upper Control Limit, UCL for the at least one policy, (2430);

iv. updating the at least one policy based on the calculated LCL and UCL, (2440);

v. using the at least one updated policy obtained in step (iv) for parsing the application package request, (2340); and

vi. approving the identified application package if the application package request is within the compliance threshold of the LCL and the UCL, (2350).

5. The method as claimed in claim 1 , wherein the method further includes the step of packaging the identified application package in the event that the identified application has been approved, includes:

i. receiving an approved application package request in the event that the application package request is new, (3010);

ii. generating metadata for the approved application package request;

iii. sourcing inputs required for building an application package from a project repository and building the application package, (3140); and

iv. uploading the application package to the package deployment matrix, (3160).

6. The method as claimed in claim 5, wherein the step of generating metadata for the approved application package request includes:

i. parsing and analysing a current state and a desired state of the hosting environment and the application release accompanying the approved application package request, using existing metadata registered under the hosting environment, (3044);

ii. assessing and generating release specific delta report and an environment specific delta report based on magnitude of change between release specific and environment specific metadata, (3040 - 3044);

iii. generating release specific metadata for a new application package if a release specific delta report exists, (3050);

v. registering the new metadata if changes are detected, (3070).

7. The method as claimed in claim 1 , wherein the step of transmitting the application package to the hosting environment includes updating the package deployment matrix with details of the approved application package for a particular hosting environment.

8. A self-learning system (100) for automatically performing application packaging and deployment for a hosting environment, the system comprising: - at least one node interrogator module (102) integrated in the hosting environment where an application is deployed;

- a packaging module (112); and

- a package learning and approval module (104) which remotely communicates with each one of the node interrogator modules (102) and the packaging module (1 12) to facilitate application packaging and deployment, characterized in that,

the at least one node interrogator module (102) monitors the hosting environment, raises an application package request on learning at least one issue in the hosting environment, and transmits the application package request to the package learning and approval module (104); the package learning and approval module (104) receives, processes and approves said application request based on inputs learned from the corresponding hosting environment, existing application packages available in an existing matrix of the package deployment matrix (106) and a self-regulated deployment policy, and transmits the approval to the packaging module (1 12); and the packaging module (1 12) communicates with an organization project repository (1 18) to prepare an application package and further transmits the package to the package learning and approval module (104), wherein the package learning and approval module (104) triggers the node interrogator module (102), which raised the application request, to automatically download the application package in its hosting environment and transmit a feedback for updating the matrix of the package deployment matrix (106).

9. The system (100) as claimed in claim 8, wherein the node interrogator module (102) includes a release controller (200) to detect an issue in the hosting environment and further collect current state and desired state information of environment and the application hosted in the environment to trigger said application deployment request.

10. The system (100) as claimed in claim 8, wherein the node interrogator module (102) includes a pattern analyser (202) which is integrated with a package dictionary to analyse the issue detected in the hosting environment and determine where the issue is pertinent to the environment or the application code.

1 1. The system (100) as claimed in claim 8, wherein the package learning and approval module (104) includes a deployment policy creation module (108) that uses statistical process control techniques to assign Lower Control Limit, LCL and Upper Control Limit, UCL to update and regulate at least one policy stored in the matrix.

12. The system (100) as claimed in claim 8, wherein the package learning and approval module (104) includes a decision engine (110) which uses techniques including a confidence score and compliance thresholds, to parse said application package request against said self-regulated deployment policy to approve said application package request if the application package request is within the compliance thresholds of the LCL and the UCL.

13. The system (100) as claimed in claim 8, wherein the packaging module (112) comprising a metadata engine (1 14) and a package builder (1 16), wherein the metadata engine (114) generates release specific or environment specific metadata based on a pattern of the issue learned by the node interrogator module (102); and a package builder (1 16) uses the metadata to locate the required application related data from organization project repository (1 18) to prepare the application package for the hosting environment.