После пары “горячих” обновлений боевого сайта, в результате которых проект не работает несколько часов и заказчик обрывает телефон, попутно теряя прибыль, разработчики начинают задумываться о том, как сберечь свои нервы и отношения с заказчиком.
Мы тоже прошли через эти грабли и выработали для себя схему работы, которую теперь применяем на наших проектах. Схема подходит для любых проектов, которые уже размещены в сети и требуют постоянных (итерационных) обновлений функционала.
[spoiler]
В качестве системы контроля версий кода мы используем . Эта система зарекомендовала себя с самой лучшей стороны и отвечает всем требованиям коллективной разработки. Репозиторий проекта мы предпочитаем хранить на , что позволяет заказчику видеть ход проекта в реальном времени. Для наших разработчиков доступна подробная статистика и различные вспомогательные функции на подобие сервиса для обновления структуры БД с помощью миграций.
Сам проект доступен на трех площадках Demo:rc, Demo:clone и Product.
Product - это боевая площадка, которую используют пользователи проекта и на ней не должно быть ошибок. Площадка работает на ветке master.
Demo:clone - представляет собой копию боевой площадки и также работает на ветке master. БД прощадки Demo:clone раз в сутки автоматически синхронизируется с площадкой Product.
Demo:rc - площадка, на которую выливается весь новый функционал. Площадка работает на ветке rc (релиз-кандидат). БД приводится в актуальное состояние с площадкой Product по запросу.
По мере накопления функционала принимается решение о релизе, тогда происходит слияние ветки master с веткой rc. Функционал проверяется на площадке Demo:clone. После исправления найденных замечаний происходит выкладывание кода на площадку Product.
В частных случаях бывает так, что на Product всплывают ошибки, которые надо срочно исправить (fix). В этом случае программист исправления выкладывает напрямую в ветку master, минуя стандартную схему.
Данная схема деплоя позволила минимизировать количество “пожаров”, возникающих в результате “горячих” обновлений функционала проектов, расширила зону комфорта программистов.
И завершим пост народной мудростью: пятничный релиз ведет к рабочим выходным.
Мы тоже прошли через эти грабли и выработали для себя схему работы, которую теперь применяем на наших проектах. Схема подходит для любых проектов, которые уже размещены в сети и требуют постоянных (итерационных) обновлений функционала.
[spoiler]
В качестве системы контроля версий кода мы используем . Эта система зарекомендовала себя с самой лучшей стороны и отвечает всем требованиям коллективной разработки. Репозиторий проекта мы предпочитаем хранить на , что позволяет заказчику видеть ход проекта в реальном времени. Для наших разработчиков доступна подробная статистика и различные вспомогательные функции на подобие сервиса для обновления структуры БД с помощью миграций.
Сам проект доступен на трех площадках Demo:rc, Demo:clone и Product.
Product - это боевая площадка, которую используют пользователи проекта и на ней не должно быть ошибок. Площадка работает на ветке master.
Demo:clone - представляет собой копию боевой площадки и также работает на ветке master. БД прощадки Demo:clone раз в сутки автоматически синхронизируется с площадкой Product.
Demo:rc - площадка, на которую выливается весь новый функционал. Площадка работает на ветке rc (релиз-кандидат). БД приводится в актуальное состояние с площадкой Product по запросу.
По мере накопления функционала принимается решение о релизе, тогда происходит слияние ветки master с веткой rc. Функционал проверяется на площадке Demo:clone. После исправления найденных замечаний происходит выкладывание кода на площадку Product.
В частных случаях бывает так, что на Product всплывают ошибки, которые надо срочно исправить (fix). В этом случае программист исправления выкладывает напрямую в ветку master, минуя стандартную схему.
Данная схема деплоя позволила минимизировать количество “пожаров”, возникающих в результате “горячих” обновлений функционала проектов, расширила зону комфорта программистов.
И завершим пост народной мудростью: пятничный релиз ведет к рабочим выходным.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
