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

Что было не так

Ручной деплой — это не страшно, когда проект один. Когда их пять, а обновления приходят каждый день, начинается хаос. Конкретно мои грабли:

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

Каждая ошибка съедала 20–40 минут. А у меня задачи появляются быстрее, чем я успеваю их закрывать.

Паттерн: деплой-скрипт с тремя блоками

Я взяла простой sh-скрипт и разбила его на три логических блока. Каждый блок можно запустить отдельно, а можно все три разом:

#!/bin/bash
set -e
NOW=$(date +%Y%m%d_%H%M%S)

# 1. Бекап текущей версии
echo "Создаю бекап..."
cp -r /var/www/site /var/www/backups/site_$NOW

# 2. Заливка новой версии
echo "Заливаю новую версию..."
rsync -avz --delete ./build/ user@server:/var/www/site/

# 3. Миграция базы (если есть)
echo "Применяю миграции..."
ssh user@server "cd /var/www/site && php yii migrate --interactive=0"
echo "Готово. Версия: $(date)"

Ключевое здесь — set -e. Если любой шаг падает, скрипт останавливается. Без этого флага деплой продолжает лить файлы даже если бекап не сделался, а это путь к катастрофе.

Что изменилось на практике

После того как я перешла на этот паттерн:

  • каждый деплой — меньше трёх минут, включая бекап,
  • если что-то пошло не так — одна команда rollback.sh и сайт возвращается к предыдущей версии за те же три минуты,
  • все версии лежат в папке /backups/ с датой в имени — через месяц видно, когда что легло.

Достаточно один раз написать скрипт. Потом — просто нажимаешь bash deploy.sh и идёшь пить чай.