Обновлять сайт на работающем сервере — задача не из простых. Любой, у кого в этом деле есть опыт, знает почему такую замену кода называют «горячей». Если что-то идет не так гладко, как планировалось, возникает «пожар»: сайт не работает, клиент несет убытки за каждую минуту простоя, обрывает вам телефон и подгоняет программистов. Звучит ужасно, не правда ли?
Мы дорожим своими клиентами, поэтому выработали для себя схему деплоя, которая исключает подобные ситуации. Она подходит для любых проектов, которые уже размещены в сети и требуют постоянных (итерационных) обновлений функционала.
Чтобы контролировать версии кода мы используем GIT. Эта система широко распространена и отлично подходит для коллективной разработки. Репозиторий проекта мы предпочитаем хранить на GitHub, чтобы заказчик мог в любой момент проследить, на каком этапе находится проект. Нашим разработчикам доступна подробная статистика и различные вспомогательные функции, например, сервис для обновления структуры базы данных с помощью миграций, о которых мы подробно рассказывали в серии постов о миграции данных.
Сам проект доступен на трех площадках Demo:rc, Demo:clone и Product.
Product — это боевая площадка, которая работает на ветке master. На неё заходят пользователи проекта, поэтому ошибки недопустимы.
Demo:clone — копия боевой площадки. Она также работает на ветке master и каждые сутки автоматически синхронизирует свою базу данных с Product.
Demo:rc — площадка, на которую добавляется весь новый функционал. Она работает на ветке rc (релиз-кандидат). База данных синхронизируется с Product только по запросу.
Перед релизом нового функционала, сливаем ветку master с веткой rc. Затем проверяем работоспособность на площадке Demo: clone. Когда все найденные проблемы исправлены, код можно выкладывать на площадку Product.
Иногда бывает так, что какие-то ошибки всё-же проглядели, и они всплывают на Product. В таких случаях нельзя терять ни секунды, поэтому исправления выкладываем напрямую в ветку master, отказываясь от стандартной процедуры.
С такой схемой деплоя «пожары» случаются намного реже, и «горячие» обновления функционала проектов на боевом сервере проходят более гладко, сохраняя нервные клетки как заказчикам, так и разработчикам.
Однако, даже с хорошо налаженным процессом обновлений на «бою» не стоит забывать программистскую мудрость: пятничный релиз ведет к рабочим выходным.
