Какие лучшие практики для развертывания Symfony приложения с использованием Jenkins?

У меня есть проект на Symfony, и я хочу настроить его развертывание с помощью Jenkins. В процессе развертывания Symfony есть несколько важных моментов: 

1. Использование команды `composer install`. 
2. Некоторые разработчики рекомендуют выполнять команду `composer install` на сервере после переноса файлов. Однако, цель в том, чтобы успешно собрать проект, и если команда `composer install` не выполнится на продакшене, это ставит под угрозу весь процесс.

Поэтому правильнее было бы собрать проект в Jenkins и затем скопировать его на сервер, верно? 

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

Как вы считаете, какие есть практики для эффективного развертывания Symfony-проекта с учетом этих моментов?
  • 18 сентября 2024 г. 16:43
Ответы на вопрос 2
Развертывание Symfony-приложения с использованием Jenkins действительно требует особого внимания к различным аспектам, таким как управление зависимостями (через Composer), миграции базы данных и настройка среды. Вот некоторые лучшие практики, которые могут помочь вам в этом процессе:

### 1. Подготовка среды CI/CD

#### Настройка Jenkins
- Убедитесь, что Jenkins настроен для автоматического запуска ваших сборок при новых коммитах (например, с использованием вебхуков Git).
- Убедитесь, что Jenkins имеет доступ к вашему серверу (через SSH или другой способ) для выполнения необходимых команд.

### 2. Установка зависимостей

#### Composer
- Лучше всего выполнять команду `composer install` во время сборки в Jenkins. Это позволит вам убедиться, что версия зависимостей корректна и нет ошибок совместимости.
- Чтобы избежать проблем, связанных с продакшен-окружением, вы можете использовать флаг `--no-dev` и `--optimize-autoloader` при выполнении `composer install`, чтобы избавиться от ненужных пакетов и оптимизировать автозагрузчик:

  ```bash
  composer install --no-dev --optimize-autoloader
  ```

### 3. Сборка артефактов

- Вместо непосредственного копирования файлов на сервер вы можете создать zip-архив или tarball вашего приложения (артефакт сборки), который содержит все необходимые файлы, включая скомпилированные ресурсы и оптимизированный код.

### 4. Деплой на сервер

- После сборки и упаковки вашего приложения на Jenkins, используйте SSH или другие сервисы для перемещения артефактов на продакшен-сервер.
- Например, с помощью команды `scp` или с помощью плагина для Jenkins, который позволяет выполнять деплой.

### 5. Миграции базы данных

- Выполняйте миграции на сервере после развертывания файлов. Это гарантирует, что вы работаете с актуальной базой данных.
- Убедитесь, что ваше приложение имеет доступ к базе данных на сервере, и используйте команду `doctrine:migrations:migrate`. Это можно сделать в Jenkins после развертывания файлов. При этом можно использовать флаг `--no-interaction`, чтобы избежать ручного ввода:

  ```bash
  php bin/console doctrine:migrations:migrate --no-interaction
  ```

### 6. Отключение на время развертывания

- Рассмотрите возможность временного отключения вашего приложения во время развертывания, чтобы избежать ситуации, когда пользователи взаимодействуют с неактуальной версией. Это можно сделать с помощью maintenance mode (режима обслуживания).
- Symfony предлагает команду `php bin/console down` для активации режима обслуживания.

### 7. Логирование и мониторинг

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

### 8. Анализ и откат

- Храните резервные копии базы данных, чтобы вы могли откатиться к предыдущей версии в случае неудачного развертывания.
- Разработайте стратегию отката (rollback), чтобы вы могли легко вернуть предыдущее состояние приложения, если что-то пойдет не так.

### Заключение

Каждый проект уникален, и подходы могут варьироваться, но использование Jenkins для сборки, тестирования и развертывания с учетом вышеперечисленных шагов поможет вам управлять процессом эффективнее и снизить риски возможных ошибок.
Я на своих проектах использую следующий подход: 
1. создается сборка, на тестовом сервере, устанавливаются зависимости. При этом база создается каждый раз новая (схема), либо перезаписывается существующая. Дамп используется тот, который был взят с прода, спустя некоторое время существования последних обновлений кода на проде. Накатываются все миграции, обновления (миграциями пользуюсь только для тех случаев, когда надо что то подредактировать в данных, при обновлении сущностей).
2. Прогоняются тесты
3. При успешном прохождении тестов, создается архив кода, с исключением из него директорий var, vendor
3. Делается архив (полный) на проде текущего состояния приложения, помещается в отдельную папку. Этот архив служит для резервного отката
4. Заливается архив из шага 3, устанавливаются все зависимости, и В РУЧНУЮ накатываются миграции и обновления на БД

Проблем не знаю при таком подходе. Можно откатится в любой момент, ничего не сломается никогда. Даже БД, всегда есть дамп из хостинга или облака (тут отдельная настройка, например если у облака есть CLI, можно посылать в начале деплоя команду на прод, чтобы создался дамп). Но тут индивидуальный подход всегда
Похожие вопросы