Как вы версии / отслеживать изменения в таблицах SQL?

Работая в команде разработчиков, где все вносят изменения в локальные таблицы и таблицы разработки, как вы синхронизируете все изменения? Центральный файл журнала, где все хранят свои sql изменения? Вики-страница для отслеживания операторов таблицы изменений, отдельных файлов .sql, которые могут запускать разработчики, чтобы привести свои локальные базы данных к последней версии? Я использовал некоторые из этих решений, и я изо всех сил стараюсь получить хорошее и надежное решение, которое работает, поэтому я буду признателен за ваши идеи.

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

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

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

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

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

Создание сценариев под управлением версиями и непрерывной интеграции для проверки их

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

Ночная непрерывная сборка интеграции взяла последнюю версию всех сценариев и попыталась создать из них связную тестовую базу данных. Затем приложение провело серию интеграционных и функциональных тестов, чтобы проверить, соответствует ли текущая схема текущему кандидату на выпуск.

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

Здесь очень помог контроль версий, потому что изменения в скриптах были сразу очевидны. Мы также использовали VERSIONтаблицу базы данных для определения общего состояния базы данных. Это была простая целочисленная последовательность и не была связана с каким-либо конкретным приложением.

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

Если вы находитесь в магазине MS, Visual Studio 2010 имеет несколько хороших инструментов контроля версий баз данных, которые также могут генерировать сценарии изменения / развертывания на основе различий между двумя базами данных.

Наряду с сохранением схем и других сценариев SQL под контролем версий, другой удобной практикой является поддержание таблицы «версии схемы» в фактической БД .

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

В Doctrine есть отличный инструмент для миграции: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations , лучшая часть в том, что они генерируются автоматически или могут быть легко закодированы вручную.

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

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

Кстати, весь этот подход был автоматизирован как часть Ruby on Rails вместе со сценариями отката. Мне нравится идея этого, но не все рамки делают это. Когда я не использую Ruby on Rails, я использую подход, описанный выше.