Сотрудничество на сайтах с реляционными базами данных и CMS

Какие процессы вы выполняете при совместной работе в небольшой команде на сайтах с базами данных?

У нас нет проблем с работой над файлами сайта, так как они находятся под контролем версий, поэтому любое число наших разработчиков может работать из любого места в этом аспекте веб-сайта.

Но, когда изменения базы данных должны быть сделаны (либо непосредственно как часть разработки, либо неявно, путем внесения изменений контента в CMS), очевидно, что различным разработчикам сложно слить эти изменения в базе данных.

Наши подходы до сих пор были ограничены следующим:

Помещение замораживания содержимого на веб-сайте производства и создание всех разработчиков в той же копии производственной базы данных
Делегирование задач, которые будут связаны с изменениями базы данных с одним разработчиком, а затем попросить других разработчиков импортировать копию этой базы данных после внесения изменений; в то время как другие разработчики работают только на файлах сайта под контролем версий
Предоставление разработчикам изменений в собственной копии базы данных ради собственной разработки, но затем вручную внесение этих изменений во все другие копии базы данных (например, предоставление другим разработчикам импорта SQL script, относящегося к изменения в базе данных, которые они сделали)

Мне было бы интересно узнать, есть ли у вас лучшие предложения.

Мы работаем в основном с базами данных MySQL и в настоящее время не отслеживаем изменения этих баз данных. Проблемы, описанные выше, относятся главным образом к сайтам Drupal и Wordpress, где значительная часть "разработки" выполняется в сочетании с изменениями, внесенными в базу данных в CMS.

Ответ 1

Где я работаю, каждый разработчик (фактически, каждая виртуальная машина разработки) имеет свою собственную базу данных (точнее, свою собственную схему на общем экземпляре Oracle). Наш рабочий процесс основан на полных перестроениях. У нас нет возможности модифицировать существующую базу данных - у нас только есть ядерная возможность сдуть всю схему и построить с нуля.

У нас есть немного "drop all" script, который использует запросы в системных таблицах, чтобы идентифицировать каждый объект в схеме, создает кучу SQL, чтобы удалить их и запускает. Затем у нас есть стек файлов DDL, полный операторов CREATE TABLE, тогда у нас есть стек XML файлов, содержащих исходные данные для системы, которые загружаются инструментом загрузки. Все это проверяется на исходный контроль. Когда разработчик выполняет обновление из исходного элемента управления, если они видят входящие изменения базы данных (DDL или данные), они запускают мастер-сборку script, которая запускает их для создания новой базы данных с нуля.

Хорошо, что это делает жизнь простой. Нам не нужно беспокоиться о различиях, дельтах, ALTER TABLE, обратимости и т.д., Просто просто DDL и данных. Нам не нужно беспокоиться о сохранении состояния базы данных или ее чистке - вы можете вернуться в чистое состояние одним нажатием кнопки. Еще одна важная особенность этого заключается в том, что тривиально настраивать новую платформу, а это значит, что, когда мы добавляем больше машин для разработки или нужно создать систему принятия или что-то еще, это легко. Я видел проекты сбой, потому что они не могли создавать новые экземпляры из своих запутанных баз данных.

Самое главное, что в нашем случае требуется некоторое время - из-за особых удручающих деталей нашей системы - долгое время, но я думаю, что команда, которая действительно была на вершине своих инструментов, могла бы сделать полную перестройте это через 10 минут. Полчаса, если у вас много данных. Достаточно короткий, чтобы иметь возможность делать несколько раз в течение рабочего дня, не убивая себя.

Проблема в том, что вы делаете с данными. Есть две стороны: данные, генерируемые во время разработки, и живые данные.

Данные, созданные во время разработки, на самом деле довольно просты. Люди, которые не работают, по-видимому, имеют привычку создавать эти данные непосредственно в базе данных и поэтому видят проблему в том, что они будут потеряны при восстановлении. Решение прост: вы не создаете данные в базе данных, вы создаете его в сценариях загрузчика (в нашем случае XML, но вы можете использовать SQL DML или CSV с инструментом импорта базы данных или что-то еще). Подумайте о сценариях загрузчика как исходном коде, а база данных - как объектный код: сценарии являются окончательной формой и являются тем, что вы редактируете вручную; база данных - это то, что сделано из них.

Живые данные более жесткие. Моя компания не разработала ни одного процесса, который работает во всех случаях - я не знаю, если мы еще не нашли волшебную пулю, или если ее нет. Один из наших проектов - это подход, который отличается от развития, и что нет полных перестроек; скорее, они разработали набор методов для определения дельт при создании нового выпуска и их применения вручную. Они выпускаются каждые несколько недель, так что это всего лишь пара дней работы для пары людей, которые часто. Не много.

Проект, над которым я сейчас, еще не стал жить, но он заменяет существующую живую систему, поэтому у нас есть аналогичная проблема. Наш подход основан на миграции: вместо того, чтобы пытаться использовать существующую базу данных, мы переносим все данные из нее в нашу систему. Мы написали довольно растягивающий инструмент для этого, который запускает запросы к существующей базе данных (ее копию, а не живую версию!), А затем записывает данные как скрипты загрузчика. Затем они поступают в процесс сборки так же, как и другие. Миграция написана сценарием и работает каждую ночь в рамках нашей ежедневной сборки. В этом случае усилия, необходимые для написания этого инструмента, были необходимы в любом случае, потому что наша база данных отличается от старой по своей структуре; способность выполнять повторяющиеся миграции нажатием кнопки была бесплатной.

