Забезпечення одночасної роботи декількох користувачів над однією версію-кандидатом
Основні принципи існуючого рішення
-
Один локальний репозиторій для всіх користувачів в розрізі однієї версії-кандидату
-
Scheduled job для актуалізації даних
Проблеми існуючого рішення
-
Втрата внесених змін користувачами при одночасній роботі декількох користувачів над однією сутністю в рамках однієї версії-кандидату
-
Можлива неконсистентність файлів на файловій системі в момент виконання git операцій (наприклад
git rebase) при одночасній роботі декількох екземплярів admin-portal backend сервісу з одним persistent volume -
В разі необхідності горизонтального маштабування backend сервісу, Java based synchronisation відбувається лише на рівні одного екземпляру admin-portal backend сервісу.
Варіанти вирішення проблеми
Вирішення проблеми
Основні принципи
-
Локальний репозиторій per version candidate (спільний репозиторій для всіх користувачів, що працюють над однією версією-кандидатом)
-
Доступ до файлів та їх зміна відбувається через java service, що використовує програмний Lock для синхронізації доступу до конфігурації регламенту реєстру (операції по зміні файлів на файловій системі та git commands)
-
Rebase (актуалізація змін) відносно master branch відбувається в gerrit для кожного MR, що відповідаю версії-кандидату регламенту реєстру. Процес актуалізації запускається періодично (періодичність конфігурується в property file).
-
Актуалізація змін в репозиторії на файловій системі відбувається періодично (періодичність конфігурується в property file). Актуалізація відбувається тільки якщо присутні нові зміни в remote ref.
| Періодичність актуалізації даних не забезпечує миттєве отримання змін після їх внесення в master версію. При виникненні необхідності ініціювання актуалізації даних користувачем, функціонал може бути розшірену шляхом ініціювання виклику Synchronisation service через admin portal RestAPI (по натисканню відповідної кнопки на GUI). |
-
Для уникнення затирання змін між користувачами використовується optimistic locking на рівні RestAPI. При спрацюванні optimistic lock користувачу буде сповіщено про те, що регламент entity була змінена іншим користувачем і потребує оновлення перед внесенням змін. Збереження змін користувача на сервері при цьобму не відбувається.