Управление версиями базы данных - как работает переключение веток?

Question

Это вопрос для тех из вас, кто работает в команде разработчиков, где у всех вас есть отдельные базы данных. Вы управляете версией своей базы данных, используя систему контроля версий и другие инструменты, которые автоматически обновляют базы данных dev до последней версии базы данных (схема, данные, SP, функции и т. Д.).

ОК Отлично! Но ждать! Что если вы разрабатываете версию программного обеспечения 4.0, но теперь вам нужно переключить ветки на ветку 3.2, чтобы исправить ошибку? Схема может быть (почти наверняка) совсем другой ...

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

Answer 1

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

Answer 2

Я собираюсь взять конечность и предположить, что вы управляете базой данных как двоичным файлом?Если бы все ваши ресурсы базы данных были в форме конструктивного кода (например, сценарии SQL и / или дампы текстовых данных), решение было бы простым, как предложил Марк: хранить эти активы как часть ветви разработки.Чтобы работать с версией 3.2, переключите ветку, перезапустите базу данных create scripts и presto, 3.2.Объединение будет таким же простым, как и с обычным кодом (или столь же болезненным, в зависимости от выбранной вами системы управления версиями).

Вот несколько советов для работы в этом режиме:

• Если создание экземпляров базы данных из текста выполняется слишком медленно, создайте кэш на томе общего диска, на который указывает содержимое всех файлов схемы / данных (или их сумма в MD5).
• Записать предварительнохук commit, чтобы убедиться, что схема и дампы данных в экземпляре разработчика совпадают с теми, что находятся под управлением версиями.Это не позволяет людям вносить изменения в свою базу данных разработчиков с помощью интерактивного инструмента, а затем забывает зафиксировать их.
• Вы упоминаете сценарии изменений;относиться к ним как к ответственности.Хотя они могут потребоваться в вашем сценарии развертывания (например, для клиентов, которые хотят выполнить обновление на месте), они дублируют информацию из истории версий базы данных, и согласно закону Мерфи дублирование рано или поздно означает десинхронизацию.Попробуйте автоматически сгенерировать сценарии изменений из версионных ресурсов базы данных, используя «diff»;или, если это невозможно, посвятите несколько серьезных юнит-тестов обновлению базы данных.