Как происходит развертывание и поставка изменений на проекте
Что проверяют
Видите ли вы путь изменения от коммита до продакшена целиком и понимаете ли, где в нём стоит QA: какие проверки блокируют слияние, какие блокируют выкатку и что делают, когда на проде уже плохо.
Как отвечать
- Тесты гоняются на пул-реквесте, до слияния, а не после. Пайплайн на PR: линтеры, юнит и интеграционные тесты, сборка. Красный пайплайн блокирует мердж, в этом и смысл CI.
- Артефакт собирается один раз, и по всем окружениям (dev, stage, prod) едет один и тот же. Пересборка под каждое окружение означает, что тестировали не то, что выкатили. Конфигурация подставляется переменными окружения.
- Автотесты на стенде: smoke сразу после деплоя, регресс по расписанию или на релизной ветке. Ручное тестирование остаётся на новую функциональность и на исследовательские сценарии.
- Выкатка: rolling update, blue-green или canary с постепенным переливом трафика. Фичефлаг позволяет выкатить код выключенным и включить отдельно от деплоя, для QA это шанс проверить на проде без риска для всех.
- После выкатки смотрят метрики и логи: доля ошибок 5xx, латентность, ключевая бизнес-метрика. Автоматический откат по порогу ошибок надёжнее ручного.
- Откат: возврат на предыдущий образ, но миграции базы так не откатываются. Отсюда правило: миграции обратно совместимые, схема меняется отдельным релизом от кода (expand and contract).
Где спотыкаются
Говорят, что откат решает любую проблему. Необратимая миграция, разосланные письма и списанные деньги не откатываются, и спрашивают обычно как раз про это.
Путают CI и CD, называя CD «кнопкой деплоя». Continuous delivery это готовность выкатить любой зелёный коммит, continuous deployment это автоматическая выкатка без кнопки.
Заканчивают рассказ на «выкатили», забывая про мониторинг и алерты. Поставка завершается подтверждением, что на проде действительно работает.
Не могут сказать, что именно в их пайплайне блокирует релиз. Ответ «у нас есть Jenkins» на вопрос про качество поставки не отвечает.