Как проходят итерации и релизы в команде

Что проверяют

Как код в вашей команде проходит путь от задачи до продакшена и понимаете ли вы, что итерация и релиз не одно и то же. Уточнения обычно такие: как часто вы выкатывались, как откатывались и что делали с миграциями базы.

Как отвечать

Рассказывайте про свою команду, а каркас такой:

• итерация: длина (чаще всего две недели), планирование, дейли, демо и ретро. Коротко, без определений из учебника;
• ветки: trunk-based с короткими ветками и фича-флагами или GitFlow с релизными ветками. Скажите, что было у вас и почему;
• CI: на каждый merge request гоняются линтер и форматтер (ruff), проверка типов (mypy или pyright), тесты pytest с базой в контейнере. Без зелёного пайплайна мерж закрыт;
• релиз: версия по semver и тег, сборка Docker-образа, выкладка на стейджинг, затем в прод. Для библиотеки вместо образа публикация пакета;
• миграции: Alembic или Django migrations, совместимые с предыдущей версией кода. Колонку сначала добавляют, код переводят на неё, и только в следующем релизе старое удаляют, иначе откат кода сломается о схему;
• после выкладки: мониторинг ошибок в Sentry, метрики, план отката.

Хорошо звучит честная конкретика: выкатывались два раза в неделю, откатывались раз в квартал, самый долгий инцидент случился из-за такой-то миграции. Цифры берите только свои.

Если опыта командной работы ещё не было, так и скажите и опишите свой проект: как настроили GitHub Actions, как версионировали, как выкатывали. Это лучше выдуманного Scrum.

Где спотыкаются

Отвечают шаблоном «мы используем Agile, это позволяет гибко реагировать». Ни одного факта о том, как на самом деле выходит релиз.

Не различают спринт и релиз. Во многих командах деплой идёт несколько раз в день, а спринт задаёт только ритм планирования.

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