Організація роботи з репозиторіями
мети:— організація безперервного впровадження нового функціоналу проекту — пов'язана система виправлення багів у процесі підтримки проекту — підвищення якості проекту загалом — атомарність розробки окремих частин проекту (модулі / функції)
Для досягнення описаних вище цілей необхідно організувати наступну структуру гілок: release hotfixes (необов'язкова) testing fixes (необов'язкова) default developers branches (умовна назва)1. ReleaseЦя гілка містить актуальну робочу копію проекту, з якої викочується проект на продакшн сервері.
2. HotfixesНе секрет, що після викату проекту на продакшн сервер можуть з'явитися непередбачені баги, найчастіше це дрібні недоробки, якщо баг, дійсно є дрібним, то допускається правка безпосередньо у гілці Release, якщо ж правка не тривіальна, слід зробити так:a створити гілку з гілки Release (як префікс в імені гілки має бути присутнім hotfixes_, наприклад: hotfixes_calls) b пофіксувати баг. c перейти на гілку 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)
Хардкорна конфа за С++. Ми запрошуємо лише профі.