Skip to content
This repository has been archived by the owner on Jul 17, 2023. It is now read-only.

Latest commit

 

History

History
14 lines (12 loc) · 5.67 KB

how-to-release.md

File metadata and controls

14 lines (12 loc) · 5.67 KB
Raw

Как релизить проект?

№ Действие Ответственный
1 Проверка выполненных задач: перед релизом не должно быть:
  1. блокирующих и/или критичных багов;
  2. не выполненных важных задач в рамках эпиков, включённых в релиз;
 Руководитель проекта
2 Согласие тестировщика и/или QA lead: если в проекте имеется тестировщик и/или QA Lead, то они должны выразить своё явное согласие на релиз. В отсутствии согласия руководитель проекта не может релизить продукт и должен провести совещание с курирующим ПМом, Product owner'ом и/или заказчиком.

Рекомендуется сделать QA проактивным, чтобы он сам сообщал раз в день-два о текущем статусе.		 Тестировщик
3 Согласие ведущего разработчика на релиз. См. п.2. Ведущий разработчик
4 Положительный feedback от заказчика: если проект находится уже в стадии Production, то во время UAT необходимо отправить заказчику ссылку на DEV-сервер и/или билд для проверки и получить согласие на релиз. Руководитель проекта + Заказчик
5 Release notes:
  • по каждому приложению (Web, Mobile) должен быть подготовлен список Release Notes, содержащий набор эпиков, выполненных в рамках релиза.
  • Release Notes должен быть понятен прежде всего Заказчику.
  • При необходимости (публикация в App Store / Play Store) Release Notes должны быть творчески отредактированы и согласованы с заказчиком.
  • Release Notes должны содержать только основные изменения (обычно это — эпики, но могут быть и отдельные задачи, которые существенно что-то улучшают и/или отдельно упоминались заказчиком, как важные).
  • Список всех изменений можно предоставлять в виде ссылки на версию в JIRA.
 Руководитель проекта
6 Smoke-тестирование перед релизом: руководитель проекта должен провести самостоятельно smoke-тестирование для оценки качества продукта. В случае важных релизов необходимо привлечь к этому процессу курирующего ПМа. Руководитель проекта
7 План по релизу (деплою): сотрудник, ответственный за релиз, должен чётко понимать последовательность действий, необходимых для релиза. В случае сложных релизов системный администратор / CTO должны быть в курсе и доступны на время релиза, равно как и сам разработчик. Руководитель проекта
8 Информирование по релизу (деплою):
  • руководитель проекта обязан своевременно информировать клиента и команду по ходу релиза проекта.
  • Внутри компании все стадии релиза должны сопровождаться сообщениями в Slack.
  • @here/@channel в самом начале релиза и в самом конце для привлечения внимания. Если клиент хочет также получать статусы о релизе, это необходимо также дублировать и клиенту.
  • По завершению релиза необходимо отправить e-mail, содержащий:
    1. номер и дату релиза,
    2. функционал, который был отрелижен (Release Notes)
    3. статус релиза (всё прошло успешно и/или нет; если нет — список проблем)
    4. известные баги и ETA по их исправлению (последнее — если применимо)
  • В случае возникновения любых проблем во время или после релиза, куратор и клиент должны быть немедленно уведомлены. Принимаемые решения должны координироваться с ними и командой.
 Руководитель проекта
9 Чеклист для технологической проверки перед релизом. Все пункты (кроме курсива) должны быть выполнены. Руководитель проекта