Підсистема розгортання регламенту реєстру
| 🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. |
1. Загальний опис
Підсистема, що забезпечує функції перевірки цілісності внесених змін до цифрового регламенту реєстру та їх автоматичне застосування до підсистем операційної зони реєстру.
2. Функції підсистеми
-
Відстеження змін до регламенту реєстру
-
Валідація цілісності регламенту реєстру
-
Розгортання тимчасових баз даних для версій кандидатів
-
Застосування змін до схеми бази даних реєстру
-
Генерація коду сервісів доступу до даних реєстру
-
Розгортання сервісів доступу до даних реєстру
-
Розгортання змін до бізнес-процесів та UI-форм
-
Створення ролей користувачів реєстру
-
Налаштування прав доступу до бізнес-процесів
-
Застосування змін до налаштувань зовнішніх інтеграцій та між-реєстрової взаємодії
-
Розгортання змін до шаблонів витягів та звітів
-
Розгортання змін до шаблонів повідомлень користувачів
-
Застосування змін до налаштувань та кастомізацій реєстру
-
Зберігання артефактів сервісів доступу до даних реєстру
-
Приведення підсистем операційної зони реєстру до стану за замовчуванням (очищення регламенту)
-
Налаштування правил симуляції зовнішніх інтеграцій
-
Налаштування підсистеми управління геоданими
3. Технічний дизайн підсистеми
-
(1) - Відбувається тільки при першому розгортанні регламенту реєстру включно з відновленням після очищення
4. Складові підсистеми
| Назва компоненти | Представлення в реєстрі | Походження | Репозиторій | Призначення |
|---|---|---|---|---|
Сервіс розгортання регламенту |
|
3rd-party |
Програмний комплекс, що забезпечує автоматизацію в життєвому циклі розгортання регламенту Реєстру |
|
Пайплайни розгортання реглменту |
|
origin |
Groovy пайплайни для виконання різноманітних кроків підсистеми розгортання регламенту. Побудовано на базі EDP Pipeline Framework |
|
Агент розгортання регламенту |
|
origin |
Jenkins агент, який використовується для запуску пайплайнів підсистеми розгортання регламенту і містить всі необхідні залежності для цього. Детальніше з концепцією Jenkins агентів можна ознайомитись в офіційній документації |
|
Сховище артефактів реєстру |
|
3rd-party |
Збереження згенерованих в підсистемі артефактів |
|
Утиліта валідації регламенту |
|
origin |
Command line interface (CLI) для валідації складників регламенту на етапі перевірки потенційних змін |
|
Утиліта генерації сервісів доступу до даних реєстру |
|
origin |
CLI для генерації коду сервісів доступу до даних реєстру на основі опису Liqubase-скриптів |
|
Утиліта публікації аналітичних звітів та витягів |
|
origin |
CLI для публікації аналітичних звітів та витягів у відповідні підсистеми |
|
Утиліта управління доступом до БП |
|
origin |
CLI для налаштування прав доступу до БП для відповідних ролей користувачів |
|
Утиліта публікації шаблонів нотифікацій |
|
origin |
CLI для публікації шаблонів нотифікацій у відповідну підсистему |
|
Утиліта завантаження геошарів |
|
origin |
CLI для налаштування підсистеми управління геоданими |
|
Тимчасові бази даних реєстру |
|
origin |
Тимчасові бази даних реєстру для версій-кандидатів, які використовуються при моделюванні регламенту для перевірки потенційних змін у Liquibase скриптах |
5. Технологічний стек
При проєктуванні та розробці підсистеми, були використані наступні технології:
6. Атрибути якості підсистеми
6.1. Deployability
Основна задача підсистеми - це швидке розгортання внесених до регламенту змін у відповідні підсистеми операційної зони реєстру відразу після їх створення. Для реалізації розгортання використовуються загально поширені технології скриптування та автоматизації розгортання, такі як Groovy, Jenkins, Helm.
6.2. Integrability
Перед підсистемою стоїть задача інтеграції з іншими підсистемами операційної зони реєстру. Для цього використовуються Groovy скрипти або CLI адаптери, які містять складну логіку інтеграції та розроблені за допомогою мови програмування Java та поширених фреймворків Spring та Spring Boot.
6.3. Modifiability
Пайплайн публікації регламенту реєстру розділений на окремі кроки, які слабо пов’язані один з одним. Це дозволяє більш безпечно вносити зміни до наявної реалізації та розробляти нові функції по застосуванню змін до нових підсистем при розширенні операційної зони реєстру.