Что происходит до финального этапа деплоя?

Отличный вопрос, который затрагивает самую суть современных процессов разработки. До финала деплоя (развертывания) в продакшн-окружение проходит целый комплекс автоматизированных и ручных этапов, образующих CI/CD-конвейер (Continuous Integration / Continuous Delivery/Deployment). Я опишу этот путь, типичный для зрелой PHP-команды.

Жизненный цикл коммита до продакшена

Весь процесс можно разделить на несколько ключевых стадий, которые код проходит после того, как разработчик делает git push.

1. Continuous Integration (CI): Интеграция и валидация

Это первый и полностью автоматизированный рубеж. Запускается сборкой (build) на CI-сервере (GitLab CI, GitHub Actions, Jenkins).

• Запуск пайплайна (Pipeline): Весь процесс описывается в конфигурационном файле (.gitlab-ci.yml, .github/workflows/deploy.yml).
• Установка зависимостей: Система создает изолированное окружение и запускает composer install (часто с флагом --prefer-dist --no-dev для оптимизации).
• Статический анализ кода:

  // Пример: инструменты анализа
  // PHPStan для проверки типов
  vendor/bin/phpstan analyse --level max src/
  // Psalm для выявления ошибок
  vendor/bin/psalm
  // PHP CS Fixer или CodeSniffer для проверки стиля
  vendor/bin/php-cs-fixer fix --dry-run --diff src/
  

• Запуск тестов: Это критически важный этап.

    *   **Юнит-тесты** (PHPUnit) проверяют отдельные классы и методы.
    *   **Функциональные/интеграционные тесты** проверяют взаимодействие компонентов, работу с базой данных (часто на SQLite в памяти или отдельной тестовой БД).

```yaml
# Пример шага в GitLab CI
test:unit:
  stage: test
  script:
    - vendor/bin/phpunit --testsuite Unit --coverage-text --colors=never
```

• Артефакты: Успешная сборка создает артефакты — готовый для развертывания пакет (например, .tar.gz архив с кодом и зависимостями).

2. Continuous Delivery (CD): Подготовка к развертыванию

Если CI-стадия пройдена, артефакт продвигается дальше по конвейеру.

• Деплой в тестовое/стейджинг-окружение: Автоматический деплой собранного артефакта на сервер, максимально близкий к продакшену. Это может быть ручной триггер (кнопка "Deploy to Staging") или автоматический после успеха CI.
• Дополнительное тестирование в среде, близкой к боевой:

    *   **Приемочное тестирование (Acceptance Tests)**: Например, с помощью Codeception, проверяющее ключевые пользовательские сценарии.
    *   **Нагрузочное тестирование**: Инструменты вроде Apache JMeter или k6 могут запускаться для проверки критических эндпоинтов.
    *   **Тестирование безопасности (SAST/DAST)**: Сканирование на уязвимости (например, с помощью SensioLabs Security Checker, SonarQube).

• Миграции базы данных: Подготовка и прогон скриптов миграций (например, с использованием Doctrine Migrations или Phinx) для стейджинг-БД.

  // Пример консольной команды для миграций Doctrine
  php bin/console doctrine:migrations:migrate --no-interaction --env=staging
  

3. Финальные проверки и артефакт для продакшена

Перед самым последним шагом происходят ключевые ручные и автоматические gate.

• Ревью и согласование (Manual Approval): Ответственное лицо (тимлид, менеджер) проверяет работу в стейджинге, просматривает CHANGELOG, результаты тестов и дает "добро" на деплой в прод. В современных системах это кнопка "Approve for production".
• Создание финального релизного артефакта: Система создает четко версионированный релиз (Git tag, Docker-образ). Этот артефакт идентичен тому, что тестировался в стейджинге — принцип «build once, deploy everywhere».
• Проверки окружения (Health Checks): Автоматически проверяется доступность и здоровье продакшен-окружения (до деплоя), чтобы убедиться, что деплой будет в стабильную систему.

Ключевые принципы, обеспечивающие безопасность процесса

• Идемпотентность деплоя: Скрипт развертывания можно запускать много раз без побочных эффектов (проверка существования симлинков, откат неудачных миграций).
• Минимальное время простоя (Zero-downtime deployment): Использование стратегий вроде синего-зеленого деплоя (blue-green) или деплоя через симлинки. Пока новый код (зеленая версия) разворачивается параллельно, продакшен (синяя) работает. После успешного запуска новой версии трафик переключается на нее.

  # Упрощенный пример переключения симлинка (ключевой момент)
  ln -snf /var/www/releases/<new-release> /var/www/current
  

• Откат (Rollback): Процедура быстрого отката на предыдущую рабочую версию должна быть отлажена и занимать минуты. Чаще всего — это переключение симлинка обратно на предыдущий релиз.

Итог: До финального деплоя код проходит через череду автоматизированных "сит" (сборка, тесты, анализ) и ручных проверок в изолированных средах. Главная цель этого процесса — максимально снизить риск, сделав развертывание в прод предсказуемой, безопасной и, по возможности, рутинной операцией, а не героическим актом. Сам "финальный этап" — часто всего лишь быстрое переключение трафика на уже протестированную и готовую к работе версию.