В проекте действуют определенные правила работы с репозиторием:
1) На каждый релиз создается своя ветка, именующая следующим образом release_yyyy.mm.dd (где yyyy – год, mm – месяц, dd - день). Данную ветку создает один из разработчиков группы dev-senior
2) Изменения попадают в ветку master только перед самым релизом, после того как ветка для релиза была полностью оттестирована. Слияние ветки master с веткой релиза производится одним из разработчиков группы dev-senior. Коммиты напрямую в ветку master запрещены
3) Ветки для разработки именуются следующим образом <аббревиатура проекта>-<номер тикета>_<краткое описание тикета(одним словом, разделение частей слова заглавной буквой, например pdfParsingWithServices)>
4) При совершении коммита необходимо в начале коммита указать номер тикета в аналогичном формате.
5) Необходимо регулярно (не реже раза в день) забирать изменения из текущей актуальной релизной ветки
6) В случае возникновения конфликтов, необходимо обратиться к разработчику –автору того кода, где они возникли.
7) Сложные конфликты может разрешать один из senior-разработчиков
2.2 Процедура добавления change request’ов
Весь процесс работы с change request’ами в проекте будет происходить в системе баг-трекинга Jira версии 5. Добавление, хранение и изменение состояний будет осуществлять с помощью выбранной системы, в строгом соответствии с распределением прав и обязанностей участников.
2.2.1 Добавление новых change request’ов
Добавление новых change request’ов происходит по трем направлениям:
1. Создание новых CR’ов, имеющих статус Bug, в ходе ручного или автоматического тестирования членами QA-команды. И дальнейшее их перенаправление на лидера команды тестирования.
2. Создание новых CR’ов, имеющих статус Task или Sub-Task, входе работы над проектом любым членом команды. В связи с необходимостью расширения функциональности системы другими разработчиками или взаимодействия с ними. Может направляться непосредственно на разработчика или на своего лидера группы, в зависимости от важности CR’а и срока сдачи зависящей от него работы.
3. Основное направление создания новых CR’ов, имеющих статус Task, Sub-Task, Improvements или New Features, после получения обновленных требований к проекту или при разработке новой функциональности системы. Добавление CR’ов данным направлением осуществляется непосредственно руководителем проекта. Руководитель проекта производит подробное описание задач и выставляет сроки их реализации. Все созданные CR’ы размещаются в свободный pool CR’ов где находятся до тех пор, пока не будут включены в список задач релиза и направлены на соответствующего разработчика.
2.2.2 Распределения change request’ов
Для описания данного раздела будем использовать следующие понятия:
· текущий релиз – релиз, над списком задач и багов которого идет работа в настоящий момент;
· следующий релиз – релиз, список задач и багов которого планируется выполнять после текущего релиза;
· заморозка кода – остановка процесса разработки и исправления багов для текущего релиза, слияние всех веток, в которых велась разработка и исправление, в релизную ветку и подготовка этой ветки к передаче на тестирование QA команде.
Распределение change request’ов, созданных руководителем проекта, к следующему релизу производится на следующий день после заморозки кода.
Также, на следующий день после заморозки кода начинается тестирование релизной ветки с последним build состоянием проекта в течение 2-3 дней. Производится полное регрессионное тестирование всего проекта и новой функциональности, в ручном и автоматическом режимах.
Параллельно с процессом тестирования происходит:
· постановка и обсуждение новых задач;
· распределение CR’ов по отделам разработки и конкретным разработчикам;
· выставляются сроки реализации, и указывается релиз, к которому готовится данная разработка;
· рассчитывается время для устранения багов;
· производятся hotfix’ы для текущего релиза, в случае необходимости.
2.2.3 Жизненный цикл change request’а
В рассматриваемом проекте change request может иметь следующие возможные состояния:
· Open – CR создан, ожидает направления на разработчика и начала работы над ним;
· In Progress – означает, что отвечающий за CR человек приступил к работе над ним;
· Resolved – работа над CR’ом завершена, ожидается проверка QA командой;
· Verified – проверка CR’а проведена, задача готова к мержу и закрытию;
· Reopened – после проверки работоспособности задачи выявлены какие-то недостатки и CR направлен обратно на доработку;
· Closed – CR считается завершенным.
Правила оформления и работы с change request’ами:
· при оформлении CR’а необходимо указывать:
ü полную информацию о реализуемых задачах или об исправляемом баге с подробным описанием;
ü заносить сведения о компонентах и версии проекта;
ü прикреплять файлы, для улучшения понимания задач;
ü дополнительную информацию, которая поможет при реализации CR’а;
· работа над CR’ом должна производиться по схеме, представленной ниже (Рис.1);
· при переходе в состояние Resolved разработчик должен оставить комментарий с указанием названия ветки, в которой производилась работа, и возможных недоработках задачи, если он осведомлен о них;
· при нахождении недостатков в реализации, тестировщик должен подробно их описать и перевести CR в состояние Reopened на соответствующего человека;
· при выполнении всех требований, поставленных в CR’е, тестировщик может перевести CR в состояние Verified, указав, что он готов к мержу в соответствующую релизную ветку;
· при получении CR’а с состоянием Verified, разработчик должен смержить свою ветку для этого CR’а в релизную, при этом правильно разрешив конфликты совместно с другим разработчиком, если они возникнут. После чего CR можно закрыть и перевести в состояние Closed.
Схема, представленная на Рис. 1, демонстрирует жизненный цикл Change Request’а, обуславливая все его возможные состояния и переходы, которые можно совершать для каждого из них. При работе над CR’ом необходимо руководствоваться данной схемой.
