Мабуть всі програмісти, які використовують гіт в тій чи іншій мірі стикались з успішною моделлю розгалуження в Git (чи з перекладом на хабрі). Дана схема чудесно працює в «гомогенному середовищі програмістів», де команда приблизно має рівний досвід, бачення коду. Що я пояснювати буду, програмісти приблизно одного рівня. Також цей підхід чудового підходить продуктовим компаніям, які добре знають роудмапу свого проекта заздалегідь і можуть вести розробку згідно цього плану. Мінусами даної схеми роботи є те, що в ній не передбачено багато бюрократичних моментів, які впливають на якісну розробку програмного забезпечення, вважаючи, що продуктові компанії людські проблеми вирішують на рівні людей. Про це можна написати окрему статтю на тему чим продуктова компанія відрізняється від аутсорсингової, але зараз не про це.
Аутсорсингові компанії зазвичай мають більше бюрократичних правил (які, чесно кажучи, оправдані), що необхідно слідувати під час розробки. Від релізу до релізу потрібно робити код рев’ю, планувати спрінти, розділяти відповідальність на групи розробників всередині команди. Такий процес провокує взаємодію між людьми. Як відомо, коли проблема стосується людей то її вирішення значно складніше і менш універсальне, чим рішення, що знаходиться в технічній сфері.
Отож як гіт може допомогти нам в код рев’ю, поділ відповідальності на групи розробників і оформлення релізів? Давайте розглянемо на прикладах. Уявимо що в нас є декілька feature-команд, що займаються розробкою нового функціоналу до уявного продукту і декілька maintenance-команд, що займаються підтримкою існуючої системи і мінорними покращеннями до продукту. На схемі 1 нижче зображено все що ми тут науявляли.
Схема 1
Звісно кожна команда створює свої гілки в основному репозиторії, там собі девелопає успішно, обмінюється комітами, але все-ж залишається гетерогенною групою програмістів. Тому перше, що варто зробити це надати кожній групі свого публічного репозиторію. Мабуть група має якогось лідера (team-lead, старший інженер). Ось його публічний репозиторій може виступати в якості групового публічного репозиторію. Відповідно ми отримуємо групи двох рівнів: старші інженери і девелопери.
Старші інтежени рулять командним репозиторієм і комітяться туди безпосередньо, а девелопери ролять клони і девелопають в своїх клонах, відправляючи мердж реквести.
Відповідно ми наближаємось до схеми диктаторів-лейтенантів, яка характерна для розробки ядра Лінукса, тільки без диктатора. Хоча позицію диктатора може займати скраміський реліз менеджер. ВІн власне буде відповідальний за оформлення релізу, вибиратиме стабільні бранчі і включатиме їх в реліз.
Якщо вас ця тема зацікавила ,залиште будь ласка відгука і я розгорну її детальніше. Маю досвід впроваждення такої схеми в проект з 15+ девелоперами в 4 командах. Такі діла.
