Лучше всего придумать надежный процесс управления релизами.
Пусть ваши разработчики пишут сценарии выпуска и отката для каждого изменения, которое они вносят.
Настаивайте на сценариях SQL вместо изменений на основе графического интерфейса (используйте GUI для написания сценариев - в этом нет ничего плохого)
Таким образом, когда код завершен, у вас есть код, подготовленный для перехода от разработки к тесту, и затем используйте те же сценарии для перехода от теста к производству.
Делая это, вы можете
- Восстановление производственной базы данных в тестовой среде и тестирование выпуска и отката.
- Восстановите производственную базу данных в среде разработки и получите возможность вернуться туда, где вы были в своем жизненном цикле разработки. (Это иногда полезно, если вам нужно протестировать «свежие» данные)
Я склонен использовать следующую структуру папок
ChangeNo-xxxxx-Description
--> release.bat (sqlcmd script to loop through release folder)
--> rollback.bat (sqlcmd script to loop through rollback folder)
--> release (folder)
---->0001.ChangeDescription.sql
---->0002.ChangeDescription.sql
--> rollback (folder)
---->0001.ChangeDescription.sql
---->0002.ChangeDescription.sql
Кроме того, для быстрого тестирования процесса выпуска я стараюсь делать снимки базы данных. Протестируйте релиз. При необходимости вернитесь к снимку и попробуйте снова.
Самый простой способ синхронизировать ваши схемы между средами - это использовать Red-Gate SQL Compare или Embarcadero DB Change Manager, однако после синхронизации схемы вы будете иметь представление о том, почему вы внесли какое-либо изменение, или о методе отмены любого из перемены. сделал?
Оба являются отличными инструментами, однако, возможно, вы захотите установить контролируемый процесс изменений в вашей среде.
Отличный инструмент не может заменить управление изменениями и релизами.