alexey_bille
@alexey_bille
Web developer

Как правильно деплоить проект на php?

Что используется:
Laravel (nginx + php-fpm + mysql) + git

Для изменений в базе используются миграции laravel.
Как применять миграции без 5XX ошибок?

  1. Допустим из таблицы удаляется столбец - нет проблем, затягиваем коммит с кодом который не использует столбец -> запускаем миграции
  2. Допустим в таблицу добавился столбец - разбить деплой на 2 коммита?
    1. с миграцией которая просто добавит столбец
    2. с кодом который его использует


  3. Допустим отношение с hasMany поменялось на manyToMany - так же разбить на 2 коммита?
    1. добавляет таблицу которая связывает 2 другие таблицы, переносит отношения
    2. код который работает уже с manyToMany + миграция которая удаляет отношение hasMany. Тут нужно учесть что между деплоем первого и второго коммита могут появиться новые записи, их нужно отслеживать на уровне базы (тригерами)? и при деплое второго его удалять?



Если обычный сайт, то можно не разбивать на коммиты, закрыть сайт (php artisan down) -> запустить миграции -> открыть сайт (php artisan up)

Если проект используется как api, то такой способ не подойдет.

Как обычно решают такие проблемы?
  • Вопрос задан
  • 203 просмотра
Решения вопроса 1
Shark13
@Shark13
Для решения данной проблемы требуется обеспечивать обратную совместимость версий релизов. Другими словами все новые изменения не должны ломать старый код. Общий порядок деплоя новой версии происходит в 2 этапа:
1 - применение миграций и поднятие новой версии парралельно со старой,
2 - старая версия прекращает принимать новые запросы и останавливается при окончании обработки существующих соединенй (graceful shutdown).

По поводу приведенных примеров
1 - совершенно верно, проблем нет
2 - не обязательно, ведь в процессе деплоя может одновременно работать новый и старый код
3 - если речь идет о невозможности реализации обратной совместимости, то данную проблему следует избегать на уровне архитектуры и планирования. Красивого решения она не имеет, но есть варианты, либо потребуется полная остановка системы для применения несовместимых миграций. Либо потребуется реализация, которая позволит работать двум версиям кода и базы, с возможностью ручной синхронизации изменений произошедших со старой версией в момент деплоя.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@dmitrylee
а зачем такой геморрой с коммитами, когда можно просто сделать миграцию, которая добавит, изменит или удалит нужное количество столбцов и т.д.?
Ответ написан
@eustatos
Рекомендую посмотреть в сторону Docker.
В контейнере развернуть те сервисы, которые используются.
При деплое собираются образы сервисов в контейнере,
отрабатывают скрипты для статики (если нужно) и миграции.
Смена контейнера занимает доли секунды - это и будет временем простоя.
Из известных мне это самый быстрый способ обновиться на продакш.
Ответ написан
@rPman
В одном месте, одно из требований у меня было - подготовить deb пакет со скриптами первичной установки и обновления (там не было классической базы но смысл в том чтобы и ее тоже при необходимости обновлять), причем необходимо было гарантировать что deb корректно обновит с любой предыдущей версии (это легко решается последовательным исполнением скриптов каждой промежуточной версии, не так эффективно зато однозначно). Откат на предыдущую версию не требовался.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы