Zero Downtime Software Upgrade via Delta Deployment

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Traditional upgrade procedures for software applications and databases often result in downtime during maintenance, as they cannot deploy new features of the data dictionary activator together with data dictionary objects that use these features, leading to inefficiencies and constraints on the system, especially with frequent deployments.

Innovation Solution

The implementation of a zero-downtime upgrade procedure that uses multiple application servers and access schemas to deploy changes from a first version to a second version, allowing the deployment of new data dictionary features and objects without interrupting production use, by adjusting infrastructure table structures and activating data dictionary objects of the second version.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If traditional upgrade procedures are used, then the upgrade can be performed using the system's existing functionality, but the system cannot deploy new data dictionary features together with data dictionary objects that use these features

Engineering Contradiction:

Improveability to deploy new data dictionary featuresVSAvoidupgrade completeness

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The upgrade process is divided into multiple phases: first deploying the new data dictionary activator with new features, then separately deploying data dictionary objects that utilize these features. This segmentation allows the system to handle new features and their corresponding objects in manageable steps, ensuring both adaptability and reliability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The new data dictionary activator and its features are deployed and activated before the data dictionary objects that depend on these features are deployed. This preliminary action ensures that when the dependent objects are deployed, the necessary functionality already exists in the system.

Inventive Principle:

Principle #10Preliminary action

2Adaptability or versatility

If multiple smaller deltas are deployed to handle new features, then the system can avoid using the second version for the upgrade, but the deployment procedure adds constraints to the system and requires additional resources

Engineering Contradiction:

Improvedeployment flexibilityVSAvoiddeployment procedure constraints

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent combines the deployment of the new data dictionary activator with the deployment of data dictionary objects into a unified upgrade procedure. This merging eliminates the need for multiple separate delta deployments, reducing system constraints and resource requirements while maintaining deployment flexibility.

Inventive Principle:

Principle #5Merging (Combining)

3Productivity

If frequent deployments are performed, then new functionality can be deployed often, but the constraints are applied too frequently and inefficiencies multiply

Engineering Contradiction:

Improvedeployment frequencyVSAvoidsystem constraints

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The upgrade procedure enables continuous deployment of new data dictionary features and objects without requiring the system to be taken offline or putting constraints on user extensibility. This continuity allows frequent deployments to occur efficiently, multiplying productivity while avoiding the inefficiencies of repeated constraint application.

Inventive Principle:

Principle #20Continuity of useful action

4Adaptability or versatility

If the second version is used for the upgrade, then new features can be deployed, but the system cannot re-use functionality within the system during the upgrade

Engineering Contradiction:

Improvenew feature deploymentVSAvoidfunctionality re-use

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The new data dictionary activator is deployed and activated as a preliminary action before the upgrade completes. This allows the system to re-use the new functionality during the upgrade process itself, eliminating the need to choose between using the second version for new features or re-using existing functionality.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS11269620B1Zero downtime upgrade through delta deployment procedure using target software stack

Publication Date: 2022.03.08 SAP SE

AI summary

Implementations include a first application server interacting with a first infrastructure table of a first version through a first access schema, providing, during an upgrade, a second application server to execute a portion of the upgrade by interacting with data schema through the first access schema, adjusting a structure of a second infrastructure table to provide an adjusted structure, the structure of the first version and the adjusted structure of the second version, the second infrastructure table including a copy of the first infrastructure table, providing a second access schema of the second version, providing a third application server configured to interact with data schema through the second access schema, and activating, by the third application server using an activator of the second version, objects of the second version, the activator including features that are different than an activator of the first version.