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

Question

[Alexey Bille]

Что используется:
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, то такой способ не подойдет.

Как обычно решают такие проблемы?

Answer 1

[Алексей]

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

По поводу приведенных примеров
1 - совершенно верно, проблем нет
2 - не обязательно, ведь в процессе деплоя может одновременно работать новый и старый код
3 - если речь идет о невозможности реализации обратной совместимости, то данную проблему следует избегать на уровне архитектуры и планирования. Красивого решения она не имеет, но есть варианты, либо потребуется полная остановка системы для применения несовместимых миграций. Либо потребуется реализация, которая позволит работать двум версиям кода и базы, с возможностью ручной синхронизации изменений произошедших со старой версией в момент деплоя.

Answer 2

[eustatos]

Рекомендую посмотреть в сторону Docker.
В контейнере развернуть те сервисы, которые используются.
При деплое собираются образы сервисов в контейнере,
отрабатывают скрипты для статики (если нужно) и миграции.
Смена контейнера занимает доли секунды - это и будет временем простоя.
Из известных мне это самый быстрый способ обновиться на продакш.

Answer 3

[rPman]

В одном месте, одно из требований у меня было - подготовить deb пакет со скриптами первичной установки и обновления (там не было классической базы но смысл в том чтобы и ее тоже при необходимости обновлять), причем необходимо было гарантировать что deb корректно обновит с любой предыдущей версии (это легко решается последовательным исполнением скриптов каждой промежуточной версии, не так эффективно зато однозначно). Откат на предыдущую версию не требовался.

Comments

[Roman K]

Кул стори