Перейти к основному содержимому

Регламент работы с задачами разработки

к сведению

Данный регламент применим к процессу разработки самой платформы, а не конкретного её внедрения. При старте внедрения регламент необходимо адаптировать к его требованиям

В общих чертах схема работы выглядит как показано на схеме

Используемые системы​

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

  • Yandex tracker - здесь находятся постановки задач
  • ensi - репозитории с исходным кодом платформы
  • Jenkins - сервер автоматизации сборки и отгрузки сервисов

Этап 1. Начало работы над задачей​

  1. Убедитесь, что постановка задачи вам ясна.
  2. Переведите задачу в статус “В процессе”
  3. Разверните локально все сервисы необходимые для выполнения задачи. Если в ходе выполнения задачи вам будет необходимо лишь коммуницировать с каким-то сервисом, а доработки в нём не требуются, то такой сервис можно не разворачивать локально, а использовать развернутый в тестовом контуре
  4. Необходимо обратить внимание на тип задачи, с которой ведётся работа:
    1. Если вы работаете над большой фичей (блок задач) (родительская задача имеет тип Epic, внутренние - "Задача"), то для неё должна быть создана отдельная "основная" ветка соответствующая номеру фичи, а мелкие задачи внутри делаться во "вспомогательных" ветках, необходимых исключительно для удобства ревью. Для "основной" ветки необходимо сразу создать PR в master, без назначения Reviewer, пометить как Draft.
    2. Если вы работаете над атомарной задачей (типы "Story" или "Ошибка"), то необходимо работать в одной ветке, созданной от master.
  5. Создайте ветки <queue_key>-<number> (в нижнем регистре, например ef-5 или ensitech-8) во всех сервисах требующих доработки в рамках задачи.

Этап 2. Реализация задачи​

При реализации задачи НЕОБХОДИМО не забывать о требованиях остальных гайдлайнов

Результат задачи ДОЛЖЕН быть протестирован локально разработчиком посредством: 1) автотестов 2) вручную.

ДОЛЖНЫ быть настроены и успешно проходить pre-commit/pre-push хуки git.

Если вы меняете переменные окружения, то НЕОБХОДИМО проверить не нужно ли это отразить в:

Если при реализации приходится ставить заглушки на существующий код, скрывать поля в спецификации и прочее, то НЕОБХОДИМО добавлять todo c номером задачи, где это будет решено.

Сообщение коммита ДОЛЖНО соответствовать следующему шаблону:
КОД-ЗАДАЧИ-ИЗ-ТРEКЕРА краткое_описание_изменений

Этап 3. Загрузка в Gitlab и Code Review​

  1. Пушим ветки в Gitlab
  2. Создаем Merge Request/Pull Request. Если работа ведётся над блоком задач, то в качестве ветки-назначения используется "основная" ветка. Иначе master.
  3. Назначаем Assignee и Reviewer. Подробнее о выборе Reviewer при разработке платформы тут
  4. Проверяем код в RP, чтобы убедиться что всё корректно с вашей собственной точки зрения
  5. Переводим задачу в Y.tracker в статус “Ревью”, исполнитель должен совпадать с Reviewer
  6. Если по PR есть замечания, ревьювер должен написать об этом в задачу и вернуть её в статус "Открыт" на человека, указанного в Assignee
  7. Reviewer после аппрува должен: 1) добавить в PR нового ревьювера - техлида. 2) отписать в задачу "PR аппрувнут, переведён на техлида". 3) сменить исполнителя в задаче на техлида
  8. Техлид, после аппрува, должен перевести задачу в статус "Готово к релизу" на человека, указанного в Assignee

Если в задаче требуется изменение конфигов развертывания в k8s (например добавляется новая переменная окружения), то вместе с MR реализующим задачу в сервисе необходимо отправить и MR в репозиторий конфигов развертывания. Этот MR должен внести необходимые изменения в конфигурацию для ветки master. Конфиги для других веток можно править без MR

Если задача вернулась вам с Review на доработки, то она имеет более высокий приоритет, чем остальные задачи Ensi. Более подробную информацию про Code Review можно найти в Code Review Guide

Выбор Reviewer​

  1. Reviewer должен состоять в команде разработки на текущий момент
  2. При работе над багами/правками в существующих блоках, можно выбрать изначального автора кода

Этап 4. Тестирование​

Если ветка является "вспомогательной", т.е. создана исключительно для удобства ревью, то сразу переходим к этапу 5.

Если работа ведётся:

  • по блоку задач и смержена последняя "вспомогательная" ветка
  • над атомарной задачей и вы уже создали RP

то необходимо отгрузить ветку на фича-стенд по этой инструкции и написать все необходимые ссылки и доступы в задачу. Если на этапе 3 проводились изменения кода, не забываем догружать эти изменения на стенд.

После того как все необходимые аппрувы получены, запускается процесс приёмки: происходит тестирование/сверка с постановкой и прочее, занимается этим аналитик/QA/менеджер.

После успешной приёмки задачу необходимо вернуть разработчику в статус "Готово к релизу" с комментарием о том что можно отгружать.

Этап 5. Отгрузка​

После успешно пройденного Code Review и приёмки можно смержить PR.

При мерже задачи важно начинать с репозитория конфигов развертывания.

На данный момент никакие ветки не развертываются автоматически в тестовом контуре Ensi.

В Y.tracker необходимо оставить комментарий, что задача смержена и перевести её в статус “Решен”.

Если мержилась "вспомогательная" ветка, то, если она была последней в блоке, необходимо вернуться к шагу 4 для передачи на тест всего блока. Исполнитель при этом должен написать комментарий в задачу, что блок целиком готов к тестированию.