Расскажи как устроен деплой

Развертывание (деплой) PHP-приложения: от кода до продакшена

Деплой — это процесс вывода нового или обновленного программного обеспечения в рабочую среду, где оно становится доступным для конечных пользователей. Для PHP Backend это комплексный процесс, включающий подготовку кода, настройку среды, перенос файлов, миграции баз данных и перезапуск сервисов. Рассмотрим ключевые этапы и методологии.

Основные этапы процесса деплоя

Типичный пайплайн деплоя состоит из следующих шагов:

1. Подготовка кода и сборка (Build)

    *   Код забирается из системы контроля версий (обычно **Git**) из определенной ветки (например, `main`, `production`).
    *   Устанавливаются зависимости через **Composer** (`composer install --no-dev --optimize-autoloader`). Флаг `--no-dev` критичен для продакшена.
    *   Выполняются задачи сборки фронтенда (если есть) – минификация CSS/JS через Webpack, Vite и т.д.
    *   Оптимизируется автозагрузчик PSR-4 для повышения производительности.
    *   Могут генерироваться/кэшироваться конфигурационные файлы, роуты, контейнер зависимостей (для Symfony/Laravel).

```bash
# Пример скрипта сборки (build.sh)
git pull origin main
composer install --no-dev --optimize-autoloader
npm run production # если используется фронтенд
php artisan config:cache # для Laravel
php bin/console cache:warmup --env=prod # для Symfony
```

2. Настройка среды (Environment Configuration)

    *   Критически важный этап. Параметры подключения к БД, API-ключи, настройки кэша и логирования **никогда не хранятся в репозитории**.
    *   Используются переменные окружения (`.env` файлы или сервисы вроде AWS Parameter Store, HashiCorp Vault).
    *   На сервере создается файл `.env.production.local` (в Symfony) или `.env` (в Laravel) с актуальными продакшен-значениями.

1. Перенос артефактов на сервер

    *   **Ручной/полуавтоматический способ:** Использование `rsync`, `scp` или FTP. Часто совмещается с использованием инструментов вроде **Deployer**, **Capistrano** или **Ansible**.
    *   **Современный/CI-CD способ:** Сборка происходит в изолированном окружении CI/CD сервера (GitLab CI, GitHub Actions, Jenkins). Получившийся артефакт (образ Docker или просто архив) разворачивается на серверах.

```bash
# Пример деплоя через rsync (исключая временные файлы)
rsync -avz --exclude='.env' --exclude='.git' \
      --exclude='storage/logs/' --exclude='node_modules/' \
      ./ user@production-server:/var/www/app/
```

4. Запуск миграций базы данных и скриптов

    *   Перед или после переноса файлов выполняются миграции БД для приведения схемы данных в актуальное состояние.
    *   Выполняются скрипты, необходимые для обновления (например, инвалидация кэша, переиндексация поиска).

```bash
php artisan migrate --force # Laravel
php bin/console doctrine:migrations:migrate --no-interaction --env=prod # Symfony
```

5. Переключение на новую версию и перезапуск сервисов

    *   **Без Downtime (без простоя):** Современные стратегии стремятся к нулевому простою. Популярный подход — симлинки. Новая версия разворачивается в отдельную директорию (например, `releases/20240527_120000`), а симлинк текущей версии (`current`) в корневой директории проекта (`/var/www/app`) перенацеливается на эту новую папку атомарной операцией.
    *   Для применения изменений в коде PHP часто требуется перезагрузка **PHP-FPM**.
    *   Необходимо очистить кэш OPcache, иначе будет выполняться старый код.
    *   Может потребоваться перезагрузка веб-сервера (Nginx/Apache) или перезапуск workers (для очередей).

```bash
# Пример атомарного переключения симлинка (используется в Deployer)
ln -sfn /var/www/app/releases/20240527_120000 /var/www/app/current
# Перезагрузка PHP-FPM для применения нового кода
sudo systemctl reload php8.3-fpm
# Очистка OPcache (можно через php-cli или http-запрос)
php -r 'opcache_reset();'
```

Стратегии деплоя

• Blue-Green Deployment: Поднимаются два идентичных продакшен-окружения (Blue и Green). В текущий момент работает одно (напр., Blue). Новую версию разворачивают на Green, тестируют, а затем переключают весь трафик (например, меняя правило в балансировщике нагрузки) на Green. В случае проблем — мгновенный откат на Blue.
• Canary Release: Новую версию разворачивают на небольшой процент серверов или для небольшой доли пользователей. Это позволяет оценить стабильность и собрать метрики перед полным rollout.
• Rolling Update: Постепенное обновление серверов в кластере по одному или группами, что обеспечивает доступность приложения во время деплоя.

Инструменты и инфраструктура

• Инструменты деплоя: Deployer (нативный для PHP), Capistrano (Ruby, но часто используется), Ansible, SaltStack.
• CI/CD Пайплайны: GitLab CI, GitHub Actions, Jenkins, TeamCity. Они автоматизируют сборку, тестирование и сам деплой.
• Контейнеризация: Docker и Kubernetes кардинально меняют подход. Приложение упаковывается в immutable-образ, который затем разворачивается в оркестраторе. Деплой сводится к обновлению образа в кластере с использованием стратегий K8s (rolling update).
• Инфраструктура как код (IaC): Использование Terraform, Pulumi или CloudFormation для описания и воспроизведения всей инфраструктуры (серверы, сети, БД).

Ключевые практики для надежного деплоя

• Автоматизация: Чем меньше ручных шагов, тем ниже риск человеческой ошибки.
• Идемпотентность: Скрипты деплоя должны быть безопасны для многократного запуска.
• Откатываемость (Rollback): Всегда имейте четкий и быстрый план отката к предыдущей стабильной версии (например, переключение симлинка обратно).
• Мониторинг и логирование: Сразу после деплоя внимательно отслеживайте метрики приложения (ошибки, latency, нагрузка CPU) и логи, чтобы оперативно выявить проблемы, вызванные обновлением.
• Деплой в непиковые часы: Чтобы минимизировать потенциальное влияние на пользователей.

Таким образом, современный деплой PHP-приложения — это не просто git pull, а хорошо спроектированный, автоматизированный и контролируемый процесс, являющийся неотъемлемой частью DevOps-культуры, нацеленный на скорость, надежность и минимальный риск.