В вашей базе данных будет 3 вида вещей, о которых вам нужно беспокоиться.
1) Схема, которую можно определить в DDL.2) Статические данные или данные поиска, которые могут быть определены в DML.3) Динамические (или пользовательские) данные, которые также могут быть определены в DML.
Обычно изменения в (1) и (2) должны просто перейти к производству с кодом, на который они взаимно зависят.(3) никогда не должно идти вверх, но может быть скопировано в среды разработки, если они в то время синхронизированы с производственными средами.
Конечно, это намного сложнее, чем это.Чтобы получить (1), может потребоваться преобразование существующей схемы / DDL в конкретные операторы alter, а также может потребоваться манипулирование данными, если типы данных или местоположения меняются.Для получения (2) требуется синхронизация со сборкой кода, которая может стать сложной в сложных средах.
Существует множество инструментов, и если вам требуется автоматизация, вам, возможно, понадобится совет от кого-то, кто знаком с ними.*
Я использую очень простую схему, где все изменения схемы отражаются в сценарии сборки SQL, а также добавляются в сценарий изменения SQL, который включает в себя весь SQL, необходимый для выполнения любых необходимых преобразований.Это хорошо работает для меня, но мой сценарий очень прост (1 человек, 1 сервер) и поэтому нетипичен.
Однако ключом к любому успеху является определение работы, необходимой для внесения изменений в момент внесения изменений.,Наивным методом простого изменения БД разработки и последующего исправления во время развертывания является катастрофа.