13 апреля 2011 в 16:30
Есть вопрос.
В процессе командной работы над проектом возникла проблема. До момента запуска пре-продакшн сервера вся разработка велась вместе на одном сервере. Плохо, ибо косяк одного девелопера для всех становится глюку подобен, и до момента исправления делает работу всей команды зело трудной и не удобной ,а иногда и вообще все стопорит.
Потому как косячить на пре-продакшн сервере нельзя, и там должна хранится работающая версия сайта, решено создать для каждого девелопера локальные сервера разработки, на которые каждый сливает себе копию с пре-продакшн и работает с ней. Однако как корректно все залить назад на пре-продакшн после внесения изменений?
С файловой частью все более-менее понятно. На то есть системы контроля версий.
Как быть с базой данных? Каким методом делать корректное слияние баз данных с локальных серверов разработки и БД продакшн сервера?
Нагуглилось:
- Migraine от Shearer Software (судя по описанию, ориентирован на Д5, допилен под Д6, а про совместимость с Д7 вообще ничего не нагуглилось)
- Drupal Features (краем уха слышал, никогда не работал)
Как вариант на ум приходит еще отбор таблиц для дампа в ручном режиме через PhpMyAdmin или Sypex Dumper, с последующим импортом на продакшн. Гиморно и большая вероятность накосячить.
Какие еще варианты есть?
Комментарии
не встречал контроль версии мускула.
поделитесь решением
Как правило проблема с автоинкрементом связана.
Чтобы её решить можно выделить для разработчиков диапазон id для создания нод в процессе разработки, а на продакшн выставлять вручную автоинкремент для нужных таблиц в опред. значение. Это позволит не пересекаться контенту, таксономии и прочему.
Можно использовать экспорт в код всего, что только можно (Views, CCK, Features, Strongarm & etc.)
Про контроль версий - я писал о "файловой" части проекта, то есть о модулях, темах и т.п. Тут все достаточно прозрачно, систем контроля версий достаточно: GIT, SVN, CVS Для мускула пока системы контроля версий на прямую не нашел.
Пока копаю в сторону Migraine от Shearer Software. На данный момент занимаюсь конфигурированием этой штуковины под D7, потому как с готовым конфигом оно нагугливается только под D5 и D6. По мере появления результатов буду отписывать в этот топик.
2 VladSavitsky: Спасибо за идею.
Получилось настроить migraine для drupal 7? Очень был бы признателен если выложите. Да и не только я один думаю.
Или может по другому решили проблему синхронизации БД? Поделитесь решением, очень интересно.
Настройка конфигурации Migraine для Drupal 7 отличается только несколько другой структурой стандартных таблиц. Сейчас при себе базового файла конфигурации нет, завтра постараюсь поискать.
Еще в тему - под руку попадал утиль под названием MySQL Compare (если память не изменяет). Удобная программа, правда платная, поэтому дальше срока триального использования дело не пошло. Но вещь удобная. Также завтра посмотрю, как именно оно называется.
Неужели ошибка одного девелопера так серьезно стопорит работу всех?
У нас в команде 3 человека.Используем 1 девелоперский сервер,1 бета и 1 боевой.
пишем свои модули-кидаем на девелоперский.если всё ок-кидаем на бету-там тестеры тестят.если всё ок-копируем с беты на боевой.
ну и у каждого сайта своя БД конечно.
Вполне удобно.файлы коммитим меркурием.
вначале тоже хотели каждому девелоперу свой сервер,но отказались от этого.ведь критичную ошибку(например не закрыли кавычку) можно пофиксить быстро,и сайт дальше работает.