Схема деплоя на наших проектах

Обновлять сайт на работающем сервере — задача не из простых. Любой, у кого в этом деле есть опыт, знает почему такую замену кода называют «горячей». Если что-то идет не так гладко, как планировалось, возникает «пожар»: сайт не работает, клиент несет убытки за каждую минуту простоя, обрывает вам телефон и подгоняет программистов. Звучит ужасно, не правда ли?

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

Чтобы контролировать версии кода мы используем GIT. Эта система широко распространена и отлично подходит для коллективной разработки. Репозиторий проекта мы предпочитаем хранить на GitHub, чтобы заказчик мог в любой момент проследить, на каком этапе находится проект. Нашим разработчикам доступна подробная статистика и различные вспомогательные функции, например, сервис для обновления структуры базы данных с помощью миграций, о которых мы подробно рассказывали в серии постов о миграции данных.

Схема деплоя на наших проектах

Сам проект доступен на трех площадках Demo:rc, Demo:clone и Product.

Product — это боевая площадка, которая работает на ветке master. На неё заходят пользователи проекта, поэтому ошибки недопустимы.

Demo:clone — копия боевой площадки. Она также работает на ветке master и каждые сутки автоматически синхронизирует свою базу данных с Product.

Demo:rc — площадка, на которую добавляется весь новый функционал. Она работает на ветке rc (релиз-кандидат). База данных синхронизируется с Product только по запросу.

Перед релизом нового функционала, сливаем ветку master с веткой rc. Затем проверяем работоспособность на площадке Demo: clone. Когда все найденные проблемы исправлены, код можно выкладывать на площадку Product.

Схема деплоя на наших проектах

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

С такой схемой деплоя «пожары» случаются намного реже, и «горячие» обновления функционала проектов на боевом сервере проходят более гладко, сохраняя нервные клетки как заказчикам, так и разработчикам.

Однако, даже с хорошо налаженным процессом обновлений на «бою» не стоит забывать программистскую мудрость: пятничный релиз ведет к рабочим выходным.

На данном сайте собираются метаданные пользователя (cookie, данные об IP-адресе и местоположении) для функционирования сайта. Если Вы не хотите чтобы эти данные обрабатывались, то должны покинуть сайт

Заявка
на сотрудничество

Как вас зовут? Заполните это поле
Адрес электронной почты Неверный формат почты
Телефон для связи Заполните это поле
Нажимая на кнопку «Отправить заявку»,
я даю согласие на обработку персональных данных