Деплой на 8

Аватар пользователя vlucas vlucas 29 марта 2018 в 16:42

Друзья, знаю, что тема изъезженная, но всё-таки посоветуйте инструменты или рецепты деплоя для 8. Кто как это делает?

Работаю 1, код локальный - тут всё делаю, тестирую, надо выкладывать на боевой - тут не знаю, что взять за основу, хочется автоматизировать более-менее.

Вот например, вчера было обновление, на локальном: composer update, cd web, drush updb, может что-то новое накликаю, drush cex. Теперь надо это выгрузить всё на прод. Вот чем это лучше делать, учитывая, что на боевом нужно будет импортировать конфиги, выполнить обновление базы, почистить кеш?

Сейчас смотрю просто в сторону написание скрипта обёртки для rsync, но может быть я придумываю велосипед? Прошу советов, решений, которыми сами пользуетесь!

Комментарии

Аватар пользователя adubovskoy adubovskoy 29 марта 2018 в 16:59

Мы сидим на 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 и писать.

Аватар пользователя adubovskoy adubovskoy 29 марта 2018 в 17:11

composer install, да, запускаем, чтобы он забрал новых вендоров из composer.lock . это единственный способ - другой это тянуть вендоры в гите, но как-то нам не нравится эта мысль)

Аватар пользователя vlucas vlucas 29 марта 2018 в 17:15

Вот не нравится мне эта идея композер на продакшене запускать. Не так давно и в канале телеграм советовали этого не делать, он же медленный жутко и ресурсов жрёт. А разве если rsync всё синхронизировать не проще ли будет? И в чём минусы и преимущества композера на проде?

Аватар пользователя bumble bumble 29 марта 2018 в 17:00

В идеале: Локалка -> GIT репо -> CI сервер -> Prod

Доставка и хранение кода - однозначно GIT.

Обновление прода, если нет сборочного сервера - синкать вручную, в админке, или ходить на сервер по SSH и там звать все апдейты, синки конфигов, очистки кешей, запуск обновлений и т.п.

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

Если более серьезно подходить, то от подготовки образа для доккера, до полноценных ансамблей. Здесь так просто не посоветуешь, тема широка до безобразия...

Аватар пользователя vlucas vlucas 29 марта 2018 в 17:13

bumble wrote:
В идеале: Локалка -> GIT репо -> CI сервер -> Prod

Согласен, но написал, что работаю 1, и проект небольшой, поэтому есть 2 узла: dev и prod

bumble wrote:
Доставка и хранение кода - однозначно GIT.

конечно храню код, но только кастом, остальное - композитор

bumble wrote:

Обновление прода, если нет сборочного сервера - синкать вручную, в админке, или ходить на сервер по SSH и там звать все апдейты, синки конфигов, очистки кешей, запуск обновлений и т.п.

Может как то у автоматизировать? Например у гита есть хуки, есть ли что-то подобное если делать rsync?

bumble wrote:

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

Но локале всё через композер, ну а если делать rsync то зачем на проде композер запускать?

Аватар пользователя bumble bumble 29 марта 2018 в 17:16

lukasss-vs wrote:

Может как то у автоматизировать? Например у гита есть хуки, есть ли что-то подобное если делать rsync?

А зачем нужен rsync если все GIT'ом доставляется?

Аватар пользователя vlucas vlucas 29 марта 2018 в 17:19

Блин, ну чтобы не хранить всё в гите )))
Мне вот думается что это верно.
Да на 7 у меня проекты так и были, хотя я думаю, тоже что не верно так, но вот на 8 с этим композитором хочется мало-мальского перфекционизма )))

Аватар пользователя bumble bumble 29 марта 2018 в 17:21

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

Аватар пользователя adubovskoy adubovskoy 29 марта 2018 в 17:17

1. composer update медленный. composer install быстрый. он просто доставит то чего не хватает.
2. если composer install валится - вы увидите это на тестах сборки в stage, до прода.

Аватар пользователя vlucas vlucas 29 марта 2018 в 17:20

С такой схемой я должен и меть тестовый сервер, правильно? и на тестовом выполнять композер, если я исклюяаю это звено и оставляю только локальный где работаю и прод. Тогда как лучше?

Аватар пользователя bumble bumble 29 марта 2018 в 17:19
1

Начинает казаться что ТС просто хочет найти оправдания использования rsync...

Аватар пользователя vlucas vlucas 29 марта 2018 в 17:21

Да нет, на самом деле никаких оправданий ))) Просто не хочется бросать композер )))

Аватар пользователя vlucas vlucas 29 марта 2018 в 17:33

Всем спасибо! Сделал вывод, что composer install не страшно на сервере, тема закрыта!