4.2. Где взять задачи и как с ними работать (релиз задач по отдельности)

Инструкция предназначена для разработчиков компании СтратоСфера и описывают процесс выбора задачи и процесса работы с ней у нас.

Эта версия описывает вариант, по которому в релиз идет заранее проверенный список задач по отдельности, которые заказчик проверил на тесте и релиз формируется из выбранных заказчиком задач. В этом случае, задачи, которые не протестированы заказчиком до конца, не блокируют релиз, однако, эта схема требует от разработчиков и тестировщиков больше ресурсов по поддержке этой схемы работы.

Инструкция, описывающая альтернативный вариант, доступна в этом разделе

4.2.1. Общие положения

В небольших проектах все разработчики и постановщики выставляют и делают все задачи.

В больших проектах функциональность разделяется на части по командам, и заказчики и разработчики, чтобы снизить потребности в квалификации и уменьшить область знания, которая необходима для работы Дополнительно выделяются разработчики с повышенной квалификацией, которые делают задачи по всем командам, которые могут перераспределятся динамически в зависимости от «плавающей» потребности заказчиков по различным командам. Некоторые из разработчиков повышенной квалификации выделяются как менторы и ответственные за pull request’s каждой команды отдельно.

Заказчики создают задачи в системе redmine, разработчики берут их и выполняют поставленные требования, передают задачи на проверку. Заказчики проверяют и принимают задачи.

В системе redmine организуются под-проекты по командам (заказчиков и постановщиков) и все задачи выставляются в этих подпроектах, но при этом, общий список задач доступен в корневом проекте. В корневом проекте формируются выборки, которые отбирают задачи по состоянию следующим образом.

В выборке Бэклог отбираются задачи, для которых еще не назначен исполнитель (ожидают взятия в работу) и отсортированы таким образом, что вверх по списку поднимаются задачи с максимальным приоритетом (который определяется заказчиком). Далее, среди всех задач одного приоритета, вверх поднимаются задачи, которые были выставлены раньше всего (то есть, дольше всего ждущие в очереди)

В выборке Мои задачи отбираются задачи, назначенные на данного оператора и отсортированы таким же образом, как и в выборке «Бэклог». Это задачи, которые разработчик взял в работу и которые вернулись к нему с замечаниями от заказчика

В первую очередь, разработчик отрабатывает задачу, над которой он работает, не отвлекаясь на поступающий поток вне зависимости от приоритета.

Далее, освободившись от очередной задачи и передав ее на проверку (pull-request-а или заказчику), разработчик в первую очередь смотрит выборку «Мои задачи». И если там что-то есть (вернулось на доработку), берет первую задачу в списке и работает над ней.

Если, отработав задачу, видит, что в списке «Мои задачи» пусто, то берет очредную задачу из Бэклога и работает над ней.

Примечание

В случае закрепления за определенным под-проектом redmine, вам следует использовать отдельные ссылки для выборки «Бэклог» - уточните у вашего руководителя

Все ветки по задаче создаются от master-ветки.

После реализации задачи, все ветки после pull-request’s вливаются на проверку в ветку test на тестовый сервер. Ветка test «глухая» и код из нее никуда не включается. Время от времени она удаляется и пересоздается из master-ветки, чтобы уменьшить конфликты слияния.

Когда заказчик готов к релизу, ветки с задачей включаются в релизную ветку, которая создается от master-ветки и происходит финальное тестирование.

После завершения финального тестирования, релизная ветка включается в master и происходит обновление системы на production стенде

4.2.2. Стадии жизненного цикла задачи

Стадии жизненного цикла, через который проходит задача и как его определить

Задача ожидает взятия в работу
- Версия не заполнена
- Статус «Новая»
- Ответственный по задаче не назначен
Задачу взяли в работу и выполняют, пока не передали на проверку
- Версия не заполнена
- Статус «В работе»
- Роль назначенного «Разработчик»
Заказчик проверяет задачу на тесте
- Версия не заполнена
- Статус «На проверке»
- Роль назначенного «Заказчик»
Разработчик вносит корректировки после проверки
- Версия не заполнена
- Статус «На проверке»
- Роль назначенного «Разработчик»
Задача проверена заказчиком и ожидает включения в очередной релиз
- Версия не заполнена
- Статус задачи «Проверена, Ожидает релиз»
Задача на финальной проверке на пред-релизном стенде
- Версия заполнена и статус версии не «Закрыта»

4.2.3. Выбор задачи

Когда мы закончили работу над очередной задачей и отдали ее на проверку, смотрим в выборке Мои задачи в которой отобраны задачи, назначенные на разработчика или вернулись ему на доработку со стороны тестировщика. Если такая есть, то берется задача, первая по списку в этом отборе (сортировка в нем настроена по приоритету и дате постановки) И переходим к разделу Подготовка для дорабатываемой задачи

В случае, когда в этом разделе пусто, он переходит в свой проект и открывает список задач в Бэклог выбирает задачу, которая является первой по списку сверху, подходящая ему по квалификации.

В некоторых отдельных случаях, выдавать задачи может руководитель разработки в соответствии по стратегии распределения, согласованной с заказчиком. Запоминаем номер этой задачи (далее по тексту <task_id>) и переходим к разделу Подготовка для новой задачи

4.2.4. Подготовка для новой задачи

Вначале читаем постановку задачи поверхностно. Если вам не понятно описание, сначала спрашиваем у своего ментора (если назначен). Если ментор не смог понять и объяснить вам что нужно делать, то максимально подробно описываем вопросы в поле с комментариями, в карточку задачи в поле «Назначено» ставим ответственным автора задачи и сохраняем изменение. После чего повторяем действия, описанные в пункте Выбор задачи

