цілі:
- організація безперервного впровадження нового функціоналу проекту
- пов'язана система виправлення багів у процесі підтримки проекту
- підвищення якості проекту в цілому
- Атомна розробка окремих частин проекту (модулі/функції)
Для досягнення описаних вище цілей необхідно організувати наступну структуру гілок:
release
hotfixes (необов'язкова)
testing
fixes (необов'язкова)
default
developers branches (умовна назва)
1. Release
Дана гілка містить актуальну робочу копію проекту, з якої викочується проект на продакшн сервері.
2. Hotfixes
Не секрет, що після викату проекту на продакшн сервер, можуть з'явитися непередбачені баги,
найчастіше це дрібні недоробки, якщо порожній, дійсно є дрібним, то допускається правка безпосередньо
у гілці Release, якщо ж правка не тривіальна, то слід вчинити так:
a створити гілку з гілки Release (як префікс в імені гілки має бути hotfixes _, наприклад: hotfixes_calls)
b пофіксувати.
з перемкнутися на гілку Release
d отримати в гілку Release, всі правки з гілки з виправленим багом.
e протестувати (якщо це можливо)
f оновити продакшн сервер з гілки Release
g збільшує значення версії теґу на 1 (наприклад: було 1.0.0, стало 1.0.1)
3 Testing
Ця гілка містить нові фічі, які повинні потрапити в наступну версію проекту.
Під цю гілку має бути окреме оточення, максимально наближене до бойового,
код який знаходиться в даній гілці активно тестується.
при виявленні будь-яких багів, в коді даної гілки, виробляємо правки, до повного позбавлення від багрепортів.
Після закінчення тестування, і виправлення багів, виробляємо наступне:
a перемикаємося на гілку Release
b отримати в гілку Release всі правки з гілки Testing
c протестувати (якщо це можливо)
d оновити продакшн сервер з гілки Release
4 Fixes
процес роботи аналогічний процесу описаному в розділі 2. (приклад використання описано в розділі «процес роботи»)
5 Default
Дана гілка містить фічі проекту, готові до виходу на стадію testing. Гілка існує виключно для того,
щоб розробники могли протестувати функціонал в цілому, за проектом (взаємодія модулів декількох розробників)
6 Developers branches
Насправді це не гілка, це загальна назва всіх гілок які представляють з себе новий функціонал.
Процес роботи:
коли набір нових фіч готовий (і хотяби мінімально відтестований кожним програмістом свого функціоналу),
і менеджер дав добро на викат нового функціоналу, то відбувається злиття фічі в гілку default
(програміст дивиться як його функціонал працює з іншими додатками), якщо все добре,
то зливаємо фічі з гілки default у гілку testing. з цього моменту не бажана поява нових фіч у текушому релізі.
код який знаходиться в гілці testing піддається тестуванню, виправленню багів
(виправлення багів відбувається в такому ж порядку як і у випадку з hotfixes, тільки для виправлення істотних багів
застосовується імена гілок просто fixes _, наприклад fixes_calls)
після того як головний QA, підтвердив готовність коду до роботи на продакшн сервері, зливаємо зміни з testing в release.
поточну версію, що потрапила в продакшн тегуємо. (наприклад: було 1.0.640 стало 1.1.0)