Система адміністрування регламенту реєстру [WIP]
Ключові вимоги
-
Пришвидшити розробку регламентів типових реєстрів
-
Знизити вимоги до кваліфікації команди моделювання регламентів типових реєстрів
-
Виключити необхідність встановлення додаткового ПЗ на локальній машині для початку розробки регламенту
-
Централізувати розробку та адміністрування усіх складових регламенту реєстру у єдиному інтерфейсі
-
Уніфікувати процес автентифікації посадових осіб / адміністраторів регламенту за допомогою КЕП
-
Забезпечити можливості ведення паралельної розробки декількох послуг реєстру
-
Забезпечити можливості ведення паралельної розробки послуги реєстру декількома розробниками одночасно
-
Забезпечити можливості актуалізації стану регламенту згідно останніх внесених змін для послуги у процесі розробки
-
Забезпечити можливості тестування та демонстрації послуг у процесі розробки з використанням анонімізованих даних реєстру
-
Забезпечити можливості перегляду, тестування та демонстрації останньої версії-кандидата регламенту реєстру
-
Забезпечити цілісність регламенту реєстру у процесі розробки
-
Забезпечити автоматизовану перевірку якості внесених змін до регламенту
-
Забезпечити процес інспекції внесених змін до регламенту
-
Візуалізувати історію внесення змін до регламенту та випуску оновлень
-
Забезпечити можливості внесення змін у вигляді коду до складних регламентів командою розробки через службові інтерфейси
-
Забезпечити можливості автоматичного та напівавтоматичного випуску оновлень регламенту реєстру
-
Забезпечити можливості відтворення дефектів з промислового оточення та випуску оновлень з виправленнями
-
Унеможливити внесення прямих змін до регламенту на промисловому оточенні
-
Забезпечити створення резервної копії регламенту при випуску оновлень
-
Забезпечити можливість відновлення регламенту з резервної копії
Базові принципи
-
Розробка регламенту реєстру відбувається з використанням адміністративного порталу, що дозволяє будувати конфігурацію типового регламенту реєстру. Інтерфейс адміністративного порталу дозволяє виконувати всю необхідну конфігурацію регламенту реєстру без володіння глибокими уміннями програмування.
-
Розробка регламенту реєстру ведеться шляхом створення версій-кандидатів регламенту реєстру, що містять зміни до регламенту реєстру.
-
Одна версія-кандидат регламенту реєстру може розроблятися декількома користувачами одночасно.
-
Можлива розробка декількох версій-кандидатів одночасно.
-
Версія кандидат регламенту реєстру має містити відповідні автоматизовані сценарії тестування внесених змін. Дані сценарії виконуються автоматизовано в Jenkins pipeline регламенту реєстру. Результат виконання відображається в адмін порталі.
-
Можливість автоматичного та напівавтоматичного випуску оновлень буде досягнута шляхом конфігурації існуючого механізму просування змін між оточеннями з використанням ControlPlane. Автоматичний випуск оновлень в якості показника працездатності версії буде використовувати автоматизовані сценарії тестування.
-
Існує можливість розгортання тимчасового реєстру по регламенту з версії-кандидату для перевірки внесених змін. Під час цього використовується тимчасовий тенант-реєстр з розгорнутою лише операційною зоною. Кількість тимчасових тенант-реєстрів, працюючих одночасно, обмежена.
-
При розгортанні тимчасового тенант оточення використовується механізм анонімізації даних, отриманих с промислового оточення.
-
Окремо існуючий backup тенант в prod оточенні буде завжди містити останню версію змін з мастер версії регламенту реєстру.
-
Всі зміни що вносяться до регламенту реєстру повинні пройти всі етапи тестування, що передбачені процесом релізу.
-
Hotfixes можуть відбуватись на staging оточенні. Такі ж самі зміни повинні бути виконані на development оточенні.
-
Можливість внесення змін по деяких частинах регламенту реєстру може обмежена для об’єктів, що були створені поза межами поточної версії-кандидату регламенту реєстру. Об’єкти, що були створені в рамках поточної версії-кандидату регламенту реєстру можуть бути змінені без обмежень.
-
Адмін портал дозволяє переглядати зміни версії-кандидату відносно мастер версії регламенту реєстру.
-
Адмін портал дозволяє проводити актуалізацію версії конфігураційних файлів по мастер версії шляхом виконання rebase операції в git.
-
Зміни, що внесені без використання адмін порталу можуть не відображатись в історії змін версії кандидату регламенту реєстру.
-
Під час роботи над версією-кандидатом регламенту реєстру можливе внесення змін в конфігураційні файли регламенту реєстру без використання адмін порталу.
-
Конфлікти змін в конфігураційних файлах будуть вирішуватись з використанням gerrit/git.
-
Резервне копіювання стану реєстру відбувається в момент зміни стану регламенту реєстру. Резервне копіювання складається з двох частин:
-
Збереження версії регламенту реєстру шляхом створення тегів в git
-
Резервне копіювання БД
-
-
Відтворення дефектів на тимчасовому тенант оточенні можливе шляхом розгортання відповідної версії регламенту реєстру використовуючи tag в git та відтворення стану БД с резервної копії
Технічний дизайн рішення
|
Регламент реєстру
На даній структурній діаграмі представлено складові частини регламенту реєстру, можливості управління якими надає інтерфейс користувача Системи Адміністрування Регламенту Реєстру.
CI/CD регламенту реєстру
У даному розділі представлено підходи до побудови CI/CD пайплайну для випуску оновлень регламенту реєстру з акцентом на наступних аспектах:
-
Розробка нових послуг
-
Виправлення дефектів
-
Тестування змін
-
Промоція оновлення
-
Blue/Green підхід до оновлення промислового екземпляра реєстру
Тактичний підхід
Для побудови CI/CD регламенту використовуються наступні визначення ролей для екземплярів реєстру:
-
Development:
-
Розробка нових послуг відбувається за допомогою запитів на внесення змін та формування версій-кандидатів реєстру
-
Портування виправлень до регламенту, який розгорнуто на Staging та Production оточеннях відбувається за допомогою створення запитів на внесення змін та формування версій-кандидатів реєстру
-
Тестування нових послуг та портованих виправлень до регламенту відбувається на окремих кандидат-тенантах реєстру, які автоматично створюються для версій-кандидатів на базі запитів на внесення змін
-
Усі зміни, які вносяться у мастер-версію регламенту реєстру мають відповідати критеріям сумісності з розгорнутими змінами на Staging та Production оточеннях
-
Мастер-версія регламенту реєстру має відповідати критеріям стабільності та якості для проведення тестування версії-кандидата на мастер-тенанті реєстру
-
-
Staging:
-
Внесення виправлень до регламенту відбувається за допомогою запитів на внесення змін та формування версій-кандидатів реєстру
-
Тестування виправлень до регламенту відбувається на окремих кандидат-тенантах реєстру, які автоматично створюються для версій-кандидатів на базі запитів на внесення змін
-
Усі зміни, які вносяться у мастер-версію регламенту реєстру мають відповідати критеріям сумісності з розгорнутими змінами на Production оточенні
-
Усі виправлення, які вносяться у мастер-версію регламенту мають бути портовані на мастер-версію Development екземпляра реєстру
-
Мастер-версія регламенту реєстру має відповідати критеріям стабільності та якості для проведення тестування версії-кандидата на мастер-тенанті реєстру
-
-
Production:
-
Headless Адміністративні сервіси реєстру без інтерфейсу користувача
-
При оновленні версії регламенту реєстру, автоматично створюється копія реєстру для забезпечення Blue/Green підходу до встановлення
-
Суттєвим недоліком підходу є відсутність можливості проводити тестування нової версії регламенту на Staging оточенні та вносити виправлення / оновлювати Production реєстр. |
Технологічний стек рішення
Розділ у процесі доповнення |
Технологія / Бібліотека | Версія | Ліцензія | Документація | Опис |
---|---|---|---|---|
Бекенд |
||||
11 |
Об’єктно орієнтована мова програмування |
|||
1.15 |
Компільована мова програмування із вбудованими засобами для паралельних обчислень і засобами віддаленого керування пакунками |
|||
3.0 |
Об’єктно орієнтована динамічна мова програмування, що працює в середовищі JRE |
|||
2.6.7 |
Розширення до Spring Framework для спрощення побудови аплікацій на базі Spring технологічного стеку за рахунок автоматичної конфігурації та стартерів |
|||
2021.0.0 |
Фреймворк для реалізації типових паттернів побудови надійних розподілених систем |
|||
7.13.0 |
Рішення для автоматизованого розгортання та виконання бізнес-процесів описаних у BPMN нотації та DMN бізнес-правил |
|||
4.12.0 |
Технологія управління міграціями бази даних |
|||
3.0.15 |
Бібліотека для задання шаблонів документів |
|||
2.3.31 |
Обробник шаблонів документів з використанням Java |
|||
15.1.1 |
TBD |
TBD |
TBD |
|
6.1.0.202203080745-r |
Бібліотека для роботи з git з використанням Java |
|||
0.9.4 |
Бібліотека для роботи з gerrit з використанням Java |
|||
… |
… |
… |
… |
|
Фронтенд |
||||
4.1.6 |
Apache 2.0 |
TypeScript мова програмування, яка розширяє можливості JavaScript |
||
17.0.2 |
MIT |
Бібліотека JavaScript для створення інтерфейсів користувача |
||
4.1.2 |
MIT |
Бібліотека Redux використовується для управлінням загальним даними в клієнтському застосунку |
||
1.2.0 |
MIT |
Проміжне програмне забезпечення на основі RxJS для Redux. redux-observable допомагає в створенні та скасуванні асинхронних дій для побічних ефектів |
||
6.6.7 |
Apache 2.0 |
RxJS — це бібліотека для реактивного програмування з використанням Observables |
||
4.13.12 |
MIT |
Form.io це комбінована платформа керування формами та даними для прогресивних веб-додатків на основі форм |
||
4.11.4 |
MIT |
Бібліотека UI компонентів |
||
9.1.0 |
Бібліотека bpmn-js допомагає взаємодіяти з BPMN діаграмами у браузері |
|||
1.1.1 |
MIT |
Бібліотека bpmn-js-properties-panel дає можливість редагувати технічні властивості BPMN |
||
0.0.5 |
MIT |
Бібліотека element-template-chooser дає можливість працювати з типовими розширення каталогу моделювання, розроблених у вигляді Element Templates |
||
6.1.2 |
MIT |
Бібліотека camunda-bpmn-moddle визначає розширення простору імен Camunda для BPMN 2.0 XML |
||
6.0.3 |
MIT |
WYSIWYG-редактор (What You See Is What You Get) |
||
4.1.0 |
MIT |
Пакет для інтеграції TinyMCE з React |
||
4.4.5 |
MIT |
Monaco Editor — це редактор коду, який підтримує VS Code. |
||
2.0.2 |
MIT |
Пакет для підключення редактора Monaco до мовних серверів |
||
1.0.1 |
MIT |
Пакет для реалізації зв’язку між клієнтом jsonrpc і сервером через WebSocket |
||
Сховища даних |
||||
12.4 |
Об’єктно реляційна система керування базами даних |
|||
4.9.8 |
Вільне сховище об’єктів, яке зберігає дані на одному розподіленому комп’ютерному кластері та забезпечує інтерфейс рівня об’єкту, блоку та файлу. |
|||
6.0 |
Розподілене сховище пар ключ-значення, які зберігаються в оперативній пам’яті |
|||
3rd-party рішення |
||||
2.2 |
Рішення для управлінням доступом до внутрішніх ресурсів, управлінню рейт-лімітами, тощо |
|||
1.10.4 |
Рішення для організації надійного транспорту між сервісами, розгорнутими на платформі оркестрації контейнерів |
|||
15.1.1 |
Система для управління користувачами та їх доступом, автентифікації, інтеграції з зовнішніми Identity провайдерами, тощо |
|||
3.0.0 |
… |
Розподілений программний брокер повідомлень |
||
1.9.7 |
Сховище для секретів, токенів, сертифікатів |
|||
8.0.2.b37747 |
Рішення для моделювання та візуалізації звітів на базі реляційних та нереляційних сховищ |
|||
2.26.2 |
Система контролю версій |
|||
3.3.2 |
Інструмент проведення перевірки коду |
|||
2.303.3 |
Сервер для організації процесів Безперервної Інтеграції та Розгортання (CI/CD) |
Глосарій
Розділ у процесі доповнення |
Термін | Опис |
---|---|
Регламент реєстру |
Цифрове представлення важливих аспектів функціонування реєстру, яке складається з декларативних описів організаційної структури, моделі даних, інформаційних та адміністративних послуг, інтеграцій з зовнішніми системами, тощо. |
Екземпляр реєстру |
Сукупність ресурсів та сервісів, які забезпечують коректне функціонування окремого реєстру по отриманню, обробці та зберіганню даних згідно розгорнутої версії цифрового регламенту. |
Екземпляр платформи |
Сукупність ресурсів та сервісів, які відповідають за управління екземплярами реєстрів, їх конфігурацією та Continuous Delivery / Deployment регламенту між екземплярами окремого реєстру. |
Операційна зона екземпляра реєстру |
Сукупність ресурсів та сервісів екземпляра реєстру, які відповідають за обслуговування запитів на надання інформаційних та адміністративних послуг. |
Адміністративна зона екземпляра реєстру |
Сукупність ресурсів та сервісів екземпляра реєстру, які відповідають за адміністрування важливих аспектів функціонування та управління цифровим регламентом реєстру. |
Інтерфейс адміністрування платформи |
Інтерфейс користувача, який постачається разом с екземпляром платформи для управління екземплярами реєстрів та є невід’ємною частиною адміністративної зони платформи. |
Інтерфейс адміністрування регламенту реєстру |
Інтерфейс користувача, який розгортається при створенні екземпляра реєстру на платформі та є невід’ємною частиною адміністративної зони реєстру. |
Службовий інтерфейс внесення складних змін до регламенту реєстру |
Інтерфейси користувача або служби, які відповідають за низькорівневе управління цифровим регламентом реєстру (Git, Gerrit, Jenkins, тощо.) та є невід’ємною частиною адміністративної зони реєстру. |
Мастер-версія регламенту |
Версія регламенту, розгорнута на окремому екземпляри реєстру, яка відповідає вимогам цілісності, стабільності, якості та сумісності відносно останньої версії, розгорнутої на промисловому оточенні. Усі зміни, які виконуються в рамках окремих запитів на внесення змін, робляться відносно стану мастер-версії. |
Запит на внесення змін до регламенту |
Логічне представлення сукупності змін відносно поточної мастер-версії регламенту, до якого застосовуються перевірки цілісності, якості та інспекції перед безпосереднім застосуванням до мастер-версії. |
Версія-кандидат регламенту |
Логічне представлення стану мастер-версії після застосування змін, сформованих в рамках відповідного запиту на внесення змін. |
Мастер-тенант реєстру |
|
Ефемерний кандидат-тенант реєстру |
|
Перевірка цілісності регламенту |
|
Перевірка якості регламенту |
|
Інспекція змін до регламенту |
|
Сумісність змін відносно мастер-версії регламенту |
|
Публікація / Застосування змін до мастер-версії регламенту |
|
Попередній перегляд / "Live Preview" версії-кандидата регламенту |
|
Development-оточення реєстру |
|
Staging-оточення реєстру |
|
Production-оточення реєстру |
|
Пайплайн промоції / оновлення версії регламенту |
|
Оновлення версії регламенту |
|
Автоматичний випуск оновлень регламенту |
|
Напівавтоматичний випуск оновлень регламенту |
|
Резервна копія регламенту |
|
Анонімізована копія даних реєстру |