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

цели: — организация постоянного внедрения нового функционала проекта — сопутствующая система исправления ошибок при поддержке проекта — улучшение качества проекта в целом — атомарность разработки отдельных частей проекта (модулей/функций) Для достижения описанных выше целей необходимо организовать следующую отраслевую структуру: выпускать исправления (необязательно) тестирование исправления (необязательно) по умолчанию ветки разработчиков (условное название) 1. Релиз Эта ветка содержит текущую рабочую копию проекта, из которой проект развертывается на производственный сервер.

2.Исправления Ни для кого не секрет, что после выхода проекта на продакшн-сервер могут появиться неожиданные ошибки, чаще всего это мелкие недостатки; если ошибка действительно незначительная, то допускается прямое редактирование в ветке Release, но если правка нетривиальная, то следует сделать так: a создать ветку из ветки Release (имя ветки должно иметь префикс hotfixes_, например: hotfixes_calls) б исправить ошибку.

c переключиться на ветку Release получать в ветку Release все правки из ветки с исправленной ошибкой.

Электронный тест (если возможно) f обновить рабочий сервер из ветки Release g увеличить значение версии тега на 1 (например: было 1.0.0, теперь 1.0.1) 3 Тестирование Эта ветка содержит новые функции, которые должны быть включены в следующую версию проекта.

Для этой ветки должна быть отдельная среда, максимально приближенная к боевой обстановке, Код в этой теме активно тестируется.

При выявлении каких-либо ошибок в коде данной ветки мы вносим правки до полного устранения сообщений об ошибках.

По завершении тестирования и исправления ошибок мы делаем следующее: переход на ветку Release b перенести все изменения из ветки тестирования в ветку выпуска.

c тест (если возможно) d обновить рабочий сервер из ветки Release 4 исправления процесс работы аналогичен процессу, описанному в разделе 2. (пример использования описан в разделе «процесс работы») 5 по умолчанию Эта ветка содержит функции проекта, которые готовы перейти на стадию тестирования.

Тема существует исключительно для того, чтобы чтобы разработчики могли протестировать функционал в целом по проекту (взаимодействие модулей от нескольких разработчиков) 6 веток разработчиков На самом деле это не ветка, это общее название всех веток, представляющих новый функционал.

Процесс работы: когда набор новых возможностей готов (и хотя бы минимально протестирован каждым программистом его функционала), и менеджер дал добро на внедрение нового функционала, далее фича сливается в дефолтную ветку (программист смотрит, как работает его функционал с другими модулями), если все в порядке, затем мы объединяем функции из ветки по умолчанию в ветку тестирования.

Впредь нежелательно появление новых функций в текущей версии.

код, находящийся в ветке тестирования, подлежит тестированию и исправлению ошибок (исправление ошибок происходит в том же порядке, что и в случае с хотфиксами, только для исправления существенных ошибок ветки называются просто fixes_, например fixes_calls) После того, как шеф QA подтвердил, что код готов к работе на производственном сервере, мы сливаем изменения из тестирования в релиз.

Мы отмечаем текущую версию, поступившую в производство.

(например: было 1.0.640 стало 1.1.0) Теги: #Mercurial #git #scm #Разработка сайтов

Вместе с данным постом часто просматривают: