Как стать автором
Обновить

Организация работы с репозиториями

Время на прочтение 2 мин
Количество просмотров 2.9K
цели:
— организация непрерывного внедрение нового функционала проекта
— связанная система исправления багов в процессе поддержки проекта
— повышение качества проекта в целом
— атомарность разработки отдельных частей проекта (модули / функции)

Для достижения описанных выше целей необходимо организовать следующую структуру веток:
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)
Теги:
Хабы:
+38
Комментарии 20
Комментарии Комментарии 20

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн