Доброго времени чтения, коллеги. Такая проблема возникла. Есть крупный магазин на битриксе. Необходимо работать над ним 3 параллельным программистам. Как это сделать? Для файлов - git. Но как быть с базой? Ее необходимо как-то синхронизировать между разрабами... Сначала подумал сделать внутренний сервачок. Был у нас в подсопке лишний комп (4 ядра. 2 гига памяти. 100гб хдд). Поднял на нем убунту сервер 12.10. мускуль. Девелоперы настроили свои локальные версии битрикса на этот сервачок. И хоть внутреняя сеть и 100 мбпс (вайфай роутер, подключено 4 компа по эзернету, по вайфаю только мобайл девайсы). Битрикс очень долго думает. Включил отладку - 700 запросов на странице. (сказать прихуел ничего не сказать, ибо стоит все стандартное, не кастомизированные компоненты). Переключились обратно на локальные версии. Теперь не знаю как сделать синхронизацию бд. бывает что то типа гита для мускуля? )))) миграции не причем, ибо вопрос связан с данными, а не только со структурой Сервер продакшна находится в амстердаме (digital ocean)
чтобы разрабы локтями не толкались на одной тяжелой базе, пусть у каждого будет свой игровой сервер. копирование с рабочей базы на сервер разработчика, mysqldump + gzip + ssh. viewtopic.php?f=22&t=46069&p=366995#p366995 для битрикса возможно надо составить список таблиц-исключений. это тебе виднее.
на работе только я убунтой пользуюсь =( так бы повесил эти бекапы и развертывание бд. но опять же. надо сливать бд разработчиков с тестовым сервером, а потом и с продакшном.
Еще раз повторюсь, посмотри в сторону отключенного extended-insert. Суть, mysqldump поумолчанию выгружает с оптимизированным кол-вом инсертов. (что для git - плохо) Отключив extended-insert он будет вываливать по 1 инсерту на строку, а это подводит мысль к тому, что гиту будет проще строить дифы. Соответственно кажный разработчик будет видеть разницу, между того что в апстриме и у него. Блин, а тут есть над чем самому задуматься )
если один кодер меняет структуру БД, то надо писать миграцию в рамках того коммита, который работает с изменённой структурой... другие кодеры видят, что прилетела миграцию и накатывают её, также её можно откатить "еслив что пошло не так"
миграция работает только со структурой бд. в битриксе ничего не меняется в структуре. только данные Добавлено спустя 28 секунд: спасибо большое. но мы уже давно с миграциями сотрудничаем.
блин, только сейчас дошло imho, сама мысль неправильная. в отличие от кода, данные с dev на prod не должны попадать ни при каких раскладах!!! со структурой всё понятно, ты говоришь что миграции есть. так что, помоему, нужна не синхронизация, а только односторонее копирование по требованию.
да мы сидим втроем (два программера и верстальщик). в принципе всегда вкурсе что куда, но в битриксе даже не заметишь как поставишь галочку и все )
Была точно такая же задача. Пытались, пытались и недопытались, оставили общую базу. Один из членов команды пытался настроить репликацию mysql, но его инициатива загнулась по причине командной лени. Добавлено спустя 1 минуту 40 секунд: Забыл: Битрикс гавно.
у каждого разработчика своя копия проекта, также продакшен, тестовые и т.д. копии. делаем небольшие файлы с миграциями бд и накатываем их на каждой копии (можно автоматизировать). Правда код миграции пишется вручную, но тут спасают различные классы хелперы. В итоге нет никакой перезаливки бд, изменения хранятся в файлах под контролем версий. https://bitbucket.org/andrey_ryabin/sprint.migration