Правильные практики деплоя symfony приложения с помощью Jenkins?

Question

[pwooolf]

У меня есть symfony проект и я хочу его деплоить с помощью jenkins

В symfony при развертывании есть несколько моментов
- composer install
кто-то пишет после переноса файлов нужно подключится к серверу и там выполнить composer install, но ведь суть в том, чтобы собрать успешно проект, какой смысл в сборке, если composer install упадет на проде... Успешно собираем в jenkins и копируем на сервер, верно?

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

Comments

[tukreb]

компосер не может упасть, если он упадёт на проде, значит он никогда не работал и в дев. А значит время сильно пинать разработчика этого проекта.

[BoShurik]

tukreb, теоретически могли не доставить какую-нибудь зависимость на прод, которая есть на деве
pwooolf, посмотрите в сторону deployer или capistrano (там есть таски для symfony) и вот их уже запускать с помощью jenkins

Answer 1

[Владислав Писарев]

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

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