Widziałem nie-wiem-jak-wiele sposobów, które próbowały sobie z tym poradzić, i w końcu myślę, że musisz po prostu dbać o ręczne skrypty.
Teraz niekoniecznie musisz sam pisać. W MSSQL, gdy wprowadzasz zmianę, jest mały przycisk do Generuj skrypt, który wypluwa skrypt SQL dla wprowadzanej zmiany. Wiem, że mówisz o Oracle i minęło kilka lat, odkąd pracowałem z ich GUI, ale mogę sobie tylko wyobrazić, że mają tę samą funkcję.
Nie można jednak uciec od ręcznej pracy ze skryptami. Będziesz mieć wiele problemów związanych z wcześniej istniejącymi danymi, takimi jak wartości domyślne dla nowych kolumn lub sposób obsługi danych dla zmienionej/usuniętej/przeniesionej kolumny. To tylko część analizy pracy ze schematem bazy danych w czasie, od której nie można uciec. Jeśli spróbujesz to zrobić za pomocą całkowicie zautomatyzowanego rozwiązania, Twoje dane prędzej czy później zostaną pomieszane.
Jedyną rzeczą, którą polecam, aby trochę ułatwić Ci życie, jest upewnienie się, że oddzielisz zmiany schematu od zmian kodu. Różnica polega na tym, że zmiany schematu w tabelach i kolumnach muszą być uruchamiane dokładnie raz i nigdy więcej, a zatem muszą być wersjonowane jako pojedyncze skrypty zmian. Jednak zmiany w kodzie, takie jak przechowywane procedury, funkcje, a nawet widoki, mogą (i powinny) być uruchamiane w kółko i mogą być wersjonowane tak jak każdy inny plik kodu. Najlepszym podejściem, jakie widziałem, było to, że mieliśmy wszystkie procs/funkcje/widoki w VSS, a nasz proces budowania porzucał wszystkie i odtwarzał je podczas każdej aktualizacji. To ten sam pomysł, co przebudowanie kodu C#/Java/cokolwiek, ponieważ zapewnia, że wszystko jest zawsze aktualne.
