Модель розгортання регламенту та пайплайн публікацій

Сторінка технічної документації є баченням майбутньої реалізації, актуальність якого може бути застарілою.

1. Розгортання регламенту

Розгортання системи відбувається на підставі одного або декількох регламентів.

Адміністратор регламенту формує та ініціює розгортання регламенту реєстру, що передбачає внесення змін до набору сутностей — елементів регламенту.

Структура та опис типових сутностей подані у розділі Структура регламенту.

Розгортання регламенту реєстру автоматизовано інструментами CI/CD. За розгортання регламенту відповідає Jenkins-пайплайн MASTER-Build-registry-regulations та пов’язані пайплайни.

Детальніше про пайплайн публікації регламенту дивіться у розділі Пайплайн MASTER-Build-registry-regulations та його особливості.

2. Структура регламенту

Каталог регламенту реєстру має чітко визначену структуру директорій. Нижче показано схему типового регламенту.

Приклад 1. Структура типового регламенту реєстру
Diagram
Таблиця 1. Пояснення до структури регламенту
Регламент Директорія/Файл Опис

registry-regulations

Верхньорівнева папка, що містить вкладені директорії із сутностями регламенту.

bp-auth

Папка, що містить YAML-файли доступу до бізнес-процесів для реалмів citizen (отримувач послуг), officer (посадова особа/надавач послуг) та external-system (зовнішні системи та реєстри).

bp-trembita

Папка, що містить конфігураційні файли для налаштування взаємодії із зовнішніми сервісами та системами через SOAP-інтерфейси ШБО «Трембіта», а також через REST.

bpmn

Папка, що містить схеми бізнес-процесів у форматі .bpmn (різновид XML)

data-model

Папка, що містить схеми для розгортання БД та API-представлень, а також CSV-довідники для подальшого наповнення даними таблиць-довідників.

dmn

Папка, що містить змодельовані перевірчі правила (таблиці прийняття рішень) у форматі .dmn (різновид XML)

excerpts

Папка, що містить шаблони PDF-витягів реєстру

excerpts-csv

Папка, що містить шаблони витягів-звітів у форматі CSV

excerpts-docx

Папка, що містить шаблони проєктів наказів у форматі DOCX

forms

Папка, що містить змодельовані користувацькі форми введення даних у форматі JSON

global-vars

Папка, що містить глобальні змінні бізнес-процесів реєстру

notifications

Папка, що містить шаблони для відправлення повідомлень через канали зв’язку diia, email, та inbox.

reports

Папка, що містить сформовану аналітичну звітність (запити та дашборди) у JSON-форматі

roles

Папка, що містить конфігураційні файли для налаштування ролей у реєстрі (officer.yml — для призначення посадових осіб різних рангів, citizen.yml — для визначення отримувачів послуг)

settings

Папка, що містить загальні налаштування регламенту (повна та скорочена назви реєстру тощо)

settings.yaml

Конфігураційний файл, що містить системні налаштування реєстру та деяких сервісів

2.1. Сценарії використання

Виділяють 3 основні сценарії розгортання:

  • Створення реєстру — розгортання системи на підставі завантаженого регламенту.

  • Внесення критичних змін — має супроводжуватись обов’язковим збільшенням версії в її другому розряді. До критичних змін можна віднести будь-які зміни до моделі даних та бізнес-процесів.

  • Внесення незначних змін — при внесенні навіть незначних змін версія має бути збільшена у своєму третьому розряді. Незначними змінами вважаються ті для внесення яких не потрібний рестарт сервісів.

2.2. Безперервна інтеграція та безперервне доставлення (CI/CD)

Розгортання регламенту реєстру автоматизовано інструментами CI/CD. За розгортання регламенту відповідає Jenkins-пайплайн MASTER-Build-registry-regulations та пов’язані пайплайни.

У розробці програмного забезпечення CI/CD або CICD — це комбінована практика безперервної інтеграції та безперервного доставлення або безперервного розгортання.

deployment pipeline
Зображення 1. Схема розгортання регламенту реєстру за допомогою CI/CD

3. Пайплайн MASTER-Build-registry-regulations та його особливості

Кроки можна розділити на службові та породжувальні. Всі службові кроки — є обов’язковими для виконання. Породжувальні — кроки які відповідальні за розгортання/внесення змін до компонентів можуть бути пропущені, якщо змін вносити не треба.

preparation
deployment
error

3.1. Зчитування змін у репозиторії реєстру

Після клонування репозиторія реєстру відбувається перевірка файлів регламенту на наявність внесених змін.

3.2. Валідація конфігураційних файлів

Перевірка відповідності завантаженого регламенту схемам та правилам.
Наприклад: відповідність зміни версії до типу внесенних змін.

3.3. Розгортання моделі даних

Оскільки розгортання моделі даних являє собою складний процес, то його створення винесено в окремий pipeline (див. Розгортання моделі даних та дата сервісів)

3.4. Автотести

Не перевіряють логіку бізнес процесів чи комунікацію між компонентами системи. Основна задача таких тестів - перевірити чи всі компоненти стартували успішно.

3.5. Розгортання моделі даних та дата сервісів

datamodel

3.6. Ініціалізація компонентів реєстру

Ініціалізація компонентів, необхідних для розгортання регламенту (Citus, Redash, Keycloak і т.д.).

3.7. Створення схеми БД

Встановлення схеми бази даних регламенту засобами бібліотеки Liquibase.

3.8. Створення проєктів дата сервісів

Створення проєктів у реєстровому Gerrit для зберігання згенерованого коду дата сервісів.

3.9. Створення пайплайнів

Створення пайплайнів дата сервісів у реєстровому Jenkins.

3.10. Клонування проєктів

Клонування проєктів із реєстрового Gerrit-а на Jenkins агент.

3.11. Генерування коду проєктів

Генерування коду дата сервісів у склоновані проєкти.

3.12. Вивантаження коду проєктів

Вивантаження згенерованого коду в реєстровий Gerrit.

3.13. Білд коду проєктів

Запуск білд пайплайнів дата сервісів. Результатом роботи пайплайнів є зібрані артифакти дата сервісів, що вивантажуються в реєстровий Nexus, а також Docker імеджі (що містять артифакти та всі залежності), які вивантажуються в реєстровий Nexus Docker Registry.

3.14. Деплой дата сервісів

Розгортання Helm charts дата сервісів у реєстровому неймспейсі засобами Helm на основі Docker імеджів, отриманих в результаті роботи білд пайплайнів.

3.15. Видалення регламенту

Пайплайн розгортання дата моделі, а також пайплайни розгортання дата сервісів мають відповідні Delete-release пайплайни для видалення. Запуск cleanup-job тригерить запуск цих пайплайнів. В результаті усі дата компоненти повністю видаляються, БД реєстру очищається, пайплайн розгортання реєстру (як і пайплайн розгортання дата моделі) перестворюється.

deleteRelease

3.16. Історія змін даних

historyExcerptor

3.17. Валідація введених даних

Перевірка того, що введена назва таблиці існує в БД, перевірка формату введеного UUID таблиці.

3.18. Створення OpenShift job

Створення OpenShift job для генерування витягу на основі введених назви та UUID таблиці.

3.19. Генерування витягу

Створення витягу історії змін даних і прикріплення до Jenkins пайплайна лінки для можливості завантаження витягу у форматі PDF.