Встречайте Envoyer.io (часть 1)

[JiLiZART]

Деплой для домохозяек? для тех кто капистрано не осилил?
<параноик> я бы не доверял деплой приложения стороннему сервису </параноик>

[SerafimArts]

Всё это делается несколькими командами (если по простому):

Скрытый текст

    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

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

[AmdY]

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

[SerafimArts]

Rockeeter?
*Гугл мне подсовывает фильмец

[haskel]

Имеется ввиду это https://github.com/rocketeers/rocketeer

[SerafimArts]

И оно делает вначале бекап всей БД, загружает в новую, потом перелиновывает ссылки на новую и одновременно делает миграции? Или как избавляется от проблем несовпадения версий таблиц БД (миграций) и текущего кода, чтобы реализовать «бесперебойный» деплой?

[SerafimArts]

Ну а если просто с бекапом сайта (без БД) и возможностью восстановиться, то вот так, т.е. не намного сложнее: pastebin.com/2gCEtABm (прошу прощения за специфический синтаксис)

[nazarpc]

А что тогда происходит в момент накатки миграций с предыдущей версией кода, если она не полностью совместима с новой структурой БД?
По-моему в общем виде zero downtime сделать невозможно, можно в частном, когда у вас есть переходная версия кода, которая работает с обеими версиями БД, тогда вы накатываете сначала этот код, потом миграции, потом обрываете обратную совместимость.

[SerafimArts]

Можно только с помощью репликации, я уже выше высказывал это. Но это требует более чем какого-то внешнего сервиса. Так что расходимся, нас опять…

[haskel]

Ой-ой, это зачем это? Надо просто писать миграции, которые не ломают обратную совместимость. А тяжелые миграции обычно накатываются аккуратненько заранее, перед релизом.
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.

[alexsoft]

По дефолту в скрипте не выполняются миграции. Надо самому этим заниматься.