Правила работы с репозиторием

В проекте действуют определенные правила работы с репозиторием:

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’ом необходимо руководствоваться данной схемой.