Registry regulations deployment subsystem
| 🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions. |
1. Overview
The registry regulations deployment subsystem verifies the integrity of the changes made to the registry regulations and automatically applies them to the subsystems of the registry operational zone.
2. Subsystem functions
-
Tracking changes to the registry regulations
-
Validating the integrity of the registry regulations
-
Deploying temporary databases for version candidates
-
Applying changes to the registry database schema
-
Generating code for registry data access services
-
Deploying registry data access services
-
Deploying changes to business processes and UI forms
-
Creating user roles for the registry
-
Configuring access rights to business processes
-
Applying changes to external integration and cross-registry interaction settings
-
Deploying changes to report and excerpt templates
-
Deploying changes to user notification templates
-
Applying changes to registry settings and customization
-
Storing artifacts of registry data access services
-
Resetting operational zone subsystems to the default state (regulations cleanup)
-
Configuring simulation rules for external integrations
-
Configuring geodata management subsystem
3. Technical design
-
(1) - Occurs only on the first deployment of the registry regulations, including post-cleanup recovery.
4. Subsystem components
Component name |
Registry representation |
Source |
Repository |
Function |
Regulations deployment service |
|
3rd-party |
A software suite that provides automation throughout the registry regulations deployment lifecycle. |
|
Regulations deployment pipeline |
|
origin |
Groovy pipelines to execute the various steps of the regulations deployment subsystem. Built on the EDP Pipeline Framework. |
|
Regulations deployment agent |
|
origin |
A Jenkins agent that runs the pipelines of the regulations deployment subsystem and has all the necessary dependencies. To learn more about Jenkins agents, refer to Jenkins documentation: Using Jenkins agents. |
|
Registry artifacts storage |
|
3rd-party |
Storing the artifacts generated in the subsystem. |
|
Regulations validation utility |
|
origin |
A command line interface (CLI) for validating the registry regulations' components at the stage of checking potential changes. |
|
Registry data access services generation utility |
|
origin |
A CLI for generating registry data access services code based on the Liquibase script descriptions. |
|
Reports and excerpts publishing utility |
|
origin |
A CLI for publishing reports and excerpts to the corresponding subsystems. |
|
BP access management utility |
|
origin |
A CLI for managing access rights to BP for the corresponding user roles. |
|
Notification templates publishing utility |
|
origin |
A CLI for publishing notification templates to the corresponding subsystems. |
|
Geolayers loading utility |
|
origin |
A CLI for configuring the geodata management subsystem. |
|
Temporary registry databases |
|
origin |
Temporary registry databases for version candidates are used when modeling the regulations to test potential changes in Liquibase scripts. |
5. Technological stack
The following technologies were used when designing and developing the subsystem:
6. Subsystem quality attributes
6.1. Deployability
The main task of the subsystem is to deploy the regulations changes to the corresponding subsystems of the registry operational zone as soon as they are made. The deployment is implemented using common scripting and deployment automation technologies such as Groovy, Jenkins, and Helm.
6.2. Integrability
The subsystem must be integrated with other subsystems of the registry operational zone. For this, the system uses Groovy scripts and CLI adapters that contain complex integration logic and are developed using the Java programming language and common frameworks such as Spring and Spring Boot.
6.3. Modifiability
The registry regulations deployment pipeline is divided into separate, loosely connected steps. This enables you to safely modify the existing implementation and develop features to update new subsystems when expanding the registry operational zone.