Організація роботи зі сховищами

цілі:

- організація безперервного впровадження нового функціоналу проекту

- пов'язана система виправлення багів у процесі підтримки проекту

- підвищення якості проекту в цілому

- Атомна розробка окремих частин проекту (модулі/функції)

Для досягнення описаних вище цілей необхідно організувати наступну структуру гілок:

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)