Я работаю с другим разработчиком на сайте Drupal. Мы изо всех сил пытались найти хороший способ работать над разными частями сайта одновременно, не мешая друг другу. Мы пытались работать над одним и тем же экземпляром разработки сайта, но мы часто наступаем друг другу на ноги или сбиваем сайт с каким-то плохим кодом, не позволяющим другому продолжать работать до тех пор, пока он не будет решен. Итак, мы перешли к отдельным экземплярам разработки. Но сейчас очень сложно объединить нашу работу в единый экземпляр сайта. В основном мы в конечном итоге переделываем все в общую копию.
Самая большая проблема, с которой мы столкнулись сейчас, заключается в том, как объединить изменения базы данных и как включить базу данных в нашу систему контроля версий? Файлы просты, просто отслеживайте их все (мы используем git) и объединяем нашу работу, разрешая конфликты там, где это необходимо. Но это на самом деле не работает с базой данных. Мы можем взять дамп SQL и включить его в наш репозиторий git, но мы не можем объединить базы данных. Модуль Features немного помогает, позволяя нам экспортировать часть нашей работы с базой данных в код, который затем может быть версионирован и объединен. Тем не менее, даже близко не все поддерживает функции. Так...
Какие шаги мы можем предпринять, чтобы легко объединить изменения нашей базы данных?
Как мы должны сделать версию базы данных (хороший ли способ сделать файл дампа в git)?
Существуют ли какие-либо модули, помогающие решить некоторые из этих проблем?
Или мы застряли на одной и той же копии сайта? (пожалуйста, нет)
Изменить: В комментариях мы обсуждали, что вещи не могут быть экспортированы с функциями, и один из них был таксономии. Есть еще один вопрос, который касается этого .
Ответы:
Это изменение рабочего процесса, но вы должны привыкнуть работать над новым дампом живой базы данных. Есть три способа внести изменения в БД.
Если сможешь. Несколько раз в день получайте свежий дамп и тестируйте свою сборку, у вас должно быть меньше проблем с интеграцией.
источник
Я ответил на аналогичный вопрос и собираюсь немного его изменить, чтобы ответить на ваш вопрос здесь. Мое основное предложение заключается в том, что у вас есть сервер разработки / промежуточного размещения, на котором изменения кода проверяются с помощью системы непрерывной интеграции на частой основе (например, каждые 5 минут). Таким образом, на вашем локальном компьютере вы одновременно работаете только с одним запросом / сообщением об ошибке, четко отделяя эту задачу от других, над которыми могут работать люди, и сообщая своим товарищам по команде, что вы работаете над ними (redmine или отслеживание других ошибок отлично подходит для этого). Затем вы регулярно вносите изменения, и они переносятся на сервер dev / staging, как и ваши товарищи по команде. В идеале у вас есть модульные тесты, встроенные в вашу систему непрерывной интеграции (кстати, для этого настоятельно рекомендуем luntbuild или QuickBuild, но Hudson также работает). Система CI или тесты могут автоматически обнаруживать любые конфликты, которые вы могли ввести, как только вы регистрируете свой код. Если вам нужно внести изменения в содержимое (не в коде), это нужно сделать на сервере dev / staging.
Что касается части базы данных, я принял в основном две школы мысли (третью школу мысли, делающую различия в базе данных, я не буду обсуждать, потому что сложность довольно высока).
1) Разверните, удалив производственную базу данных и импортировав mysqldump из базы данных разработки. По желанию, запустите regex find / replace заранее для любых жестко закодированных абсолютных ссылок, которые ссылаются на URL-адрес dev в дампе SQL. После импорта базы данных dev в prod, автоматически запускайте операторы SQL (обычно через скрипт), чтобы изменить любые параметры, отличные для prod, чем dev (например, возможно, в таблице переменных есть некоторые параметры подключения для подключения к внешним системам, которые вам нужны изменить, чтобы указать на внешние системы prod вместо версии dev).
2) Используйте модуль Features, как упомянуто budda, для настроек администратора, и используйте модуль Node Export для экспорта / импорта контента в сочетании с модулем Delete All. Итак, рабочий процесс:
используйте node_export и функции для экспорта узлов / функций в файлы. Дополнительно (и, мы надеемся), контроль версий. Загрузка файлов в систему prod. Используйте интерфейс drush или admin для загрузки функций. Используйте интерфейс drush delete-all или admin, чтобы удалить все узлы типов, которые вы хотите импортировать. Используйте drush ne-import или интерфейс администратора для импорта узлов из файла узлов, который вы экспортировали. Одно замечание, я бы настоятельно рекомендовал принять стандартный рабочий процесс, в котором контент идет только в одном направлении. Либо Dev -> Prod, либо Prod -> Dev (я предпочитаю этот).
Я сделал это, и делаю это на некоторых больших системах, с довольно хорошими результатами, но всегда будет много способов нарезать это яблоко, выбрать тот, который подходит вам лучше всего.
источник
Хотя это старый вопрос с принятым ответом, я считаю, что еще есть место для другого.
Во-первых, позвольте мне сразу сказать, что я не считаю, что функции - это правильный инструмент для этой задачи, и предложу альтернативный набор инструментов.
Обязательным условием для совместной работы в команде является наличие промежуточного сервера для тестирования версий разработки проекта, отдельного от вашего рабочего сервера. Весь код разработки тестируется на промежуточном сервере и отправляется на рабочий сервер только тогда, когда он стабилен и готов к развертыванию. Однако разработчики не работают напрямую с промежуточным сервером. Каждый разработчик работает на своей рабочей станции, используя систему контроля версий и управления исходным кодом (SCM), чтобы координировать свою работу с остальной частью команды.
Система SCM позволяет членам группы работать параллельно над разными ветвями кода, не мешая друг другу. Только мастер филиал развернут на промежуточном сервере для целей тестирования.
Для зеркального отображения базы данных между рабочей, промежуточной и рабочей станциями существует модуль с именем « Резервное копирование и миграция», который можно использовать, если вы используете общий хостинг и не управляете собственной базой данных. Если вы управляете своим собственным сервером базы данных, это единственный проект на этом сервере, и вы используете mysql , подойдет следующая пара команд:
Выгрузить:
Для восстановления:
Если ваша база данных не единственная на этом сервере, запишите какую-нибудь версию
mysqldump(или эквивалентную, если вы не используете mysql ), которая создает дамп только ваших баз данных.Создайте политику, что это база данных на рабочем сервере, которая является главной. Промежуточный сервер и рабочие станции должны быть копией производственной базы данных, а не наоборот.
Обратите внимание, что Drupal 7 сохраняет все настройки администратора в базе данных. Это означает, что при зеркалировании базы данных между рабочим сайтом, промежуточным сайтом и рабочими станциями параметры миграции будут перенесены без компонентов .
Теперь, чтобы поделиться кодом:
Стандартный способ обмена кодом между членами команды разработчиков - использование системы SCM. Drupal по умолчанию управляется с помощью такой системы, которая называется git .
Git позволяет использовать локальные или удаленные репозитории. Если члены команды находятся в одном физическом пространстве, вы можете настроить локальный репозиторий на своем промежуточном сервере. Если они распространены географически, вы можете настроить удаленное хранилище. Если вы не против того, чтобы другие имели доступ для чтения к вашему разрабатываемому коду, вы можете использовать песочницу на Drupal.org в качестве удаленного хранилища. Вы также можете использовать область проекта на GitHub . GitHub - это не только репозиторий, он поставляется с некоторыми инструментами для совместной работы и позволяет использовать как публичные, так и частные репозитории.
По сути, система SCM позволяет членам группы извлекать исходный код и документацию из репозитория, доступного для членов группы, и возвращать его обратно после работы над ним. SCM отслеживает изменения и, если возникает конфликт (т. Е. Кто-то пытается выдвинуть код, который не содержит изменений, внесенных другим членом команды), он сообщит вам и также предложит способ разрешения этого конфликта.
Как правило, при некотором сердечном общении о том, как задачи распределяются между членами команды, не возникает никаких конфликтов. Но с помощью системы SCM, отслеживающей ситуацию, конфликты становятся управляемыми, даже если допущены ошибки или сбой связи.
Существует множество руководств по началу работы с git (GIYF) и их использованию . Два, которые я рекомендую: сайт git-scm и Pro Git от Scott Chacon.
источник