Как реализовать процесс сборки, тестирования и деплоя образов

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

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

Как отвечать

Опишите конвейер по этапам:

• сборка: многоэтапный Dockerfile на slim-образе поддерживаемой версии Python. Сначала копируются только pyproject.toml и lock-файл (uv.lock или poetry.lock), ставятся пакеты, потом копируется код. Так слой с зависимостями кешируется между коммитами. Плюс .dockerignore, непривилегированный пользователь и никаких секретов в образе;
• проверки до сборки: ruff для линтинга, mypy или pyright для типов, быстрые юнит-тесты на pytest;
• тесты на образе: интеграционные тесты против собранного образа, PostgreSQL и Redis поднимаются сервисами CI или через testcontainers. Сюда же сканер уязвимостей, например Trivy;
• теги и реестр: тег по SHA коммита, а не latest. Один и тот же образ продвигается из стенда в стенд, меняются только переменные окружения;
• деплой: Kubernetes через Helm или Kustomize, часто по GitOps с Argo CD. Rolling update с readinessProbe, чтобы трафик не шёл на неготовый под;
• миграции: Alembic или Django migrations отдельным шагом до выкатки, только обратно совместимые, потому что старые и новые поды какое-то время работают одновременно;
• откат: helm rollback, kubectl rollout undo или возврат тега в репозитории с манифестами.

CI назовите тот, с которым работали: GitLab CI, GitHub Actions, Jenkins. Этапы у всех одинаковые.

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

Деплоят командой docker run прямо с CI-раннера. Это запуск контейнера на машине сборки, а не выкатка: нет проверок готовности, отката и учёта версий.

Собирают образ заново для каждого окружения. Тогда в прод уезжает не то, что проверили на стенде, а свежая сборка с потенциально другими версиями пакетов.

Берут базу вроде python:3.9-slim из старых примеров: ветка 3.9 вышла из поддержки в октябре 2025 и больше не получает исправлений безопасности.