Skip to main content

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

info

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

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

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

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

  • Greensight Redmine - здесь находятся постановки задач
  • Greensight Cabinet - канбан доска, определяющая порядок выполнения задач
  • ensi - репозитории с исходным кодом платформы
  • https://jenkins-infra.ensi.tech/ - сервер автоматизации сборки и отгрузки сервисов

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

  1. Убедитесь, что постановка задачи вам ясна.
  2. Переведите задачу в статус “В процессе”
  3. Разверните локально все сервисы необходимые для выполнения задачи. Если в ходе выполнения задачи вам будет необходимо лишь коммуницировать с каким-то сервисом, а доработки в нём не требуются, то такой сервис можно не разворачивать локально, а использовать развернутый в тестовом контуре
  4. Если вы работаете над большой фичей (блок задач), то для неё должна быть создана отдельная "основная" ветка соответствующая номеру фичи, а мелкие задачи внутри делаться во "вспомогательных" ветках, необходимых исключительно для удобства ревью. Для "основной" ветки необходимо сразу создать PR в master, без назначения Reviewer, пометить как Draft.
  5. Если вы работаете над атомарной задачей, то необходимо работать в одной ветке, созданной от master.
  6. Создайте ветки task-NNNNN во всех сервисах требующих доработки в рамках задачи. NNNNN - номер задачи или блока задач в Redmine.

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

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

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

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

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

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

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

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

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

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

Выбор Reviewer​

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

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

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

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

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

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

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

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

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

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

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

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

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

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