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

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Удачи!

Answer 3

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

Я думаю, Rails сделал это первым .

Java имеет хотя бы один проект .

А вот и миграционная библиотека .NET .

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

Может быть, другие могут предложить другие библиотеки миграции.

Приветствие.

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