Управление версиями объектов базы данных (не схема)

Question

Я пытаюсь выяснить, как реализовать контроль версий в среде, где у нас есть две базы данных: один Тестирование и один Производство.

Тестирование. существует произвольное количество проверяемых задач. У них нет ограничений в количестве манипулируемых объектов и сложности, то есть у нас может быть трехдневная задача, которая изменяет 2 пакета bodys и один триггер, и у нас может быть задача на 3 месяца, которая изменяет 100 разных объектов, включая исходные файлы S и двоичные объекты.

Моей главной задачей являются текстовые объекты БД. Нам нужно версия Test и Производства кода, но любая задача может идти от тестирования в производство без какого-либо определенного порядка вообще.

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

Я изо всех сил, чтобы реализовать SVN, потому что я хотел создать Testing как филиал производства, имеющих филиалы в Testing ограничить каждую задачу, но я считаю, что это может привести ко многим тестирования задачи переносятся на Производство во время слияния.

Это говорит, что мои вопросы:

• Есть ли способ решить эту проблему автоматически?
• Существуют ли какие-либо решения для управления версиями базы данных?
• Как я могу «связать» обе среды, если база кода настолько отличается?

Answer 1

Я использовал SVN для управления версиями по сценариям БД.

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

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

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