Чек-лист деплоя Yii2-проекта без лишней суеты

Деплой небольшого Yii2-проекта редко выглядит как красивая кнопка “выложить”. Чаще это несколько понятных действий: забрать код, проверить конфиги, выполнить миграции, сбросить кэш, убедиться, что права на директории не сломались. Проблемы начинаются тогда, когда эти шаги выполняются по памяти.

На практике лучше иметь короткий порядок действий и не усложнять его без необходимости. Даже если проект маленький, чек-лист экономит время: меньше шансов забыть очередь, фонового демона, cron или старый кэш представлений.

Перед выкладкой

Сначала стоит проверить, что выкладывается именно тот код, который должен попасть на сервер. Звучит очевидно, но ошибки с ветками встречаются чаще, чем проблемы с самим Yii2.

• проверить текущую ветку;
• посмотреть список изменённых файлов;
• убедиться, что в коммит не попали локальные конфиги;
• проверить миграции и зависимости Composer;
• понять, есть ли изменения в cron, очередях или systemd-сервисах.

git status
git branch --show-current
git log --oneline -5
composer validate

Если проект ведётся без полноценного CI, хотя бы локально стоит выполнить базовую проверку синтаксиса для изменённых PHP-файлов. Это не заменяет тесты, но ловит простые ошибки до выкладки.

find . -name "*.php" -not -path "./vendor/*" -print0 | xargs -0 -n1 php -l

Обновление кода на сервере

На сервере важно работать из правильной директории и под правильным пользователем. Отдельная частая проблема — файлы после деплоя принадлежат не тому пользователю, из-за чего сайт не может писать в runtime или web/assets.

cd /var/www/site.ru
git pull origin main
composer install --no-dev --prefer-dist --optimize-autoloader

Для проектов на shared-хостинге команда Composer может отличаться: иногда используется конкретная версия PHP, например php82. Лучше не полагаться на системный php, если на сервере установлено несколько версий.

php -v
php82 composer.phar install --no-dev --prefer-dist --optimize-autoloader

Миграции

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

php yii migrate --interactive=0

Если миграция добавляет данные, как категории, настройки или справочники, в safeDown не стоит использовать truncate. На рабочем сайте почти всегда уже есть пользовательский контент, и удалять таблицу целиком нельзя.

Кэш и runtime

После обновления кода иногда остаётся старый кэш: маршруты, фрагменты, схемы таблиц, скомпилированные зависимости. Если используется файловый кэш, его можно очистить средствами Yii2. Если Redis — проверить отдельно.

php yii cache/flush-all

При ручной чистке директорий лучше не удалять сами папки runtime и web/assets, а очищать содержимое. Иначе можно получить ошибку записи, особенно если папки создаст пользователь root.

rm -rf runtime/cache/*
rm -rf runtime/debug/*
rm -rf web/assets/*

Права на директории

Yii2 должен иметь возможность писать в runtime и web/assets. Для загрузок могут быть отдельные директории. Проверку лучше делать сразу после деплоя, а не после жалобы, что “форма перестала работать”.

chown -R www-data:www-data runtime web/assets
chmod -R ug+rw runtime web/assets

Команды зависят от окружения. На некоторых серверах пользователь будет nginx, apache, bitrix, deploy или пользователь хостинга. Главное — не выставлять 777 без необходимости. Это быстро, но обычно неправильно.

Очереди, cron и фоновые процессы

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

php yii queue/info
sudo systemctl restart yii-queue.service
sudo systemctl status yii-queue.service

Для cron полезно хранить команды в документации проекта. Когда расписание живёт только в панели хостинга или в голове разработчика, поддержка быстро превращается в расследование.

crontab -l

Проверка после выкладки

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

1. Открыть сайт в браузере без авторизации.
2. Проверить страницу, которую меняли.
3. Отправить тестовую форму.
4. Открыть админку и сохранить простую сущность.
5. Проверить логи приложения и веб-сервера.

tail -n 100 runtime/logs/app.log
tail -n 100 /var/log/nginx/error.log

Минимальный рабочий чек-лист

• код обновлён из правильной ветки;
• Composer-зависимости установлены без dev-пакетов;
• миграции выполнены;
• кэш очищен;
• runtime и assets доступны на запись;
• очереди и фоновые процессы перезапущены;
• логи проверены после тестового открытия сайта;
• критичные сценарии вручную пройдены.

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