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