Відмова від збереження попередніх версій сервісів API фабрики даних

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Загальний опис

Наразі, при розгортанні регламенту реєстру, зберігається код та docker образи всіх попередніх версій API даних. Також від розробника реєстру вимагається змінювати версію регламенту кожен раз коли він змінює модель даних.

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

2. Актори та ролі користувачів

  • Розробник регламенту

  • Адміністратор реєстру

3. Загальні принципи та положення

  • В реєстровому gerrit зберігаються тільки останні версії згенерованих сервісів API даних.

  • Пайплайни для збірки сервісів існують в одному екземплярі на кожен сервіс. Для окремих версій пайплайни не створюються.

  • В реєстровому nexus зберігаються тільки останні версії згенерованих сервісів API даних.

  • В kafka видаляються теми (topics) які не використовуються останньою версією API.

  • Обов’язкова зміна версії регламенту скасовується.

4. Функціональні сценарії

  • Розробка моделі даних реєстру

  • Розгортання регламенту реєстру

5. Поточна реалізація

Розгортання моделі даних регламенту реєстру
Зображення 1. Розгортання моделі даних регламенту реєстру

6. Цільовий дизайн

Розгортання реєстру та моделі даних регламенту реєстру
Зображення 2. Розгортання реєстру та моделі даних регламенту реєстру
Має сенс розглянути можливість не виносити створення codebase та пайплайнів API даних в пайплайн розгортання реєстру. Їх створення може залишитись в пайплайні розгортання моделі даних, за принципом "створювати якщо ще не існує". Таким чином не знадобляться зміни в процедурах створення регламенту(які в нас різні для cicd та target оточень) та створення міграційних upgrade скриптів.

6.1. Компоненти системи та їх призначення в рамках дизайну рішення

У даному розділі наведено перелік компонент системи, які задіяні або потребують змін/створення в рамках реалізації функціональних вимог згідно з технічним дизайном рішення.

Компонент Службова назва Призначення / Суть змін

JobProvisioner

jenkins-operator

Створення codebase та пайплайнів для сервісів API даних

JobProvisionerDefault

control-plane-jenkins

Створення codebase та пайплайнів для сервісів API даних

Пайплайн публікації регламенту реєстру

registry-regulations-publication-pipeline

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

Liquibase скрипти пре- та пост- розгортання моделі даних

data-model

Видалення перевірки версії регламенту

7. Моделювання регламенту реєстру

7.1. Версія регламенту

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

Адміністратору регламенту надається можливість використовувати атрибут settings.general.version в файлі налаштувань регламенту settings.yaml на власний розсуд.

Структура регламенту реєстру
Зображення 3. Структура регламенту реєстру

7.2. Міграція

Має бути створений і виконаний при оновленні реєстру міграційний скрипт який створить неверсіоновані codebases і пайплайни API даних.

Після оновлення, для очищення codebase та артефактів застарілих версій API, рекомендовано виконати процедури які застосовуються для очищення в поточної версії - cleanup пайплайн для оточень розробки та ручне очищення для промислових оточень.

8. Високорівневий план розробки

8.1. Технічні експертизи

  • DEVOPS

8.2. План розробки

  • Зміни в механізмах розгортання реєстру та публікації моделі даних регламенту

  • Актуалізація інструкцій для розробника регламенту.