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

Даже короткий простой может потерять заявки, оплату или доверие, особенно если релизы идут часто.

Коротко: деплой нужно делать атомарно: новая версия готовится отдельно и подключается только после проверки.

Почему возникает проблема

Простой появляется из-за сборки прямо в web-root, удаления старых файлов до готовности новых, долгих миграций, перезапуска PHP-FPM, очистки кеша без прогрева или отсутствия health check перед переключением.

Что проверить в первую очередь

  • где выполняется сборка
  • как переключается версия сайта
  • есть ли health check
  • как выполняются миграции
  • есть ли быстрый rollback

Как я решаю такую задачу

Я перестраиваю деплой так, чтобы пользователь видел либо старую рабочую версию, либо новую уже проверенную.

  • анализирую текущий pipeline
  • выношу сборку из публичной папки
  • настраиваю atomic symlink или release directories
  • добавляю health check и rollback
  • тестирую деплой на staging

Что подготовить

  • репозиторий или pipeline
  • сервер и путь сайта
  • что происходит во время простоя
  • стек проекта
  • требования к миграциям

Сроки и риски

Если сайт простой, zero downtime можно внедрить быстро. Если миграции несовместимы со старым кодом, нужно продумать двухфазные релизы.

Чего лучше не делать

Не запускайте сборку frontend прямо в папке, откуда nginx отдает сайт. Это частая причина частично обновленных файлов.

FAQ

Что такое atomic deploy?

Переключение на уже готовую папку релиза одной быстрой операцией.

Нужен ли rollback?

Да, чтобы быстро вернуться к прошлой версии при ошибке.

Можно ли деплоить без Docker?

Да, release directories и symlink подходят и без контейнеров.

Что делать с миграциями базы?

Делать их совместимыми с текущей и новой версией кода.

Нужна похожая задача?

Напишите в Telegram @rabotator_support или оставьте заявку на сайте. Пришлите ссылку, пример ошибки и короткое описание того, как должно работать. Я посмотрю задачу, предложу безопасный план и скажу, какие доступы понадобятся.

Итог

Деплой должен проходить предсказуемо, с проверкой готовности, возможностью отката и без минутного окна недоступности сайта.