Перегляд та управління налаштуваннями версії-кандидата
- 1. Загальний опис
- 2. Перегляд переліку внесених змін
- 3. Оновлення та актуалізація стану відкритих запитів на внесення змін
- 4. Інформація про конфліктні зміни відносно майстер-версії
- 5. Відкат окремих складових версії-кандидату до майстер-версії для усунення конфліктів
- 6. Застосування змін до майстер-версії
- 7. Відкликання запита на внесення змін в рамках версії-кандидата
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. |
1. Загальний опис
В результаті створення нової версії-кандидата на внесення змін до регламенту реєстру, можна переглянути її стан та налаштування.
Знайти нову версію-кандидат можна у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.
При створенні версії, адміністратор регламенту може переглянути дату та час створення, а також опис зміни.
- Також адміністратор регламенту може:
2. Перегляд переліку внесених змін
В Кабінетів адміністратора регламентів можна легко переглядати перелік внесених змін.
Для того, щоб переглянути внесені зміни до версії-кандидата, необхідно:
-
Перейти до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.
-
Знайти секцію
Внесені зміни
. -
Розгорнути категорію змін. Наприклад,
Моделі бізнес-процесів
. -
Переглянути файли, до яких внесено зміни.
3. Оновлення та актуалізація стану відкритих запитів на внесення змін
Для постійної синхронізації майстер-версії з усіма версіями-кандидатами та актуалізації стану відкритих запитів згідно з останньою майстер-версією, система автоматично оновлює усі відкриті запити (версії-кандидати) на внесення змін. |
Також адміністратор регламенту час від часу може оновлювати свою версію-кандидат в ручному режимі. Зробити це можна наступним чином:
-
Перейдіть до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.
-
Натисніть кнопку
Отримати оновлення
.
4. Інформація про конфліктні зміни відносно майстер-версії
4.1. Функціональні можливості
- Огляд версії-кандидата та виявлення конфліктів:
-
Розробник регламенту має змогу перевірити наявність конфліктних змін відносно майстер-версії на сторінці Огляд версії, у розділі Внесені зміни.
Натисніть
Отримати оновлення
, щоб дізнатися, чи є конфлікти. - Індикація змін у складових регламенту:
-
Поруч із назвою змінених файлів у різних складових регламенту, зокрема Моделі бізнес-процесів, Відображення у кабінетах, Форми бізнес-процесів та Структура таблиць БД, розробник може побачити:
-
Зелену іконку, коли зміни не конфліктують з майстер-версією.
-
Помаранчеву іконку, коли виявлено конфліктні зміни.
Індикатори конфліктних змін показані на момент останнього оновлення.
-
- Взаємодія з іконками:
-
При наведенні курсором на іконки, користувач отримує зрозумілі підказки:
-
Зелена іконка:
Конфліктів не виявлено
. -
Помаранчева іконка:
Знайдено конфлікти
.
-
- Виділення конфліктних складових:
-
Якщо деяка складова регламенту містить конфліктні зміни, помаранчева іконка також відображається поруч з назвою цієї складової, незалежно від того, в згорнутому чи розгорнутому вигляді вона знаходиться. Конфліктні зміни автоматично відображаються у розгорнутому вигляді.
- Додаткова інформація про версію:
-
У розділі із назвою версії-кандидата, поруч із полем Дата створення, ви можете побачити додаткове поле — Дата оновлення, яке містить інформацію про дату і час отримання останнього оновлення.
Поле Дата оновлення актуалізується щоразу після натискання кнопки
Отримати оновлення
, а також автоматично, в рамках синхронізації змін у майстер-версії з іншими версіями-кандидатами.
4.2. Сценарії конфлікту злиття та візуалізація прикладів на інтерфейсі
Конфлікт злиття — це подія, яка виникає, коли система (Git) не може автоматично вирішити відмінності в коді між двома версіями змін.
Припустімо, що є два моделювальники регламенту: моделювальник A та моделювальник Б. Обидва вони працюють над тим самим файлом коду зі сховища та намагаються внести різні зміни в цей файл в рамках своїх версій-кандидатів. Наприклад, просто змінити назву бізнес-процесу. Після внесення змін моделювальник А застосовує зміни до майстер-версії. Тепер, коли моделювальник Б намагається застосувати свої зміни над цим же файлом в рамках своєї версії-кандидата, він не може це зробити, оскільки файл уже змінено моделювальником А, а зміни злиті до майстер-гілки.
В такому випадку моделювальник Б не зможе отримати оновлення із майстер-версії через конфлікт. Шляхом до вирішення конфлікту є відкликання запита на внесення змін, тобто скасування версії-кандидата-02, та створення нового запита на внесення змін. |
5. Відкат окремих складових версії-кандидату до майстер-версії для усунення конфліктів
Адміністративний портал дозволяє відкотити (виконати rollback) зміни в окремих файлах до попереднього стану. Така опція дозволяє уникати конфліктів без необхідності видалення та перестворення версії-кандидата.
-
У розділі Огляд версії > Внесені зміни знайдіть відповідну складову, наприклад, Форми бізнес-процесів.
Навпроти назви кожного файлу є опція відкату змін —.
Опція відкату доступна незалежно від того, чи є конфліктні зміни. -
Натисніть на відповідну іконку та підтвердьте відкат змін до попереднього стану.
При підтвердженні, стан файлу повернеться до останнього оновленого стану версії-кандидата. Відповідний файл зникає із секції Внесені зміни, а конфлікт, якщо такий був, вирішується автоматично.
Якщо ви видаляєте БП у версії-кандидат, то це впливає на файл bp-grouping.yml (див. Категоризація доступних послуг у кабінетах користувачів). Якщо вам потрібно повернутися до попередньої версії, не забудьте зробити це одразу для обох файлів: того, що містить БП, та для bp-grouping.yml. |
6. Застосування змін до майстер-версії
Після виконання робіт в рамках версії-кандидата, необхідно застосувати внесені зміни до майстер-версії, щоб інші адміністратори могли бачити актуальний стан репозиторію регламенту реєстру. Для цього виконайте наступні кроки:
-
Перейдіть до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.
Перед застосуванням змін до майстер-версії, необхідно спочатку отримати оновлення -
Натисніть кнопку
Застосувати зміни до майстер-версії
. -
У вікні із попередженням підтвердьте внесення змін до майстер-версії, або закрийте його.
Ви отримаєте вікно із попередженням про підтвердження дії наступного змісту:
Будь ласка, зверніть увагу, що процес розгортання та перевірки ще не завершився або завершився з помилками. Застосування змін може призвести до помилок у майстер-версії регламенту.
Процес розгортання та перевірки — це пайплайн
MASTER-Code-review-registry-regulations
у Jenkins. Він передує процесу збірки коду та публікації змін у регламенті —MASTER-Build-registry-regulations
. Наразі адміністратор регламенту може вручну пропускати процес Code review, відразу застосовуючи зміни до майстер-гілки репозиторію.
В результаті внесені зміни потраплять до майстер-гілки, а обрана версія-кандидат автоматично видалиться зі списку версій.
7. Відкликання запита на внесення змін в рамках версії-кандидата
За потреби відкликання запита на внесення змін у власній версії-кандидаті, наприклад, при конфлікті злиття, виконайте наступні кроки:
-
Перейдіть до відповідної версії-кандидата у лівому верхньому куті сторінки, розгорнувши випадний список для управління версіями регламенту.
-
Натисніть кнопку
Відізвати
.
В результаті внесені зміни буде анульовано, а обрана версія-кандидат автоматично видалиться зі списку версій.