Последние два месяца я искал решения или практики для управления выпусками в базах данных. Я ищу то, что люди считают лучшим процессом для этого.
У нас есть 3 среды для наших баз данных:
- развитие
- Пользовательское приемочное тестирование (UAT)
- производство
Иногда проблема заключается в том, что мы вносим изменения в некоторые вещи в нашей базе данных разработки, и приходит время для развертывания, некоторые функции могут быть не готовы к выпуску в UAT.
Недавно мы начали использовать элемент управления Red Gate SQL Source для хранения всех наших объектов (с регулярными коммитами).
Я думал о том, чтобы перейти на основе наборов изменений (то есть сказать, что все, начиная с набора изменений X и обратно, теперь передается в UAT), однако это означает, что люди проверяют свой код только в контроле исходного кода непосредственно перед тем, как мы выполняем развертывание, которое может запутаться ( тем более что люди забывчивы). Другая проблема, связанная с подходом к изменению, заключается в том, что если в хранимой процедуре есть ошибка, которую необходимо исправить, номер набора изменений в конечном итоге будет выходить за рамки нашего максимального набора изменений для ревизии, поэтому сделаем так, чтобы при необходимости воссоздать базу данных с максимальным набором изменений, мы бы снова выдвинули ошибку.
Есть предложения по процессу?
Спасибо
источник
Ответы:
Миграции
Вверх и вниз, которые находятся в вашем репо и помечены вместе с вашим приложением.
Вы даже можете сделать DIY с помощью sql flatfiles, которые изменяют вашу схему и обновляют версию схемы. Все, что вам действительно нужно сделать, это:
Что ж, вы можете вносить изменения в разработку в dev, но вы всегда должны сдавать свою базу данных и перестраивать ее с помощью миграций, как только вы поймете это изменение.
источник
Управления источником!
Вы не развернете свои двоичные файлы разработки непосредственно в производство, не перейдя через svn / git / p4, так почему бы ваши базы данных сделали это? Получите частные экземпляры для разработчиков, чтобы проверить их локальные изменения, но когда он должен перейти в базу данных разработки, он должен пройти через проверенные в файлах ddl. Вы даже можете написать инструменты для автоматического применения этих изменений ddl (я не знаю ни одного существующего способа сделать это правильно).
Как только у вас появятся ограничения на изменение схемы БД (больше нет sqlplus -> Issue ddl!) И вы получите строгий контроль учетных записей (нет доступа к ddl для всех), это должно стать более управляемым.
источник
Следуя предложению об использовании миграций ... возможно, используйте O / RM, который поддерживает миграции, такие как Ruby on Rails и Entity Framework 4.3. Однако проблема обоих подходов заключается в том, что миграция - это все или ничего. Вы не можете (обычно) выбирать, какие Миграции применяются, как вы можете с точки зрения наборов изменений.
Другой жизнеспособный вариант (если вы в стеке Microsoft, вы никогда не упоминали платформу) - это управлять своим SQL с помощью инструментов базы данных Visual Studio. Он имеет встроенный рефакторинг (переименование / удаление столбцов и т. Д.) И выполняет проверку модели. Например, если хранимый процесс ссылается на столбец, которого больше нет, он сообщит вам об этом.
источник