Как вы управляете ревизиями базы данных в проекте среднего размера с филиалами?

Question

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

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

Answer 1

Если ваша база данных хорошо соотносится с набором объектов доступа к данным, рассмотрите возможность использования "миграции".Идея состоит в том, чтобы сохранить вашу модель данных в виде кода приложения с шагами для продвижения вперед и назад по каждой версии базы данных.

Я верю Рейлс сделал это первым.

Java имеет по крайней мере, один проект.

И вот такой Библиотека миграции .NET.

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

Возможно, другие могут предложить другие библиотеки миграции.

Ваше здоровье.

Редактировать:Смотрите также https://stackoverflow.com/questions/313/net-migrations-engine и Обзор инструмента миграции базы данных .NET (из поста выше).

Answer 2

http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx

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

Мы управляем только изменениями схемы, но вы также можете / захотеть рассмотреть возможность сохранения дампов ваших данных доступными и в системе управления версиями;создание таких файлов - довольно тривиальное упражнение с использованием mysqldump.

Наше решение отличается от решения, представленного в блоге, одним ключевым моментом:это не автоматизировано.Мы должны вручную применять обновления базы данных и т.д.Хотя это может занять немного времени, это отложило часть усилий, которые потребовались бы для создания полностью автоматизированной системы.Однако одна вещь, которую мы автоматизировали, - это отслеживание версии базы данных в программном обеспечении:это было довольно просто, и это гарантирует, что наше программное обеспечение знает о базе данных, с которой оно работает, и будет работать ТОЛЬКО в том случае, если оно знает схему, с которой работает.

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

Answer 3

Мы храним все наши скрипты базы данных (data и schema / ddl) в системе управления версиями.Мы также ведем центральный каталог изменений.Когда разработчик вносит изменения в файл схемы / DDL или добавляет скрипт, который каким-либо образом изменяет данные, эти файлы добавляются в каталог вместе с номером фиксации SVN.

Мы создали небольшую собственную утилиту, которая считывает изменения в каталоге и создает большой сценарий обновления на основе содержимого каталога, извлекая содержимое из каждой редакции каталога и применяя их.Концепция очень похожа на Развертывание DBDeploy инструмент, который, как я полагаю, изначально был создан Мыслительные работы, так что, возможно, вы сможете его использовать.Это, по крайней мере, даст вам хорошую отправную точку, с которой вы сможете настроить решение, более соответствующее вашим потребностям.

Желаю удачи!