Окремий репозиторій на файловій системі для кожного користувача в розрізі кожної версії-кандидату. Окремий репозиторій для перегляду інформації про конфлікти.

Основні сутності, використанні при побудові рішення

  • Scheduled jobs

  • Зміни, що ініційовані адміністратором регламенту реєстру

  • Репозиторії та бранчі на файловій системі

  • Репозиторії та бранчі в Gerrit

Огляд переліку репозиторіїв на файловій системі та переліку scheduled jobs

git summary

Іменування репозиторіїв та бранчів має наступний формат:

  • vc1 - версія-кандидат 1

  • vc1u1 - репозиторій версії-кандидату 1 для користувача 1

  • MR1 - Merge request для версії-кандидату 1

  • vc1u1_merge - _merge репозиторій для репозиторію vc1u1

Репозиторії на файловій системі розподілені на декілька груп (spaces):

  • User changes space: репозиторії для збереження змін від певного користувача в рамках змін певної версії-кандидату

  • Version candidate space: репозиторії для збереження всіх змін для певної версії-кандидату

  • Gerrit MR space: репозиторії для забезпечення оновлення Merge Request в Gerrit до актуального стану відносно репозиторіїв файлової системи

  • Backup space: резервне збереження змін з репозиторіїв файлової системи в будь-який git сервіс

  • MR Zone: Merge

Основні принципи організації роботи з локальними репозиторіями на файловій системі

  • Кожна група може мати певну кількість локальних репозиторіїв (git clone)

  • Кожен репозиторій на файловій системі може оперувати одним або більше git branch

  • В репозиторіях, зміни в котрих можуть мати конфлікти, винесені в окремі локальні репозиторії с суфіксом _merge

Changes Push flow: отримання та збереження змін

git push flow

  • Адміністратор регламенту реєстру отримує та зберігає зміни шляхом взаємодії з відповідним локальним репозиторієм в User changes space

  • Адміністратор регламенту реєстру отримує інформацію про конфлікти з окремого відповідного репозиторію на файловій системі ( _merge репозиторій)

  • Адміністратор регламенту реєстру отримує метадані про версію-кандидат з Gerrit MR

Changes synchronisation flow: синхронізація змін між локальними репозиторіями та отримання переліку конфліктних змін

git sync flow

  • Кожен репозиторій, який може бути актуалізований змінами з другого репозиторію, має додатковий репозиторій, через який виконується актуалізація змін ( _merge репозиторій)

  • _merge репозиторій оновлюється періодично in scheduled manner.

  • Якщо _merge репозиторій не має конфліктів, то відповідний user changes репозиторій є успішно актуалізованим

  • Якщо _merge репозиторій має конфлікти, то відповідний user changes репозиторій є успішно актуалізованим до стану, коли зміни користувача не конфліктували зі змінами в версії-кандидаті (на момент визову synchronisation job)

Можна виділити окремий компонент для забезпечення sync функціональності - Changes Synchronisation Task
git sync component

  • В механізмі задіяні три git репозиторії:

    • local - branch на локальній файловій системі, в котрий можуть вноситись зміни

    • remote - віддалений branch, котрий використовується як remote origin для local репозиторію

    • local_merge - branch що використовується для отримання інформації про конфлікти між local та remote репозиторіями

Механізм не лімітує розділення бранчів між репозиторіями. Наприклад бранчі local та remote можуть знаходитись в одному локальному репозиторії.

Backup flow: резервне збереження репозиторіїв в remote git

git backup flow
Для забезпечення резервного копіювання змін з user changes space буде використовуватись remote git (gerrit). Механізм резервного копіювання може бути сконфігурований на використання будь-якого git instance (включаючи будь-який git applicable транспорт протокол)

  • Технічно backup механізм це виклик git push backup <branch name>, якщо backup remote origin заданий в репозиторії

  • Один backup job instance буде забезпечувати backup всіх репозиторіїв

Squash flow: синхронізація змін в Gerrit

git squash flow

Squash flow забезпечує оновлення Merge Request в Gerrit згідно змінам м відповідному локальному репозиторії в Version candidate space

  • Оновлення змін відбувається в односторонньому порядку (з локального репозиторію в MR)

  • Всі зміни, що були зроблені в локальному репозиторії version candidate space в декількох окремих commit, будуть об’єднані в один commit

  • Під час оновлення відбувається git commot --amend. Якщо MR буде мати зміни, що не є частиною змін з локального репозиторію, вони будуть втрачені під час ції операції

Cleanup flow: видалення репозиторіїв, робота з якими завершена

git cleanup flow

Repository spaces та remote repositories, що потребують housekeeping

  • user changes space

  • version candidate changes space

  • squash space

  • backup space (remote branches)

TODO: алгоритм отримання переліку репозиторіїв, що потребують видалення, буде розробелно окремо
Need to invent mechanism how to synchronise cleanup job, sync job and backup job

Pros

  • Механізм максимально переносить в Scheduled Jobs дії з локальними репозиторіями, що не потребують виконання під час синхронного виклику від користувача

  • Механізм двозволяє ідентифікувати 2 рівни конфліктів:

    • Конфлікти версії-кандидату відносно мастер-версії

    • Конфлікти між користувачами, що вносять зміни в рамках однієї мастер-версії

  • Можливе використання non-persistent layer, що дозволить маштабувати admin-portlal backend сервіс

Cons

  • Складність розробки

  • Для забезпечення миттєвого відображення змін (not in scheduled manner) необхідно забезпечити додатково можливість Event based механізму виклику обробки більшості з scheduled jobs. Може бути використано Custom Spring Events.