После пары “горячих” обновлений боевого сайта, в результате которых проект не работает несколько часов и заказчик обрывает телефон, попутно теряя прибыль, разработчики начинают задумываться о том, как сберечь свои нервы и отношения с заказчиком.
Мы тоже прошли через эти грабли и выработали для себя схему работы, которую теперь применяем на наших проектах. Схема подходит для любых проектов, которые уже размещены в сети и требуют постоянных (итерационных) обновлений функционала. [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, минуя стандартную схему.
Данная схема деплоя позволила минимизировать количество “пожаров”, возникающих в результате “горячих” обновлений функционала проектов, расширила зону комфорта программистов.
И завершим пост народной мудростью: пятничный релиз ведет к рабочим выходным.
Коваленко Алексей, можно и так сказать. Самое главное, что БД промежуточного сервера идентична боевому сайту. Это позволяет избежать ошибок, которые возникают из-за разных БД у разработчика на локальной машине и на самом сайте.
1) Что с лицензионным соглашением? Там говорится о 2 копиях. Просто договариваетесь с битриксом или вообще "без палева"? 2) У вас клиент напрямую с боем не работает? Контент-менеджеры контент не добавляют, никакх публичных данных от пользователей не возникает? Просто тогда надо ввести процедуру периодического переноса этих изменений с боя на гитхаб и тестовые площадки, а так же коммитить все изменения перед выкладыванием релиза из гитхаба. Мне кажется, это несколько усложняет жизнь.
Задойный Алексей написал: 1) Что с лицензионным соглашением? Там говорится о 2 копиях. Просто договариваетесь с битриксом или вообще "без палева"?
Проблем не возникало. По моему если для разработки удобно держать больше копий, то надо это делать.
Задойный Алексей написал: 2) У вас клиент напрямую с боем не работает? Контент-менеджеры контент не добавляют, никакх публичных данных от пользователей не возникает?
Почитайте внимательно статью все таки про синхронизацию БД.
Demo:clone - представляет собой копию боевой площадки и также работает на ветке master. БД прощадки Demo:clone раз в сутки автоматически синхронизируется с площадкой Product.
Максим Мул написал: Проблем не возникало. По моему если для разработки удобно держать больше копий, то надо это делать.
Вопрос был в следовании букве лицензионного соглашения. В вашем случае вы просто сделали это "без палева". Я не против. Но вообще это нарушение и если вы начнёте хаотично обновлять, то один тесто, то другой, то бой, то девелоперские тачки, то обновления заблокируют и надо будет объяснить ситуацию ТП. Те помогут и всё будет хорошо. Вопрос именно по формальной стороне был.
Максим Мул написал: Почитайте внимательно статью все таки про синхронизацию БД.
Ответа не вижу. Помимо БД есть ещё файлы. Страницы статические, документы, которые надо приложить к элемента ИБ или медиабиблиотеки или просто в папку по какой-то причине.
Я просто про сценарий: 00.00 - все со всеми синхронизовались, всё хорошо 9.00 - разработчик на тесте начал делать ФИЧУ 11.00 - Клиент на бою разместил файл отчёт.xls и создал старницу /about/otcheti/2014/index.php с обычным тестом и ссылкой на документ 12.00 - Вы хотите деплоить ФИЧУ на бой. Уже протестировав её везде. Но Демо площадка уже была рассинхронизирована с боем в 11.00. Т.е. прежде чем заливать релиз вам надо сделать на бое коммит руками. Нет? У вас такой сценарий фантастичен? Или есть некий регламент для его реализации?
Мы у себя четко делим зоны, в которых работает клиент и зоны программистов. То, что генерится клиентом в гит не коммитится и, соответственно, не перезатирается и никакой синхронизации не требует. На некоторых проектах мы даже настройки компонента в гит не складываем - логика работы в компонентах и шаблонах под нашим управлением, а настройки - клиента. А кое где вообще все через нашу ТП проходит - весь контент сами размещаем.
Т.е. конечно в идеале вы правы, так и должны быть и море лайков. Но что-то я таких сферических сайтов в вакууме не встречал, всегда есть риск получить ситуацию, когда клиенту потребовалось срочно создать форму. И он её создал. И страницу для неё.
Клoкoв Денис написал: Может и очевидно, но расскажите пожалуйста про синхронизацию баз данных
Все просто. Есть скрипт, который на кроне делает полный дамп БД Production и заливает его в БД Demo:clone. Для примера БД на 1,5Гб обновляется 5 минут. Также есть возможность вручную синхронизировать БД, если нужно.
Задойный Алексей написал: Вопрос был в следовании букве лицензионного соглашения. В вашем случае вы просто сделали это "без палева". Я не против. Но вообще это нарушение и если вы начнёте хаотично обновлять, то один тесто, то другой, то бой, то девелоперские тачки, то обновления заблокируют и надо будет объяснить ситуацию ТП. Те помогут и всё будет хорошо. Вопрос именно по формальной стороне был.
Алексей, теперь понятно о чем вы. Вообще эта схема у нас используется не только для проектов на Битрикс. Касаемо битрикса. Для него есть единый для всех файл .gitignore. Согласно его правилам ядро битрикса находится под игнором. Обновление обычно происходит на Production. После архивируется ядро и распространяется на другие площадки и разработчикам. Обновления на наших проектах обычно делаются не чаще 1 раза в 3 месяца, а то и реже. В итоге, проблем с блокировкой ключа не возникает.
Задойный Алексей написал: Ответа не вижу. Помимо БД есть ещё файлы. Страницы статические, документы, которые надо приложить к элемента ИБ или медиабиблиотеки или просто в папку по какой-то причине.
Релиз это такая вещь, которая бывает не очень часто. Клиент во время выкладки релиза ничего не делает. Если же делает, то всегда можно сделать инструмент, который будет ему на время закрывать возможность добавления контента. Перед релизом на Production делается проверка на внесение изменений в публичные файлы. Если такие есть, то они заносятся в ветку мастер и проверяются. Как правило там совсем мелочи, которые никак не связаны с кодом, и после это происходит выливание на бой кода самого релиза.
Еще хочу обратить внимание, что папка upload находится в игноре. Самое интересное там это картинки, за редким исключением. Вместо них выводятся заглушки на других площадках. Для особенных проверок папка upload сливается с Production целиком, либо с помощью специальных скриптов только нужные файлы.
Максим, как у вас всё хорошо!.. А у нас по 10 раз на дню надо срочно-срочно выложить функционал. И нет такого, что кто-то не работает над сайтом. Проект большой работа останавливается только по ночам.
Касательно .gitignore - это конечно технически всё хорошо и понятно. Но от нажатия кнопочки "обновить" и блокировки ключа вас не страхует )))) Плюс, формально это нарушает лиц соглашение. Но схема рабочая да. Более того, правильная! Надеюсь в будущем под неё лиц соглашение подкорректируют (сейчас в него укладывается только схема тест+бой)
Это достигается воспитанием заказчиков. Данная схема применяется на готовых для этого проектах. Не везде у нас так конечно, но мы к этому стремимся. Вообще это уже тема отдельного разговора.
Задойный Алексей написал: Надеюсь в будущем под неё лиц соглашение подкорректируют (сейчас в него укладывается только схема тест+бой)
Ну мы по этому поводу даже не задывались, но судя по вашим постам согласно лицензии над проектом должен работать один человек. Это конечно в корне неверно для серьезных проектов, где работает команда.
Максим, это вопрос построения процесса разработки.
Но если читать лиц соглашение, то там "русским по белому" написано, про 2. Довольно долго считал, что так и правильно и хорошо, но вот последние года 2 постепенно перевоспитываю себя в сторону систем контроль версий и-таки да, это ограничение (чисто формальное) смущает. Хотя я знаю, что всегда смогу договориться с партнёрским отделом.
Чебан Валерий, пока только два. Большая CRM-система на YII и большой интернет-магазин на Битрикс. Тут надо понимать, что эта схема подходит только для проектов определенного масштаба. Для обычных корпоративных сайтов она конечно избыточна.
Идея клевая, еще бы увидеть те скрипты для синхронизации БД. И как обстоит дело с изменением БД на стороне разработчика, ну надо ему добавить Инфоблок например, он добавил, завел пару элементов, а в это время контентщик заказчика на продакте заводит еще пару элементов с теми же ID что и у девелопера. Как быть в этом случае?
Диденко Денис написал: Инфоблок например, он добавил, завел пару элементов, а в это время контентщик заказчика на продакте заводит еще пару элементов с теми же ID что и у девелопера. Как быть в этом случае?
Пусть заводит. Как это может мешать работе проекта?
Диденко Денис, приведите пример, когда ID элементов используются в коде проекта?
БД у каждого разработчика своя. И если он сделал новость с ID = 10 и на production сделали новость с таким же ID, но с другим наполнением, то ничего страшного.
Максим Мул, могу привести и такие примеры, но не в этом суть, свойства, значения свойств типа список, инфоблоки которые могут создаваться и на прокашене и на бое, в общем пока вопросов больше чем ответов.
Максим Мул, на самом деле как таковой деплой вопросов не вызывает, есть git, есть mercurial, тут давно все изобретено, самая большая трудность в командной работе с битрикс это именно данные, на хабре была интересная статья по этому поводу, хочу прикрутить такую схему, но все руки не доходят http://habrahabr.ru/post/221979/
Диденко Денис, у нас сейчас в производстве находится модуль миграций. Пока обкатаем на своих проектах и выложим в пользование. Если интересно, то могу дать ссылку на github раньше, как будет готова beta.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».