Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of Invention:
AUTOMATED DEPLOYMENT SYSTEM AND METHOD THEREOF

Applicant:
TECH MAHINDRA LIMITED
A company Incorporated in India under the Companies Act, 1956
Having address:
Tech Mahindra Limited, Phase III, Rajiv Gandhi Infotech Park Hinjewadi,
Pune - 411057, Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.

CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application does not claim priority from any patent application.
TECHNICAL FIELD
[002] The present invention related with the field of one click deployment of tools. Particularly, the present invention involves an automated deployment pipeline for a platform that provides infrastructure and tools needed to support a wide range of services required in banking, capital markets, insurance etc.
BACKGROUND OF THE INVENTION
[003] Traditionally, infrastructure management involved manual configurations, which were time-consuming and prone to errors. These manual methods often led to inconsistencies between environments, such as development, testing, and production. To address these challenges, Infrastructure as Code (IaC) has emerged as a modern solution. IaC enables infrastructure to be defined, provisioned, and managed through code, using tools like Terraform, Ansible, and AWS CloudFormation. However, these infrastructures have limitations i.e. said infrastructure directly managing or providing the underlying resources (like servers, networking, or storage) but fails to focuses on the automatic functional and operational aspects of relying on the underlying infrastructure layer to provide the necessary resources for those functions to run smoothly.
[004] Moreover, the support platform relies on servers or external storage repositories, which burden the platform with hardware dependencies and may not be suitable for running applications efficiently. Additionally, there is no dedicated development platform that supports open application development and facilitates follow-up measures. As a result, developers are forced to use general application development tools, which reduce development efficiency. Furthermore, the power system operation has become challenging due to the proliferation of applications.
OBJECTS OF THE INVENTION
[005] The objectives of the invention based on the provided description of the automated deployment pipeline for an application platform.
[006] Primary objective of the present invention is to provide an automated deployment pipeline for an application platform, which enables seamless provisioning of server less cloud infrastructure, creation of deployable Docker images, and deployment to a centralized repository, ensuring efficient and scalable cloud-based application delivery.
[007] Another objective of the present invention is to enable a structured, step-by-step deployment process for the application platform, where each step is triggered sequentially based on the completion of previous steps, allowing for error-free execution and ensuring that all necessary infrastructure and configuration changes are applied automatically.
[008] Yet another objective of the present invention is to facilitate high availability and scalability of the deployed application, through automated registration with a load balancer, which ensures that user traffic, is efficiently distributed across multiple instances of the application, providing reliable access and performance.
SUMMARY OF THE INVENTION
[009] Before the present system is described, it is to be understood that this application is not limited to the particular machine, device, or system, as there can be multiple possible embodiments that are not expressly illustrated in the present disclosures. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present application. This summary is provided to introduce aspects related to an automated deployment system and method thereof, and the aspects are further elaborated below in the detailed description. This summary is not intended to identify essential features of the proposed subject matter nor is it intended for use in determining or limiting the scope of the proposed subject matter.
[0010] In an embodiment, the present invention provide a deployment system for automating the deployment of application services comprises several key modules working together to streamline the process. A builder module (101) is responsible for creating a build job using a Compute Infrastructure as Code (IaC) platform, which provisions the necessary infrastructure for deploying the build job. Once the builder module completes its task, a trigger module (102) detects the completion signal and activates a code build module (103). The code build module (103) receives the build job from the builder, transforms it into a binary format (104), and generates a deployable containerized Docker image (105). This Docker image is then validated and stored by a repository module (106), which ensures accessibility to the image for subsequent stages in the deployment pipeline. Upon successful storage of the Docker image, a second trigger module (107) generates a notification event, activating an Infrastructure as Code (IaC) module (108) to create and define the required compute infrastructure. The deployment module (110) retrieves the Docker image from the repository and deploys it as containerized application services on the provisioned compute infrastructure. A trigger to launch app services (109) is then initiated, ensuring that the deployment of application services occurs only after all prerequisites are met. Finally, a load balancing module (111) registers the deployed application service instances and dynamically updates the load balancer’s registry to reflect the addition or removal of instances.
[0011] In an embodiment, the present invention provides the builder module is configured to utilize templates or scripts to define resource configurations for infrastructure provisioning, and validate the configurations before initiating the build job.
[0012] In yet another embodiment, the present invention provides the load balancing module (111) is configured to: maintain the registry with real-time status information of each application service instance, including its network address and health status, to ensure that the load balancer accurately distributes incoming user requests to healthy instances.
[0013] In still another embodiment, the present invention provides the prerequisites for deploying the application services of trigger to launch app services (109) comprises successful generation and validation of the Docker image (105), successful provisioning of the compute infrastructure, and proper configuration of the network, storage, and compute resources.
[0014] In an embodiment, the present invention provides the code build module comprises: a container or virtual machine pre-configured with specific tools, libraries, and dependencies required for the build process.
[0015] In an embodiment, the present invention provides the repository module is configured to: implement access control mechanisms to ensure secure storage and retrieval of Docker images, and maintain version control of stored images to support rollback in case of deployment failures.
[0016] In still another embodiment, the present invention provides the second trigger module is configured to: validate the Docker image before generating a notification event, and halt the deployment pipeline if validation criteria are not met.
[0017] In yet another embodiment, the present invention provides the Infrastructure as Code (IaC) module provisions resources using orchestration tools, such as Kubernetes, Terraform, or AWS CloudFormation,
[0018] In an embodiment, the present invention provides the deployment module comprises a one-click deployment feature configured for an automated workflow that eliminates manual intervention across all stages of the deployment process, and provide a feedback mechanism to provide real-time status updates for the deployment process to the user.
[0019] In yet another embodiment, the present invention provides the builder module (101), code build module (103), and repository module (106) operate sequentially.
[0020] In still another embodiment, the present invention provides the trigger module (102) and second trigger module (107) operate synchronously, ensuring that each step in the deployment pipeline, including the completion of the build job and the successful storage of the Docker image, is fully validated before initiating subsequent stages, ensuring a step-by-step, controlled deployment process.
BRIEF DESCRIPTION OF DRAWING
[0021] The foregoing summary, as well as the following detailed description of embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the disclosure, there is shown in the present document example constructions of the disclosure, however, the disclosure is not limited to the specific methods and device disclosed in the document and the drawing. The detailed description is described with reference to the following accompanying figures.
[0022] Figure 1: illustrate the deployment system (100), in accordance with an embodiment of the present subject matter.
[0023] Figure 2: illustrate the flowchart depicting the operation of the deployment system, in accordance with an embodiment of the present subject matter.
[0024] The figures depict various embodiments of the present disclosure for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures illustrated herein may be employed without departing from the principles of the disclosure described herein.
DETAILED DESCRIPTION OF THE INVENTION
[0025] Some embodiments of this disclosure, illustrating all its features, will now be discussed in detail. The words "comprising", “having”, and "including," and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any devices and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, the exemplary, devices and methods are now described. The disclosed embodiments are merely exemplary of the disclosure, which may be embodied in various forms.
[0026] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure is not intended to be limited to the embodiments illustrated, but is to be accorded the widest scope consistent with the principles and features described herein.
[0027] Present invention is related to the development of tools and processes in a platform that enhance efficiency and reliability particularly in software development and operations. Particularly, present invention involves the adoption of CI/CD (Continuous Integration/Continuous Deployment) pipelines, which automate the build, and deployment of code changes. These pipelines enable teams to seamlessly integrate and validate code, ensuring that software is always in a deployable state. Further, the present invention also involves the use of containerization, allowing applications to be packaged into containers that run consistently across different environments. Tools like Docker is also used to facilitate the smooth deployment processes.
[0028] Particularly, in present invention the process begins with the source code files, which are the raw code written by developers. Particularly, in present invention a job or code is created in the CI/CD pipeline that will handle the build process. The code is built in a particular format, possibly in a Jenkins file or a similar configuration in another CI/CD tool. Afterwards, a code is triggered, as a code compilation. The compiled code is packaged into a binary Docker image. The Docker image is then pushed to a repository. This repository acts as a storage location where the Docker images are kept and can be accessed by other parts of the deployment process. The binary files are used to create a Docker image (a binary Docker image). This image is then pushed to an image repository, which is a storage system for Docker images (e.g., Docker Hub, AWS ECR).
[0029] The Docker image needs to be deployed in an environment where it can run. This environment can be a set of virtual machines (VMs), a Kubernetes cluster, or another container orchestration platform. One such platform is the Kubernetes or AWS ECS (Elastic Container Service), which automates the creation and configuration of this environment. Platform like Kubernetes or AWS ECS (Elastic Container Service) provides capabilities for management of containers. IaC is making it easier to automate operations of these platform. After creating a Docker image, IaC is essential to automate the deployment and management of the environment where that image will run. IaC ensures that the necessary infrastructure is provisioned, configured, and maintained in a consistent, repeatable, and scalable way, enabling reliable deployment and operation of containerized applications. Once the infrastructure setup is complete, the CI/CD pipeline triggers the actual application services (which are packaged in containers) are deployed into the container compute environment. This means that the Docker image can be deployed to a production environment, where it will run as a containerized application. IaC scripts might deploy the Docker container using a container orchestration tool (like Kubernetes). The scripts define how many replicas of the container should run, how they are balanced across nodes, and how they recover from failures. The application is then registered with a load balancer. A load balancer distributes incoming network traffic across multiple servers to ensure no single server becomes overwhelmed, improving the application’s availability and reliability. Finally, the application becomes accessible to users.
[0030] In an embodiment, the Figure 1 illustrate an explanation of the deployment pipeline system (100) illustrated in the same. The pipeline ensures a streamlined system from building the application's binary to making it accessible to end users. The system comprises a platform or Compute Infra as Code (IaC) that provisions the infrastructure required for the application to run, where a builder module (101) build or create a job using IaC platform defining the necessary resources for application deployment. This configuration sets the foundation for generating serverless infrastructure. Compute Infra as Code (IaC) is a type of platform that involves creating or provisioning the required infrastructure (e.g., servers, containers, networks, storage) in a cloud environment. The Builder module (101) depends on the infrastructure created by the IaC or the platform.
[0031] Afterwards a trigger module (102) triggers an automated deployment pipeline in response to a single user action, wherein the action initiates a sequence of build, infrastructure provisioning, and deployment stages. Particularly, the trigger module (102) detect completion signals from the build job module (101) and initiate subsequent processes in a sequential manner. In other words, trigger module (102) starts the build job created by the builder module (101).
[0032] A code build module (103) is configured to receive the job created by the builder module (101) and initiate the build process within a controlled environment, such as a container or virtual machine. This environment is equipped with all necessary tools, compilers, interpreters, and SDKs. The code build module (103) retrieves the relevant build scripts or configuration files, such as a Docker file, which dictate the steps for the build. The code build module (103) then transforms the job created by the builder module (101) into a usable binary format. The code build module (103), further requires specific inputs, including the application’s source files and binary dependencies or binary files (104). The source files contain the application’s core code, such as .java, .py, or .js files. Additionally, pre-compiled libraries may be included to support the application’s functionality. The code build module (103) then concludes the process by generating a binary Docker image. This containerized version of the system includes the compiled build code, all runtime dependencies such as source files, and the necessary configurations to execute the application in any Docker-supported environment. Once docker image (105) is built, it undergoes validation to ensure functionality, and the Docker image (105) is ready for deployment. This docker image is then pushed to an image repository or repository module (106), which is a storage system for Docker images (e.g., Docker Hub, AWS ECR). The repository module (106) acts as a storage medium, where the image is easily accessible.
[0033] Once the Docker image (105) is successfully pushed to the repository module (106), a trigger event notifies the next step in the pipeline. Afterwards, an IaC (107) provisions the necessary infrastructure, and retrieve the image (105) from the repository module (106) to deploy it. This ensures that the same tested and validated image runs consistently across all environments, leveraging automated and scalable infrastructure provisioned by the IaC.
[0034] Particularly, once the Docker image is successfully pushed to the repository module (106), a trigger event created by an image Generated Trigger module (also referred as second trigger module) (107) notifies the next step in the pipeline. This event serves as a signal to notify the pipeline that the docker image generation and storage has been completed. This trigger event is automatically created by the CI/CD tool in use (e.g., Jenkins, GitLab CI, or AWS CodePipeline). The notification may be a status flag (e.g., "success" or "ready") that activates the next job in the pipeline. The trigger module (107) ensures that the pipeline moves forward only when the Docker image (105) is successfully created and stored, avoiding errors caused by incomplete or invalid artifacts. The trigger automates the transition between steps, eliminating the need for manual intervention. If the image fails to generate or store properly, the pipeline stops, allowing developers to fix the issue before proceeding to the next step. The trigger event from the trigger module (107) activates the next step in the pipeline, which is typically infrastructure setup or application deployment.
[0035] IaC (108) module ensures that infrastructure is created in a consistent way every time, avoiding human errors. The same configuration file can be used to recreate the infrastructure in different environments (development, testing, production). After the infrastructure (e.g., compute nodes, storage, and network) is created, the system retrieves the Docker image from the repository module. The image is deployed as a containerized application on the provisioned infrastructure.
[0036] Once the IaC module (108) is provisioned and the image is deployed as a containerized application on the provisioned infrastructure, a trigger to launch app services (109) ensures that the application deployment process begins only after all prerequisites are met, making the system reliable and efficient. The trigger to launch app services (109) is an automated event initiates the deployment of application services (110) within the containerized compute environment. The deployment process configures the application services to work within the container environment. After the container compute environment is set up (e.g., through Infrastructure as Code module (108), the deployment of containerized docker image (105) as an application services (110) ensures that the application is running on the provisioned infrastructure, ready to handle requests from users or other systems and integrates seamlessly with external systems or services, like databases or APIs. Deployment of application services by a deployment module (110) in a containerized compute environment transforms the Docker image into an active, accessible, and scalable application service that is ready to operate in production. It ensures that the services are properly configured, networked, and monitored for reliable operation.
[0037] After deployment, multiple instances of the application services (running as containers or on virtual machines) are made available in the compute environment. A load balancing module (111) registers these instances with a load balancer. The load balancer maintains a list of active application service instances and their network addresses (IP and port). This setup allows for dynamic addition or removal of instances (e.g., scaling up or down) without disrupting user traffic. Once the application services are deployed in the compute environment, the load balancing module ensures they are accessible. As new instances are deployed or old ones removed, the load balancer’s registry is updated automatically and ensures the uninterrupted service as traffic is intelligently routed to healthy instances.
[0038] In an embodiment, the figure 2 illustrate the flowchart a well-defined process for deploying containerized applications using a combination of infrastructure as code (IaC), Kubernetes, and automated deployment mechanisms, ensuring smooth operation and scalability. The flow chart starts by triggering the Infrastructure as Code (IaC) pipeline. This triggers the Docker image build job, which initiates the creation of the necessary environment for building the containerized application. Secondly, the build job retrieves the source code and any binary dependencies required for the application. This step ensures that the application code and its necessary components are available for the build process. Afterwards, using the retrieved source code and binaries, a docker image is created. This image is a self-contained unit that includes the application, its dependencies, runtime libraries, configurations, and environment settings. After the Docker image is successfully created, it is pushed to a Docker image repository (e.g., Docker Hub, AWS ECR, or a private registry). The repository serves as a central location for storing and managing Docker images, ensuring they are accessible for the next stages of deployment. Once the Docker image has been pushed to the repository, a build completion event is triggered. This event notifies the pipeline that the build job has finished, prompting the next stage. The event triggers the Infrastructure Build Job, which will initiate the creation of the necessary infrastructure for deploying the application. In next step, the Infrastructure as Code (IaC) module provisions the required infrastructure. Additionally, a container cluster (like Kubernetes cluster or AWS ECS cluster) is created to orchestrate and manage containerized application deployment. The container cluster allows for scalable, automated, and efficient management of application containers.
[0039] After the infrastructure and container cluster (like Kubernetes cluster or AWS ECS cluster) are ready, the web service and application services are created using the Docker image pulled from the repository. These services are configured to run in the container management platform (like Kubernetes, AWS ECS).
[0040] Once the services are created, they need to be configured for optimal performance and security. This involves configuring networking, environment variables, security settings, and dependencies. After configuration, the services are started within the Kubernetes environment, making them ready to serve requests. At this stage, the system waits for the web service and application services to become fully operational and ready to handle incoming traffic. This may involve checking the status of the services and verifying that they have successfully initialized.
[0041] The system then checks checks if the web service is running correctly and is ready to serve requests. If the web service is not yet operational, the system will wait for it to become ready. If the web service is not running or ready, the system will continue to monitor the services and wait until they are ready. If the web service is running and ready, the system proceeds to register the web service as a load balancer target. The load balancer will route traffic to healthy web service instances, while failing instances will be removed from the pool until they are healthy again. After the load balancer has been configured and the web service is successfully registered, a sanity test is performed. This involves accessing the web service through the load balancer URL to ensure that the web service is functioning as expected. The test verifies that the web service can handle traffic and respond to requests correctly.
[0042] In an embodiment, the system described employs synchronous or sequential methodologies to improve efficiency and control during the deployment process. The CI/CD pipeline follows a strictly sequential process, where each step—such as code build, deployment, and infrastructure provisioning—is completed before the next begins. This approach ensures strict control over each stage of the process, reducing potential errors arising from concurrent operations. Sequential operations ensure that all components and resources are prepared in the correct order for deployment.
[0043] Furthermore, in the deployment system and method a synchronous approach would require each task in the CI/CD pipeline to complete before the next one begins. For example, a build job must finish successfully before the image is pushed to the repository or before infrastructure, provisioning can start. This ensures that each task is fully completed before proceeding, which is especially useful for critical components where failure in one step could lead to issues in subsequent steps. This guarantees a controlled, step-by-step flow and reduces the risk of errors from overlapping tasks.
[0044] Equivalents
[0045] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for the sake of clarity.
[0046] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present.
[0047] Although implementations for the automated deployment system and method thereof have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features described. Rather, the specific features are disclosed as examples of implementation for the automated deployment system and method thereof.
, Claims:
1. A deployment system for automating the deployment of application services, comprising:
a builder module (101), configured to create a build job using a Compute Infrastructure as Code (IaC) platform, the Compute IaC platform provisioning infrastructure required for deploying the build job;
a trigger module (102), configured to detect a completion signal from the builder module (101) and activate a code build module (103);
the code build module (103), configured to receive the build job created by the builder module (101), transform the build job into a binary format (104), and generate a deployable containerized Docker image (105);
a repository module (106), configured to validate and store the generated Docker image (105), and provide accessibility to the Docker image (105) for subsequent stages of the deployment pipeline;
a second trigger module (107), configured to generate a notification event upon successful storage of the Docker image (105) in the repository module (106), and activate an Infrastructure as Code (IaC) module (108), configured to create and define a compute infrastructure;
a deployment module (110), configured to retrieve the Docker image (105) from the repository module (106), and deploy the Docker image (105) as containerized application services on the provisioned compute infrastructure;
a trigger to launch app services (109), configured as an automated event to initiate the deployment of application services within the containerized compute environment, ensuring the application services are launched only after all prerequisites are met, and
a load balancing module (111), configured to register deployed application service instances, and dynamically update a registry of the load balancer to reflect addition or removal of instances.
2. The deployment system as claimed in claim 1, wherein the builder module (101) is configured to utilize templates or scripts to define resource configurations for infrastructure provisioning, and validate the configurations before initiating the build job.

3. The deployment system as claimed in claim 1, wherein the load balancing module (111) is configured to: maintain the registry with real-time status information of each application service instance, including its network address and health status, to ensure that the load balancer accurately distributes incoming user requests to healthy instances.

4. The deployment system as claimed in claim 1, wherein the prerequisites for deploying the application services of trigger to launch app services (109) comprises successful generation and validation of the Docker image (105), successful provisioning of the compute infrastructure, and proper configuration of the network, storage, and compute resources;

5. The deployment system as claimed in claim 1, wherein the code build module (103) comprises:
a container or virtual machine pre-configured with specific tools, libraries, and dependencies required for the build process.

6. The deployment system as claimed in claim 1, wherein the repository module (106) is configured to: implement access control mechanisms to ensure secure storage and retrieval of Docker images, and maintain version control of stored images to support rollback in case of deployment failures.

7. The deployment system as claimed in claim 1, wherein the second trigger module (107) is configured to: validate the Docker image (105) before generating a notification event, and halt the deployment pipeline if validation criteria are not met.

8. The deployment system as claimed in claim 1, wherein the Infrastructure as Code (IaC) module (108) provisions resources using orchestration tools, such as Kubernetes, Terraform, or AWS CloudFormation,
9. The deployment system as claimed in claim 1, the deployment module (110) comprises a one-click deployment feature configured for an automated workflow that eliminates manual intervention across all stages of the deployment process, and provide a feedback mechanism to provide real-time status updates for the deployment process to the user.

10. The deployment system as claimed in claim 1, wherein the builder module (101), code build module (103), and repository module (106) operate sequentially.

11. The deployment system as claimed in claim 1, wherein the trigger module (102) and second trigger module (107) operate synchronously, ensuring that each step in the deployment pipeline, including the completion of the build job and the successful storage of the Docker image, is fully validated before initiating subsequent stages, ensuring a step-by-step, controlled deployment process.

12. A method for automating the deployment of application services, comprising:
creating a build job using a Compute Infrastructure as Code (IaC) platform, wherein the IaC platform provisions infrastructure required for deploying the build job;
detecting a completion signal from the builder module (101) and activating a code build module (103) to initiate the build process;
receiving the build job by the code build module (103), transforming the build job into a binary format (104), and generating a deployable containerized Docker image;
validating and storing the generated Docker image (105) in a repository, and providing accessibility to the Docker image (105) for subsequent stages of the deployment pipeline;
generating a notification event upon successful storage of the Docker image (105) in the repository, and activating an Infrastructure as Code (IaC) module (108) to define and provision compute infrastructure;
retrieving the Docker image (105) from the repository module (106) and deploying the Docker image (105) as containerized application services on the provisioned compute infrastructure;
initiating the deployment of the application services within the containerized compute environment through an automated event, ensuring the application services are launched only after all prerequisites are met;
registering deployed application service instances with a load balancer and dynamically updating a registry of the load balancer to reflect addition or removal of instances.