В случае, если вам понятно, как именно делать задачу (при поверхностном прочтении или понятно ментору), переходим в директорию проекта и переключаемся на ветку master, обновляем ее и от нее отпочковываем ветку для нашей новой задачи.

cd ~/projects/<project_name>/

# Переключаемся на ветку, от которой будет создана ветка для задачи
git checkout master

# Обновляем ветку, чтобы получить максимально свежее состояние ветки
# и уменьшить возможные конфликты при вливании этой ветки назад
git pull

# Создаем ветку для задачи и переключаемся на нее
git checkout -b task_<task_id>

И выполняем необходимую доработку (см раздел Работа с задачей)

4.2.5. Подготовка для дорабатываемой задачи

В случае, когда вы берете в работу задачу после обсуждения замечаний по запросу на слияние или из выборки «Мои задачи», для которой вы уже создали ветку ранее, переключаемся на нее, втягиваем свежие изменения из ветки master

cd ~/projects/<project_name>/

# Переключаемся на ветку
git checkout task_<task_id>

# Обновляем ветку, чтобы свести к минимуму рассинхронизацию между ветками
git pull origin master

Предупреждение

Очень важно обновлять вашу ветку именно из master. Если вы по ошибке влили в свою ветку test, то вы в свою ветку получили все фиксации из этой ветки и после этого влить эту ветку в релиз отдельно уже нельзя.

И выполняем необходимую доработку (см раздел Работа с задачей)

4.2.6. Работа с задачей

Если уже после того, как вы начали работу, у вас возникли вопросы, пытаемся решить их через прямую коммуникацию с автором задачи (если это поддерживает заказчик). Если заказчик подобный тип коммуникации не поддерживает или автор задачи не отвечает долгое время, то фиксируем вопросы в redmine (в графе «Назначено» выбираем автора задачи) фиксируем изменения в репозиторий и переходим к этапу Выбор задачи В фиксации результата работы указываем номер задачи и ключевое слово DRAFT, и (опционально) произвольный комментарий

git commit -m 'refs #<task_id> DRAFT - Сделал пункты с 1 по 5 и отправил на уточнение задачи'
git push origin task_<task_id>

Если вопросов не возникло, то выполняем задачу, фиксируем результат, отправляем изменения в origin-репозиторий.

git commit -m 'refs #<task_id> <Произвольный комментарий>'

# Обновляем ветку, чтобы свести к минимуму рассинхронизацию между ветками
git pull origin master

# Отправляем ветку в удаленный репозиторий
git push origin task_<task_id>

Переходим к списку веток в репозитории https://git.sbps.ru/sphere/<project_name>/branches/, ищем свою ветку и нажимаем на серую кнопку «New Pull Request», далее на зеленые кнопки «New Pull Request» и «Create Pull Request» И создаем запрос на слияние в ветку test для проверки заказчиком

Переходим к разделу Выбор задачи. Ваш pull request рассмотрят, далее об этом ниже.

4.2.7. Когда ваш запрос на слияние просмотрели

После того, как ваш запрос на слияние просмотрят, возможны 2 варианта.

Если все нормально, то запрос примут и выложат на тест (о чем сообщат лично или в чате). В этом случае, нужно открыть эту задачу в redmine, в комментариях написать какую-то информацию для заказчика (при необходимости), в поле «Назначено» выбрать представителя заказчика, который в задаче писал что-то последним (иногда бывает, что общение по задаче у автора перехватывает другой бизнес-аналитик) или автора задачи. Статус перевести в «На проверке» и сохранить Далее задача может вернуться на доработку (Подготовка для дорабатываемой задачи) или быть принятой (Когда заказчик принял задачу). Но это «уже совсем другая история». А мы, тем временем, плавно перемещается у уже знакомому разделу Выбор задачи

Если по вашему коду есть какие-то предложения по улучшению или замечания, то человек, принимающий ваш запрос, описывает в запросе на слияние в виде комментариев к запросу на слияние и согласовывает с вами время обсуждения замечаний, чтобы не выдергивать разработчика из контекста выполнения задачи. Далее, в согласованное время (когда вы закончили работать над текущей задачей) разработчик созванивается и обсуждает замечания. После этого, он переключается на ветку с этой задачей и выполняет все действия, описанные в разделе Подготовка для дорабатываемой задачи

4.2.8. Когда заказчик принял задачу

После того, как заказчик проверил и принял задачу на тестовом стенде, он выставляет статус «Ожидает релиз, проверена». Это означает что заказчик готов к релизу этой задачи, выполнив все необходимые работы по внедрению.

4.2.9. Формирование релиза, финальное тестирование и релиз

В redmine создается релизная версия, в которую включаются эти задачи. https://redmine.sbps.ru/projects/sber/roadmap В карточке задачи в поле «Версия» доступна информация о том, в каком именно релизе задача вошла в рабочую версию.

Разработчики выбирают все задачи, которые находятся на этапе «Проверены, ожидают релиз», но пока еще не ассоциированы ни с одной релизной версией. От ветки master отпочковывается релизная ветка и все необходимые фича-ветки по задачам включаются в нее.

Для регресс-тестов запускается отдельный экземпляр системы, на котором выкладывается для финальной пред-релизной проверки, на котором заказчик тестирует задачи уже «на чистовую», чтобы исключить ошибки, связанные с не правильным решением конфликтов слияния веток в релизную ветку и взаимозависимости между задачами.

К контрольной точке проверка заканчивается и релизная ветка вливается в master ветку и происходит релиз. Версия redmine помечается как закрытая.