Когда мы будем жить, одним из наших вариантов будет адаптация этого процесса для перехода от старых версий нашей базы данных к новым. Нам нужно будет писать совершенно новые запросы, но они должны быть очень легкими, потому что исходная база данных является нашей собственной, и сопоставление от нее к сценариям загрузчика, как вы могли себе представить, просто, даже если новая версия система отходит от живой версии. Это позволило бы нам продолжать работу над полной перестроенной парадигмой - нам все равно не придется беспокоиться об ALTER TABLE или чистить наши базы данных, даже когда мы проводим техническое обслуживание. Я понятия не имею, что команда операций будет думать об этой идее, хотя!

Ответ 2

Вы помещаете все изменения базы данных в сценарии SQL. Поместите какой-то порядковый номер в имя файла для каждого script, чтобы вы знали, в каком порядке они должны быть выполнены. Затем проверьте эти сценарии в своей системе управления версиями. Теперь у вас есть воспроизводимые шаги, которые вы можете применить к тестовым и производственным базам данных.

Ответ 3

В то время как вы можете поместить весь свой DDL в VC, это может стать очень грязным очень быстро, если вы попытаетесь управлять множеством и операторами ALTER.

Принуждение всех разработчиков к использованию одной и той же исходной базы данных также не является очень эффективным.

Решением, которое я использовал, было поддержание файла для каждого объекта базы данных, определяющего, как создать объект (в первую очередь, чтобы изменения могли просматриваться с помощью утилиты diff), а затем вручную создавая инструкции ALTER, сравнивая версию выпуска с текущей версией - Да, это довольно трудоемкий процесс, но единственный способ решить проблему.

У меня был план автоматизации генерации операторов ALTER - он должен быть относительно простым - действительно, быстрый google нашел эту статью и этот. Никогда не оборачивался сам по себе, так как усилия по этому вопросу были намного больше, чем частота изменений схемы в проектах, над которыми я работал.

Ответ 4

Вы можете использовать модуль репликации ядра базы данных, если он есть.
Один сервер будет мастером, изменения должны быть сделаны на нем.
Копии разработчиков будут рабами.
Любые изменения на главном будут дублированы на ведомых устройствах.
Это односторонняя репликация.

Может быть немного сложно установить, поскольку любые изменения на ведомых устройства будут удалены.

Также это означает, что разработчики должны иметь две копии базы данных.
Один из них будет подчиненным, а другой - базой данных разработки.

Существуют также инструменты для перекрестных повторений баз данных. Таким образом, все копии могут быть мастером.

Оба решения могут привести к бедствиям (ошибки репликации).

Единственное решение, похоже, подходит для того, чтобы иметь только одну базу данных для всех разработчиков и сохранять ее несколько раз в день во вращающейся истории.
Не избавит вас от конфликтов, но вы сможете восстановить предыдущую версию, если это произойдет (и это всегда происходит...).

Ответ 5

Где я работаю, мы используем Dotnetnuke, и это создает те же проблемы. т.е. после того, как на выпуске сайта появились данные, поступающие в базу данных, а также файлы, добавляемые в файловую систему некоторыми модулями и файловой системой DNN.

Мы обновляем файловую систему сайта с помощью svn, которая по большей части работает нормально. Однако база данных - это другое дело. Лучшим методом, с которым мы сталкивались до сих пор, является использование инструментов RedGate для синхронизации промежуточной базы данных с производственной базой данных. Инструменты RedGate очень хороши и хорошо стоят денег.

В основном мы все разрабатываем локально с локальной копией базы данных и сайта. Если изменения являются основными, мы разветвляемся. Затем мы фиксируем локально и выполняем слияние RedGate, чтобы поместить наши изменения в базу данных на общем сервере dev.

Мы используем общий сервер dev, чтобы другие могли выполнять тестирование. После завершения мы затем обновляем сайт на этапе svn, а затем объединяем изменения базы данных с сервера разработки на промежуточный сервер.

Затем, чтобы идти в прямом эфире, мы делаем то же самое с постановки на prod.

Этот метод работает, но подвержен ошибкам и очень трудоемкий, когда необходимо внести небольшие изменения. База данных prod всегда резервируется, поэтому мы можем легко откатиться, если доставка идет не так.

Одна из основных головных болей у нас заключается в том, что Dotnetnuke использует идентификационные cols во многих таблицах, и если у вас есть данные, идущие в таблицы для разработки и производства, такие как вкладки и разрешения и экземпляры модулей, у вас есть кошмар, синхронизирующий их. В идеале вы хотите найти или построить cms, который использует графический интерфейс или что-то еще в базе данных, чтобы вы могли легко синхронизировать таблицы, которые используются одновременно.

Мы хотели бы найти лучший метод! Поскольку у нас много проблем с ветвлением и слиянием, когда проекты параллельны.

Гас