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

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

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

Ответ 1

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

Я верю Rails сделал это сначала.

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

И здесь . NET-библиотека миграции.

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Удачи!