Версіонування дата фабрики

1. Структура версій

Версія складається з трьох розрядів

1 - нова версія платформи
2 - мажорні зміни - зміни стосуються моделі даних
3 - мінорна версія

1.1.0 - перша версія регламента
1.1.1 - версія з новими звітами, валідаційними правилами
1.2.0 - версія в якій додані нові таблиці
2.0.0 - попередня версія, але згенерована з використанням нової версії платформи

Оскільки для Дата Фабрики значушими є тільки перші два розряди то в середині фабрики для версіонування використовуються тільки вони

2. Версіонування репозиторіїв

Для забезпечення відслідковування змін/еволюції регламентів кожна критична зміна зберігається в окремому репозиторії з суфіксом версії. Всі три компоненти мають бути узгоджені - використовувати ту саму версію.

Приклад:

labaratory-rest-api-1.0
labaratory-kafka-api-1.0
labaratory-model-1.0

labaratory-rest-api-1.1
labaratory-kafka-api-1.1
labaratory-model-1.1

3. Версіонування артефактів

Всі артіфакти після компіляції відправляються в nexus. Версіонування відбувається в рамках group id та artifact id. В image registry артіфакти викоритовують той самий image stream.

4. Версіонування БД

Об’єкти які не містять дані такі як searchCondition перестворюються. Таблиці з даними мігруються відповідними інструментами liquibase

Для зміни дата вмістних структур дозволяється додавання колонок до існуючих таблиць. У такому випадку операційна таблиця буде змінена. Поточна історична таблиця буде збережена з вказанням версії регламенту, а для нової версії буде створена нова історична таблиця до якої буде зкопійовано останні записи пов’язані з усіма існуючими записами операційної таблиці. Данна міграція відбувається на рівні БД.

Приклад:
Додавання телефону до таблиці сертифікованих лабараторій

<addColumn tableName="laboratory" >
  <column name="phone_number" type="varchar(7)"/>
</addColumn>

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

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

При необхідності видалення колонки з таблиці маює бути створена нова таблиця без відповідної колонки, а дані повторно завантажені

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

Модифікація типів та накладання додаткових constrains можливе якщо не вимагає модифікацію даних при цьому.

Приклад: Розширення кількості доступних символів для колонки phone_number.

<modifyDataType
        columnName="phone_number"
        newDataType="varchar(255)"
        tableName="laboratory"/>

5. Версіонування черг

Для відслідковування версійності черг та структур даних які були асоційовані з даною версією черг до назви черг має додаватись перші два розряди

Приклад:

create-labaratory-1.0-inbound
create-labaratory-1.0-outbound
create-labaratory-1.0-outbound.DLT

create-labaratory-1.1-inbound
create-labaratory-1.1-outbound

6. Версіонування сервісів розгортання (Deployments)

Розгорнутим в реєстрі одночасно може бути тільки одна версія окремого регламенту. Для забезпечення версіонування та змін регламенту кожна наступна версія розгортається як Helm chart з новою версією контейнера (image). Версія також проставляється в якості додаткового ярлика (label) в кожному ресурсі K8s що створюється за допомогою цього Helm chart.

Приклад:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}-deployment
  labels:
    app: {{.Values.name}}
    version: {{ .Values.version }}
spec:
  replicas: ...
  selector:
    matchLabels:
      app: {{ .Values.name }}
      version: {{ .Values.version }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
        version: {{ .Values.version }}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: labaratory-rest-api-deployment
  labels:
    app: labaratory-rest-api
    version: "1.0"
spec:
  replicas: ...
  selector:
    matchLabels:
      app: labaratory-rest-api
      version: "1.0"
  template:
    metadata:
      labels:
        app: labaratory-rest-api
        version: "1.0"