Deployment Pipeline Automation Using DAG-Based Container Orchestration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software deployment processes are complex, inefficient, and prone to technical debt due to the use of artisanal scripts that are not portable, require manual orchestration, and lack effective pipeline automation, making it difficult to manage containers and audit deployment errors.

Innovation Solution

A script automation processor with a GraphQL-based API is introduced to manage container instantiation and automate workflows, allowing developers to write small scripts that leverage API extensions for scalable and modular pipeline automation, ensuring portability and ease of maintenance.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If artisanal scripts are used for pipeline automation, then deployment can be automated, but the scripts become difficult to maintain and accumulate technical debt

Engineering Contradiction:
Improvepipeline automationVSAvoidscript maintenance
Core Design Contradiction:
Extent of automationVSEase of repair

Solution Approach 1:

The patent segments the deployment pipeline into modular, reusable script components that can be independently maintained and updated. This modularization allows specific parts of the pipeline to be repaired or modified without affecting the entire system, reducing technical debt while maintaining automation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent creates universal script templates and functions that can be applied across multiple deployment scenarios and platforms. These standardized components reduce maintenance burden by providing consistent, tested patterns that work across different environments, eliminating the need to maintain separate artisanal scripts for each case.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Productivity

If platform-specific scripts are written for cloud services, then deployment can be optimized for that platform, but the scripts become incompatible with other platforms and require rewriting

Engineering Contradiction:
Improvedeployment efficiencyVSAvoidplatform portability
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent develops universal deployment scripts that can operate across multiple cloud platforms and environments. By designing platform-agnostic script templates with configurable parameters, the system maintains high deployment efficiency while enabling easy adaptation to different platforms without complete rewriting.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent uses parameter-based configuration to adapt deployment scripts to different platforms. By changing parameters and configuration values rather than rewriting the entire script, the system achieves platform-specific optimization while maintaining portability and compatibility across different cloud services.

Inventive Principle:
Principle #35Parameter changes

3Ease of operation

If manual orchestration of deployment workflows is performed, then flexibility and control are maintained, but the process becomes time-consuming and inefficient

Engineering Contradiction:
Improveworkflow controlVSAvoiddeployment time
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The patent implements pre-configured deployment templates, scripts, and workflows that are prepared in advance. This preliminary action allows automated execution of complex deployment sequences without manual intervention during actual deployment, significantly reducing deployment time while maintaining the flexibility to customize configurations when needed.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent incorporates automated feedback mechanisms that monitor deployment progress, detect issues, and trigger appropriate responses. This feedback-driven automation maintains operational control by allowing the system to self-correct and adapt during deployment, reducing manual oversight time while preserving flexibility through automated decision-making.

Inventive Principle:
Principle #23Feedback

4Adaptability or versatility

If custom automation platforms are implemented for enterprises, then specific organizational needs are met, but the implementation requires large up-front costs and is time-consuming

Engineering Contradiction:
Improveorganizational customizationVSAvoidplatform complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the automation platform into modular, independently deployable components that can be selectively implemented based on organizational needs. This segmentation allows enterprises to start with essential features and gradually add customization, reducing up-front costs and implementation time while maintaining the ability to meet specific organizational requirements.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements a dynamic automation platform that can adapt its complexity level based on organizational needs. The system allows enterprises to configure the degree of customization and automation, enabling simple organizations to use basic templates while more complex organizations can implement advanced custom workflows, thereby matching platform complexity to actual requirements rather than imposing maximum complexity on all users.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP4332754B1Automated application deployment
Publication Date: 2026.02.11 DAGGER
  • EP4332754B1 patent drawingFigure 1
  • EP4332754B1 patent drawingFigure 2
  • EP4332754B1 patent drawingFigure 3

AI summary

In one embodiment, a computer-implemented method comprises using a script automation processor that is hosted using a virtual compute instance and a virtual storage instance associated with one or more second non-transitory computer-readable storage media storing one or more second sequences of instructions defining an API implementation of the API, a graph server, and one or more programming language runtime interpreters, receiving a user pipeline automation script comprising one or more first sequences of instructions specifying one or more API calls to an application programming interface (API), and a user application; using the script automation processor, creating and storing one or more programmatic containers in memory of the script automation processor, the containers corresponding to functions that user pipeline automation script and user application invoke; using the script automation processor, creating and storing a directed acyclic graph (DAG) in the memory of the script processor, the DAG comprising nodes and edges corresponding to dependencies of the containers; using the script automation processor, interpreting the user pipeline automation script using a particular programming language runtime interpreter among the one or more programming language runtime interpreters; using the script automation processor, running the user pipeline automation script to automatically build, test, or deploy the user application in a cloud computing service.