Путь кода до прода: сборка, образ, registry, миграции, деплой

↑ 7.6 DevOps для бэкенд-разработчика · → Следующая

По желанию~3 мин чтенияУровень: senior

Зачем это на собесе

Бэкендера часто спрашивают, как его код попадает в прод и что происходит при сбое релиза.

Объяснение

flowchart LR
  C[Commit / MR] --> B[Сборка + тесты]
  B --> I[Docker-образ]
  I --> R[(Registry)]
  R --> M[Миграции БД]
  M --> D[Деплой]
  D --> H[Health check]
  H --> O[Мониторинг]
  H -. сбой .-> RB[Откат]
ЭтапЧто происходитАртефакт
Сборкаrestore, build, unit-тесты, линтерыбинарники, отчёты
Качество/безопасностьSAST, сканирование зависимостей и образаотчёты
Образdocker build, тег по коммиту/версииобраз
Публикацияpush в registryобраз с тегом
Миграцииприменение изменений схемыобновлённая БД
Деплойобновление контейнеров/подовзапущенная версия
Проверкаhealth checks, smoke-тестыстатус релиза
Наблюдениеметрики и логи после выкладкисигналы для отката

Принципы:

  • Один артефакт на все окружения (immutable image): различается только конфигурация.
  • Тег = коммит/версия, не latest.
  • Повторяемость: всё в коде (Dockerfile, pipeline, compose, IaC).
  • Небольшие частые релизы безопаснее редких больших.
  • Обратная совместимость кода и схемы БД для откатов и rolling-обновления.

Нюансы и подводные камни

  • Сборка «на машине разработчика» не воспроизводима.
  • Сборка образа отдельно для каждого окружения приводит к «на stage работало».
  • Миграции должны переживать одновременную работу старой и новой версий.
  • Нужны быстрый откат и способ узнать, что именно запущено (версия в /health или метаданных).

Практика

  1. Нарисуйте путь кода вашего проекта от коммита до прода и найдите ручные шаги.
  2. Добавьте версию (коммит) в ответ /health и метрики.
  3. Проверьте, что один и тот же образ работает в stage и prod с разной конфигурацией.

Вопросы с ответами

Связанные темы