Segregated Schema Application Infrastructure for Zero-Downtime Deployment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Code deployment and business validation in systems like PEGA BPM require downtime for hours, necessitating off-hours deployment to minimize user impact, which wastes resources and slows rollouts.
Innovation Solution
A system with segregated schemas allows simultaneous production and non-production environments by using separate rule and data schemas, enabling developers to update and validate code without affecting live users, and includes automated file decryption and validation processes to ensure secure, efficient processing of sensitive data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If code deployment and business validation are performed in a single environment, then deployment completeness is improved, but application downtime increases
Solution Approach 1:
The patent segments the deployment environment into two separate schemas: a production schema for live applications and a non-production schema for development and validation. This segmentation allows parallel operations in both schemas without mutual interference, eliminating the need for sequential deployment processes that cause downtime.
Solution Approach 2:
The patent implements preliminary action by performing all code updates and business validations in the non-production schema before switching to the production schema. This preliminary validation ensures that only tested and verified changes are deployed to production, eliminating the need for post-deployment validation that would require production downtime.
2Productivity
If developers update code in the production environment, then code freshness is improved, but system stability deteriorates
Solution Approach 1:
The patent segments the codebase into production and non-production schemas, allowing developers to work freely in the non-production schema without risking production system stability. The production schema remains stable and unchanged until validation is complete, while the non-production schema serves as a safe testing ground for all modifications.
Solution Approach 2:
The patent creates a copy of the production schema as a non-production schema for development purposes. This copy allows developers to perform all updates and validations without affecting the original production system. Once validated, the changes are then applied to production, ensuring both development agility and system stability.
3Object-affected harmful factors
If deployment is performed during off-hours, then user impact is reduced, but resource utilization efficiency deteriorates
Solution Approach 1:
The patent segments deployment operations into non-production and production phases that can occur at different times. Non-production updates can be performed during business hours without impacting users, while production switching occurs during off-hours. This segmentation eliminates the need to perform all deployments during off-hours, improving resource utilization while still minimizing user impact.
Solution Approach 2:
The patent enables continuous development and validation activities in the non-production schema during business hours, maintaining productive use of system resources. The production schema remains stable and serves users continuously, while updates are prepared in parallel in the non-production schema, ensuring continuous useful action without interruption to user services.
Data Source
AI summary
A computer system includes a database configured to store a first rule schema, a second rule schema and a data schema, the first and second rule schemas each configured to store a compiled code base, and the data schema configured to store transactional data. The system includes a user application node configured to allow users to perform application operations, and a developer application node configured to facilitate developer deployment operations. Processor hardware is configured to point the user application node to the first rule schema, point the developer application node to the second rule schema, point the user application node and the developer application node to the data schema, update the second rule schema according to updates received via the developer application node, and in response to validation of the updates to the second rule schema, change the user application node to point to the updated second rule schema.