@Visteras
Любознателен, интересуюсь новым и старым :)

Что почитать что бы собрать как можно меньше граблей при деплое?

Вообщем задался целью в компании сделать нормальный деплой приложения на продакшен.
Сейчас работа идет так:
1) Надо что-то менять?
2) Заходим на сервер и меняем. Как вариант - меняем через всякие PhpStorm подключаясь через sftp/ftp.
Сам проект написан на PHP.
Согласитесь - очень не хороший вариант.
Что хочу:
1) Все разработчики работают через git. Это в принципе есть. Поднял bitbucket - ничего сложного не вижу.
2) Выкладка изменений при их наличии в репозитории. TeamCity с этим прекрасно справляется. нагрузка там не большая, так что проблем нет. С одной стороны. А вот с другой - интересует КАК сделать так что бы проект не останавливался? Пока остановился на варианте с деплоем в левую папку и rsync между этими двумя папками. Тоже не уверен что хороший вариант. Но работать вроде как должен.
3) Откат изменений в случае косяка. Вот тут вообще пока нет мыслей. Откат должен быть доступен "по кнопке". Т.е. нажал на кнопку - откат произошел. Если нужно(в идеале) - можно выбрать версию на которую производить откат.

Хороший знакомый посоветовал посмотреть на Docker. Но интересует что и как там смотреть.
С одной стороны - вроде как удобно. С другой - не совсем понятно как это все работает и как связываются разные модули проекта между собой.
Хм... а что делать с откатами изменений то? Как это должно выглядеть?
  • Вопрос задан
  • 1313 просмотров
Пригласить эксперта
Ответы на вопрос 3
Делайте папки версий
Папка проекта симлинком на папку версии
Перемена симлинка мгновенная
Ответ написан
iswitch
@iswitch
Web & iOS developer
Можно воспользоваться сервисом deploybot.com
Ответ написан
2 и 3 легко решаются с помощью указания докрута nginx/apache через симлинк, с хранением всех или последних развернутых версий в отдельных рядом лежащих каталогах, как указал Евгений Безымянников, но только в случаях или если нет схемы базы, или если она не меняется, или если приложение нормально работает с разными версиями схемы, не вылетая с ошибками типа "нет таблицы/поля" (в разумных пределах).

Иначе по быстрому можно вопрос решить только с остановкой проекта на время миграции, если база не поддерживает неблокирующее изменение схемы или поддерживает, но не для множественных изменений в одной транзакции, а в проекте требуются множественные, типа переноса столбца из одной таблицы в другую. В таких случаях для SQL баз я не нашёл способа реализовать zero-downtime без переработки приложения (триггеры, хранимки, вьюхи и т. п. - тоже часть приложения) такой что, оно либо временно (пока синкаются в фоне старые данные) пишет в две базы, читая из старой, либо определяет какая версия каких таблиц ему доступна.

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

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

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