Опишите стратегию деплоя, процесс релиза и обновления приложений на проекте
Что проверяют
Понимаете ли вы, чем выпуск отличается от выката и что происходит с работающим сервисом в момент обновления. От питониста ждут конкретики: как собирается артефакт, что происходит с воркерами и очередями, как накатываются миграции.
Как отвечать
Разделите вопрос на три части.
Артефакт: образ собирается один раз, зависимости зафиксированы файлом блокировки, установка из внешних репозиториев на выкате не происходит. Один и тот же образ едет по окружениям, отличаются только переменные окружения и секреты.
Стратегия под тип приложения: последовательное обновление реплик для сервиса за балансировщиком, две среды с переключением, когда нужен мгновенный откат, постепенный выпуск на часть трафика, когда риск в бизнес-логике. Флаги функциональности отделяют выкат от включения и остаются самым дешёвым способом снизить цену ошибки.
Специфика Python, которую и ждут: воркеры gunicorn или uvicorn должны отработать сигнал завершения и дожить текущие запросы, а проба готовности должна убрать реплику из балансировки заранее; воркерам очереди нужен свой мягкий останов, а формат задач обязан переживать соседство версий, потому что в очереди уже лежат сообщения старого вида; миграции применяются отдельным шагом, а не при старте каждой реплики, и пишутся так, чтобы схема подходила обеим версиям сразу.
Где спотыкаются
Перечисляют стратегии по учебнику, не сказав, какая из них у них самих. Вопрос о том, чем и где делится трафик, выясняет это за минуту.
Накатывают миграции из точки входа приложения. Несколько реплик стартуют одновременно и дерутся за блокировку, а необратимая миграция в том же релизе делает откат невозможным.
Держат настройки внутри образа и не фиксируют зависимости. Тогда откат означает пересборку, а повторная сборка того же тега даёт другое приложение, потому что версия библиотеки успела уехать.