29 марта 2018 в 16:42
Друзья, знаю, что тема изъезженная, но всё-таки посоветуйте инструменты или рецепты деплоя для 8. Кто как это делает?
Работаю 1, код локальный - тут всё делаю, тестирую, надо выкладывать на боевой - тут не знаю, что взять за основу, хочется автоматизировать более-менее.
Вот например, вчера было обновление, на локальном: composer update, cd web, drush updb, может что-то новое накликаю, drush cex. Теперь надо это выгрузить всё на прод. Вот чем это лучше делать, учитывая, что на боевом нужно будет импортировать конфиги, выполнить обновление базы, почистить кеш?
Сейчас смотрю просто в сторону написание скрипта обёртки для rsync, но может быть я придумываю велосипед? Прошу советов, решений, которыми сами пользуетесь!
Комментарии
Мы сидим на gitlabci.
dev:
composer requre ....
drush en
.... работа ...
drush cex sync
git add . / commit / push
git checkout stage
git merge dev
git push
GitlabCI-воркер идет на stage, делает git pull, composer install, drush cim sync, ... сообщает о том что все ок.
есты сборки этого на stage
git checkout master
git merge stage
git push origin master
GitlabCI-воркер идет на прод, делает git pull, composer install, drush cim sync, ... сообщает о том что все ок.
это кратко. подробно - надо искать статьи по CI и писать.
Правильно ли понимаю, что вы запускаете композер на продакшене?
composer install, да, запускаем, чтобы он забрал новых вендоров из composer.lock . это единственный способ - другой это тянуть вендоры в гите, но как-то нам не нравится эта мысль)
Вот не нравится мне эта идея композер на продакшене запускать. Не так давно и в канале телеграм советовали этого не делать, он же медленный жутко и ресурсов жрёт. А разве если rsync всё синхронизировать не проще ли будет? И в чём минусы и преимущества композера на проде?
В идеале: Локалка -> GIT репо -> CI сервер -> Prod
Доставка и хранение кода - однозначно GIT.
Обновление прода, если нет сборочного сервера - синкать вручную, в админке, или ходить на сервер по SSH и там звать все апдейты, синки конфигов, очистки кешей, запуск обновлений и т.п.
Если проект не особо крупный, как вариант - заводить репо на всю кодовую базу. Тогда можно на локалке все делать, потом просто пушить в баре, и оттуда либо автоматом настроить стягивание в прод, или ручками ходить. Это позволит отказаться от композерных апдейтов на проде.
Если более серьезно подходить, то от подготовки образа для доккера, до полноценных ансамблей. Здесь так просто не посоветуешь, тема широка до безобразия...
Согласен, но написал, что работаю 1, и проект небольшой, поэтому есть 2 узла: dev и prod
конечно храню код, но только кастом, остальное - композитор
Может как то у автоматизировать? Например у гита есть хуки, есть ли что-то подобное если делать rsync?
Но локале всё через композер, ну а если делать rsync то зачем на проде композер запускать?
А зачем нужен rsync если все GIT'ом доставляется?
Блин, ну чтобы не хранить всё в гите )))
Мне вот думается что это верно.
Да на 7 у меня проекты так и были, хотя я думаю, тоже что не верно так, но вот на 8 с этим композитором хочется мало-мальского перфекционизма )))
Можно все это дело атомарненько решать.
Разворачивать не на работающей сборке, а рядом. И только после успешного завершения - менять симлинк на рабочую директорию.
1. composer update медленный. composer install быстрый. он просто доставит то чего не хватает.
2. если composer install валится - вы увидите это на тестах сборки в stage, до прода.
С такой схемой я должен и меть тестовый сервер, правильно? и на тестовом выполнять композер, если я исклюяаю это звено и оставляю только локальный где работаю и прод. Тогда как лучше?
Начинает казаться что ТС просто хочет найти оправдания использования rsync...
Да нет, на самом деле никаких оправданий ))) Просто не хочется бросать композер )))
Всем спасибо! Сделал вывод, что composer install не страшно на сервере, тема закрыта!
Самый простой способ - иметь на продакшене гит, композер и драш.