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

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

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

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

Знайти нову версію-кандидат можна у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.

new admin portal 5

При створенні версії, адміністратор регламенту може переглянути дату та час створення, а також опис зміни.

new admin portal 4

2. Перегляд переліку внесених змін

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

Для того, щоб переглянути внесені зміни до версії-кандидата, необхідно:

  1. Перейти до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.

  2. Знайти секцію Внесені зміни.

  3. Розгорнути категорію змін. Наприклад, Моделі бізнес-процесів.

  4. Переглянути файли, до яких внесено зміни.

    new admin portal 9

3. Оновлення та актуалізація стану відкритих запитів на внесення змін

Для постійної синхронізації майстер-версії з усіма версіями-кандидатами та актуалізації стану відкритих запитів згідно з останньою майстер-версією, система автоматично оновлює усі відкриті запити (версії-кандидати) на внесення змін.

Також адміністратор регламенту час від часу може оновлювати свою версію-кандидат в ручному режимі. Зробити це можна наступним чином:

  1. Перейдіть до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.

  2. Натисніть кнопку Отримати оновлення.

    new admin portal 10

4. Інформація про конфліктні зміни відносно майстер-версії

4.1. Функціональні можливості

Огляд версії-кандидата та виявлення конфліктів:

Розробник регламенту має змогу перевірити наявність конфліктних змін відносно майстер-версії на сторінці Огляд версії, у розділі Внесені зміни.

Натисніть Отримати оновлення, щоб дізнатися, чи є конфлікти.

new admin portal 8 1

Індикація змін у складових регламенту:

Поруч із назвою змінених файлів у різних складових регламенту, зокрема Моделі бізнес-процесів, Відображення у кабінетах, Форми бізнес-процесів та Структура таблиць БД, розробник може побачити:

  • Зелену іконку, коли зміни не конфліктують з майстер-версією.

  • Помаранчеву іконку, коли виявлено конфліктні зміни.

    Індикатори конфліктних змін показані на момент останнього оновлення.

new admin portal 8 2

Взаємодія з іконками:

При наведенні курсором на іконки, користувач отримує зрозумілі підказки:

  • Зелена іконка: Конфліктів не виявлено.

  • Помаранчева іконка: Знайдено конфлікти.

new admin portal 8 3

Виділення конфліктних складових:

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

Додаткова інформація про версію:

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

Поле Дата оновлення актуалізується щоразу після натискання кнопки Отримати оновлення, а також автоматично, в рамках синхронізації змін у майстер-версії з іншими версіями-кандидатами.

4.2. Сценарії конфлікту злиття та візуалізація прикладів на інтерфейсі

Конфлікт злиття — це подія, яка виникає, коли система (Git) не може автоматично вирішити відмінності в коді між двома версіями змін.

Приклад 1. Сценарій конфлікту злиття

Припустімо, що є два моделювальники регламенту: моделювальник A та моделювальник Б. Обидва вони працюють над тим самим файлом коду зі сховища та намагаються внести різні зміни в цей файл в рамках своїх версій-кандидатів. Наприклад, просто змінити назву бізнес-процесу. Після внесення змін моделювальник А застосовує зміни до майстер-версії. Тепер, коли моделювальник Б намагається застосувати свої зміни над цим же файлом в рамках своєї версії-кандидата, він не може це зробити, оскільки файл уже змінено моделювальником А, а зміни злиті до майстер-гілки.

Приклад 2. Внесення змін до моделі бізнес-процесів моделювальником А у версії-кандидаті-01

new admin portal 7

Приклад 3. Приклад. Оновлення версії-кандидата-01 та застосування змін до майстер-версії моделювальником А

new admin portal 11

Приклад 4. Оновлення версії-кандидата-02 та застосування змін до майстер-версії моделювальником Б

new admin portal 8

В такому випадку моделювальник Б не зможе отримати оновлення із майстер-версії через конфлікт. Шляхом до вирішення конфлікту є відкликання запита на внесення змін, тобто скасування версії-кандидата-02, та створення нового запита на внесення змін.

5. Відкат окремих складових версії-кандидату до майстер-версії для усунення конфліктів

Адміністративний портал дозволяє відкотити (виконати rollback) зміни в окремих файлах до попереднього стану. Така опція дозволяє уникати конфліктів без необхідності видалення та перестворення версії-кандидата.

  1. У розділі Огляд версії > Внесені зміни знайдіть відповідну складову, наприклад, Форми бізнес-процесів.
    Навпроти назви кожного файлу є опція відкату змін — rollback.

    new admin portal 8 4

    Опція відкату доступна незалежно від того, чи є конфліктні зміни.
  2. Натисніть на відповідну іконку та підтвердьте відкат змін до попереднього стану.

    new admin portal 8 5

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

    new admin portal 8 6

Якщо ви видаляєте БП у версії-кандидат, то це впливає на файл bp-grouping.yml (див. Категоризація доступних послуг у кабінетах користувачів). Якщо вам потрібно повернутися до попередньої версії, не забудьте зробити це одразу для обох файлів: того, що містить БП, та для bp-grouping.yml.

6. Застосування змін до майстер-версії

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

  1. Перейдіть до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.

    Перед застосуванням змін до майстер-версії, необхідно спочатку отримати оновлення
  2. Натисніть кнопку Застосувати зміни до майстер-версії.

    new admin portal 11

  3. У вікні із попередженням підтвердьте внесення змін до майстер-версії, або закрийте його.

    new admin portal 11 1

    Ви отримаєте вікно із попередженням про підтвердження дії наступного змісту:

    Будь ласка, зверніть увагу, що процес розгортання та перевірки ще не завершився або завершився з помилками. Застосування змін може призвести до помилок у майстер-версії регламенту.

    Процес розгортання та перевірки — це пайплайн MASTER-Code-review-registry-regulations у Jenkins. Він передує процесу збірки коду та публікації змін у регламенті — MASTER-Build-registry-regulations. Наразі адміністратор регламенту може вручну пропускати процес Code review, відразу застосовуючи зміни до майстер-гілки репозиторію.

В результаті внесені зміни потраплять до майстер-гілки, а обрана версія-кандидат автоматично видалиться зі списку версій.

7. Відкликання запита на внесення змін в рамках версії-кандидата

За потреби відкликання запита на внесення змін у власній версії-кандидаті, наприклад, при конфлікті злиття, виконайте наступні кроки:

  1. Перейдіть до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.

  2. Натисніть кнопку Відізвати.

    new admin portal 12

В результаті внесені зміни буде анульовано, а обрана версія-кандидат автоматично видалиться зі списку версій.

© 2023 Платформа Реєстрів.