Комментарии 11
Деплой для домохозяек? для тех кто капистрано не осилил?
<параноик> я бы не доверял деплой приложения стороннему сервису </параноик>
<параноик> я бы не доверял деплой приложения стороннему сервису </параноик>
+6
Всё это делается несколькими командами (если по простому):
А останавливать сервер надо в обязательном порядке, если отсутствует репликация БД, т.к. выполнение миграций начисто может нарушить логику приложений, вплоть до фатальных ошибок.
Скрытый текст
artisan down
composer self-update
composer update
git checkout -f
git pull origin master
artisan migrate --force
artisan cache:clear
rm -rf public/assets
mkdir public/assets
artisan up
А останавливать сервер надо в обязательном порядке, если отсутствует репликация БД, т.к. выполнение миграций начисто может нарушить логику приложений, вплоть до фатальных ошибок.
+2
Скорее всего там аналог rocketeer, поддерживается сразу несколько релизов которые переключается линком, миграции накатываются до переключения релизной ветки, так что проблем быть не должно.
0
Rockeeter?
*Гугл мне подсовывает фильмец
*Гугл мне подсовывает фильмец
0
Имеется ввиду это https://github.com/rocketeers/rocketeer
0
И оно делает вначале бекап всей БД, загружает в новую, потом перелиновывает ссылки на новую и одновременно делает миграции? Или как избавляется от проблем несовпадения версий таблиц БД (миграций) и текущего кода, чтобы реализовать «бесперебойный» деплой?
0
Ну а если просто с бекапом сайта (без БД) и возможностью восстановиться, то вот так, т.е. не намного сложнее: pastebin.com/2gCEtABm (прошу прощения за специфический синтаксис)
0
А что тогда происходит в момент накатки миграций с предыдущей версией кода, если она не полностью совместима с новой структурой БД?
По-моему в общем виде zero downtime сделать невозможно, можно в частном, когда у вас есть переходная версия кода, которая работает с обеими версиями БД, тогда вы накатываете сначала этот код, потом миграции, потом обрываете обратную совместимость.
По-моему в общем виде zero downtime сделать невозможно, можно в частном, когда у вас есть переходная версия кода, которая работает с обеими версиями БД, тогда вы накатываете сначала этот код, потом миграции, потом обрываете обратную совместимость.
0
Ой-ой, это зачем это? Надо просто писать миграции, которые не ломают обратную совместимость. А тяжелые миграции обычно накатываются аккуратненько заранее, перед релизом.
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.
0
По дефолту в скрипте не выполняются миграции. Надо самому этим заниматься.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встречайте Envoyer.io (часть 1)