После пары “горячих” обновлений боевого сайта, в результате которых проект не работает несколько часов и заказчик обрывает телефон, попутно теряя прибыль, разработчики начинают задумываться о том, как сберечь свои нервы и отношения с заказчиком.
Мы тоже прошли через эти грабли и выработали для себя схему работы, которую теперь применяем на наших проектах. Схема подходит для любых проектов, которые уже размещены в сети и требуют постоянных (итерационных) обновлений функционала. [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 целиком, либо с помощью специальных скриптов только нужные файлы.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».