Comments 11
Деплой для домохозяек? для тех кто капистрано не осилил?
<параноик> я бы не доверял деплой приложения стороннему сервису </параноик>
<параноик> я бы не доверял деплой приложения стороннему сервису </параноик>
Всё это делается несколькими командами (если по простому):
А останавливать сервер надо в обязательном порядке, если отсутствует репликация БД, т.к. выполнение миграций начисто может нарушить логику приложений, вплоть до фатальных ошибок.
Скрытый текст
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
А останавливать сервер надо в обязательном порядке, если отсутствует репликация БД, т.к. выполнение миграций начисто может нарушить логику приложений, вплоть до фатальных ошибок.
Скорее всего там аналог rocketeer, поддерживается сразу несколько релизов которые переключается линком, миграции накатываются до переключения релизной ветки, так что проблем быть не должно.
Rockeeter?
*Гугл мне подсовывает фильмец
*Гугл мне подсовывает фильмец
Имеется ввиду это https://github.com/rocketeers/rocketeer
И оно делает вначале бекап всей БД, загружает в новую, потом перелиновывает ссылки на новую и одновременно делает миграции? Или как избавляется от проблем несовпадения версий таблиц БД (миграций) и текущего кода, чтобы реализовать «бесперебойный» деплой?
Ну а если просто с бекапом сайта (без БД) и возможностью восстановиться, то вот так, т.е. не намного сложнее: pastebin.com/2gCEtABm (прошу прощения за специфический синтаксис)
А что тогда происходит в момент накатки миграций с предыдущей версией кода, если она не полностью совместима с новой структурой БД?
По-моему в общем виде zero downtime сделать невозможно, можно в частном, когда у вас есть переходная версия кода, которая работает с обеими версиями БД, тогда вы накатываете сначала этот код, потом миграции, потом обрываете обратную совместимость.
По-моему в общем виде zero downtime сделать невозможно, можно в частном, когда у вас есть переходная версия кода, которая работает с обеими версиями БД, тогда вы накатываете сначала этот код, потом миграции, потом обрываете обратную совместимость.
Ой-ой, это зачем это? Надо просто писать миграции, которые не ломают обратную совместимость. А тяжелые миграции обычно накатываются аккуратненько заранее, перед релизом.
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.
По дефолту в скрипте не выполняются миграции. Надо самому этим заниматься.
Sign up to leave a comment.
Встречайте Envoyer.io (часть 1)