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

Question

[Анатолий Евладов]

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

Хороший знакомый посоветовал посмотреть на Docker. Но интересует что и как там смотреть.
С одной стороны - вроде как удобно. С другой - не совсем понятно как это все работает и как связываются разные модули проекта между собой.
Хм... а что делать с откатами изменений то? Как это должно выглядеть?

Answer 1

[Евгений Безымянников]

Делайте папки версий
Папка проекта симлинком на папку версии
Перемена симлинка мгновенная

Comments

[Анатолий Евладов]

Хм... про симлинки не думал, а, видимо, зря...
Т.е. получается создаем папку имя которой - это хеш для получения изменений с гита, и рядом ложим скрипт который будет менять симлинк.... В принципе - вариант интересный.... надо будет подумать про него подробнее...

[Евгений Безымянников]

Visteras: хэш - непонятное число. Называйте папки по номеру сборки если нумеруете или просто v1, v2, v3 и т.д.

Answer 2

[Евгений Колотилин]

Можно воспользоваться сервисом deploybot.com

Comments

[Анатолий Евладов]

К сожалению использовать разные сервисы нельзя. Только то что можно запустить у себя на серверах.

Answer 3

[Владимир Чернышев]

2 и 3 легко решаются с помощью указания докрута nginx/apache через симлинк, с хранением всех или последних развернутых версий в отдельных рядом лежащих каталогах, как указал Евгений Безымянников, но только в случаях или если нет схемы базы, или если она не меняется, или если приложение нормально работает с разными версиями схемы, не вылетая с ошибками типа "нет таблицы/поля" (в разумных пределах).

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

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

Comments

[Анатолий Евладов]

Мне с БД проще. Она не меняется. Или меняется но не критично. По крайне мере таких изменений что что-то упадет - там не будет.
Т.е. работаем только с файлами проекта.
Надо иметь возможность сделать выкладку изменений на сервер, и потом за 1 шаг их подцепить и все изменить. и таким же образом если необходимо откатить изменения до нужного коммита.
Откат подобный необходим по той причине что тестов у проекта нет вообще. Я просто не рискну переходить на подобную схему работы не имея возможности откатить изменения. А тесты уже придется добавлять со временем, потому что там и код такой что их туда не добавить :(

[Владимир Чернышев]

Ну тогда просто.

Делаете на сервере структуру каталогов типа:
/var/www/sitе/share/[logs,htdocs/uploads,config/database.conf] #файлы, которые не хранятся в репе и не должны обнуляться при обновлении или откате
/var/www/site/releases/{version}|{commit-id}|{timestamp} #в общем как-то отделяете разные версии
/var/www/site/releases/{version}|{commit-id}|{timestamp}/[logs,htdocs/uploads,config/database.conf] -> /var/www/sitе/share/[logs,htdocs/uploads,config/database.conf]
/var/www/site/current -> /var/www/site/releases/{current} # текущая версия

В конфигах веб-сервера указываете document root /var/www/site/current/htdocs и переключаетесь между версиями командами типа ln -s /var/www/site/releases/{version}|{commit-id}|{timestamp} var/www/site/current

Разворачивание из репозитория в /var/www/site/releases/{version}|{commit-id}|{timestamp} делаете любым удобным способом, как делаете в "варианте с деплоем в левую папку", только "левая папка" єто /var/www/site/releases/{version}|{commit-id}|{timestamp}, а вместо rsync - ln )

Ну а вообще, всё это (и больше) уже сделано в ruby-приложении capistrano, которое разработано для рельс, но вполне справляется с деплоем пхп приложений, нужно только конфиги настроить.

[Анатолий Евладов]

Владимир Чернышев: а в capistrano есть откат изменений на более старую версию?
Просто очень не хочется возиться с руби. Был опыт работы с ним, не скажу что понравилось :(...

[Владимир Чернышев]

Visteras: есть