После пары “горячих” обновлений боевого сайта, в результате которых проект не работает несколько часов и заказчик обрывает телефон, попутно теряя прибыль, разработчики начинают задумываться о том, как сберечь свои нервы и отношения с заказчиком.
Мы тоже прошли через эти грабли и выработали для себя схему работы, которую теперь применяем на наших проектах. Схема подходит для любых проектов, которые уже размещены в сети и требуют постоянных (итерационных) обновлений функционала. [spoiler] В качестве системы контроля версий кода мы используем GIT. Эта система зарекомендовала себя с самой лучшей стороны и отвечает всем требованиям коллективной разработки. Репозиторий проекта мы предпочитаем хранить на GitHub, что позволяет заказчику видеть ход проекта в реальном времени. Для наших разработчиков доступна подробная статистика и различные вспомогательные функции на подобие сервиса для обновления структуры БД с помощью миграций.
Сам проект доступен на трех площадках 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, минуя стандартную схему.
Данная схема деплоя позволила минимизировать количество “пожаров”, возникающих в результате “горячих” обновлений функционала проектов, расширила зону комфорта программистов.
И завершим пост народной мудростью: пятничный релиз ведет к рабочим выходным.
Чебан Валерий, пока только два. Большая CRM-система на YII и большой интернет-магазин на Битрикс. Тут надо понимать, что эта схема подходит только для проектов определенного масштаба. Для обычных корпоративных сайтов она конечно избыточна.
Идея клевая, еще бы увидеть те скрипты для синхронизации БД. И как обстоит дело с изменением БД на стороне разработчика, ну надо ему добавить Инфоблок например, он добавил, завел пару элементов, а в это время контентщик заказчика на продакте заводит еще пару элементов с теми же ID что и у девелопера. Как быть в этом случае?
Диденко Денис написал: Инфоблок например, он добавил, завел пару элементов, а в это время контентщик заказчика на продакте заводит еще пару элементов с теми же ID что и у девелопера. Как быть в этом случае?
Пусть заводит. Как это может мешать работе проекта?
Диденко Денис, приведите пример, когда ID элементов используются в коде проекта?
БД у каждого разработчика своя. И если он сделал новость с ID = 10 и на production сделали новость с таким же ID, но с другим наполнением, то ничего страшного.
Максим Мул, могу привести и такие примеры, но не в этом суть, свойства, значения свойств типа список, инфоблоки которые могут создаваться и на прокашене и на бое, в общем пока вопросов больше чем ответов.
Максим Мул, на самом деле как таковой деплой вопросов не вызывает, есть git, есть mercurial, тут давно все изобретено, самая большая трудность в командной работе с битрикс это именно данные, на хабре была интересная статья по этому поводу, хочу прикрутить такую схему, но все руки не доходят http://habrahabr.ru/post/221979/
Диденко Денис, у нас сейчас в производстве находится модуль миграций. Пока обкатаем на своих проектах и выложим в пользование. Если интересно, то могу дать ссылку на github раньше, как будет готова beta.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».