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

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

Эта версия описывает последовательный процесс, по которому проверяется и идет в релиз полное состояние системы, в которое включены задачи. Сначала все проверяется на тесте, потом на пред-релизном стенде и потом все это идет в релиз.

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

cd ~/projects/<project_name>/

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

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

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

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

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

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

cd ~/projects/<project_name>/

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

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

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

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

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

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

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

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

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

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

# Обновляем ветку, чтобы свести к минимуму рассинхронизацию между ветками
# **Внимание** - втягиваем из ветки, соответствующей полю "Стенд" в задаче redmine
git pull origin <test_or_stage_branch>

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

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

Задачу в redmine оставляем на себе и меняем статус в «На preview» и переходим к разделу Выбор задачи

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

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

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

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

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

После того, как заказчик проверил и принял задачу, он выставляет статус «Задача проверена»

4.1.8. Релизный цикл и ветки

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

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

4.1.8.1. Стенд (параметр в задаче redmine)

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

dev Это машина конкретного разработчика, на которой установлена система и локальная БД. Разработчик, при необходимости исследования сложившейся на тесте ситуации, может подключить приложение к базе данных стендов test или stage
test Стенд, на котором заказчик проверяет задачи до момента фиксации состояния на stage сервере Когда принимается pull-request и задача оказывается на тестовом стенде, в этом поле проставляется «test»
stage Пред-релизный стенд. На нем проводится стабилизация состояния системы в процессе подготовки ее к релизу Когда происходит фиксация состояния перед релизом, все задачи, которые имели значение «test» меняют значение на «stage»
prod Рабочий стенд, на котором работают операторы и выполняют работу. Доступен ограниченному кругу лиц, которые обрабатывают задачи по поддержке клиента. Когда stage-сервер и задачи, которые в него попали, проходят стабилизацию, происходит релиз и все они меняют название «stage» на «prod»

На соответствующем стенде активирована одноименная стенду ветка. Обычно, доменные имена серверов формируются подобным образом:

https://<project_name>-<branch>.sbps.ru/

Например, «https://sber-test.sbps.ru/» и «https://sber-stage.sbps.ru/»

4.1.8.2. Ветки в репозитории

В репозитории (мы используем git) выделяются несколько веток, которые ассоциируются с конкретной задачей или конкретным стендом развертывания

test Это основной тестовый стенд, куда вливаются все ветки задач для проверки. Также, из этой ветки отпочковываются фича-ветки Входной поток: Фича-ветки с задачами, которые вливаются через pull-request Выходной поток: За 4 дня до релиза ветка заливается в stage
stage Эта ветка связана со stage-сервером на stage сервере проводится финальное тестирование перед релизом. В нее вливаются изменения из ветки test за 4 дня до релиза и далее, пока идет стабилизация системы, из ветки test коммиты не вливаются, чтобы не де-стабилизировать состояние системы Найденные ошибки и доработки по задачам решаются в соответствующих фича-ветках и через pull-request’s вливаются в stage Входной поток: Ветка test за 4 дня до релиза и фича-ветки с исправлениями для стабилизации stage Выходной поток: В момент релиза, когда заказчик подтверждает готовность системы на этом стенде, вливается в master и происходит релиз, а также, в ветку test периодически, раз в день, в моменты, когда идет стабилизация функционала на этой ветке
master Эта ветка ассоциирована с productuion стендом (или промышленным стендом), на котором работают пользователи. В некоторых отдельных случаях, когда заказчику срочно нужна задача, от него отпочковывают фича-ветку, которую, после проверки на test стенде, вливают сюда чтобы как можно быстрее реализовать нужную задачу поверх стандартного релизного цикла Входной поток: Ветка stage в момент релиза и отдельные фича-ветки (hotfix) после проверки на стенде test Выходной поток: После релиза и вливания hotfix-веток в ветку stage