Nigdy nie spotkałem się z robieniem delty strukturalnej w bazie i aplikowaniu jej na produkcyjnym systemie (gdzie pojawia się również delta w danych...)
In-housowo mamy narzędzie, które:
a) wymaga utworzenia instancji repozytorium narzędzia (schemat bazodanowy)
b) wszystkie skrypty bazodanowe aplikowane są przez to narzędzie (w szczególności może zarządzać zmianami dla różnych systemów, różnych baz danych)
c) zmiany zorganizowane są w projekty: "instalacja od 0", "upgrade", "migracja między wersjami" , "mój wypasiony projekt"
d) W "upgrade" zmiany zorganizowane są na zasadzie paczek dla funkcjonalności bądź błędów (każdy plik z deskryptorem zmiany ma przyjętą konwencję nazewniczą: YYYYMMDD<seqno>_<ID buga/feature>.xml - więc przy tworzeniu releasu łatwo automatycznie wygenerować deskryptor projektu "wykonaj wszystko od 0 we właściwej kolejności" )
e) każdy deskryptor niesie metadane opisujące jak w ramach paczki skrypty mają być wykonywane (które zestawy skryptów sekwencyjne, które równolegle, jakie są zależności między zestawami skryptów, czy może być uruchomiony ponownie i masa innych funkcjonalności, które usprawniają zarządzanie releasami)
Development jest robiony przyrostowo (raz zreleasowane skrypty nie są modyfikowane!), np. może być taka historia:
- Utworz tabele FOO (rok 2000)
- Dodaj kolumne XYZ (rok 2003)
- Dodaj kolulmnę ABC (rok 2008)
- Ustaw dane w kolumnie ABC na podstawie danych z XYZ (razem z 3)
- Usuń kolumnę DEF (2012)
- Utworz trigger BAR (2018)
np. 2 klientów zaczyna używać systemu odpowiedni w 2004 i 2013 roku, to klient A przejdzie kilka "upgradów", a klientB będzie miał instalację od 0, na którą zostaną zaaplikoawne wszystkie upgrady.
W efekcie dla klientaB, krok 4 zostanie wykonany na "pustej kolekcji", zaś dla klientaA nie wiadomo co tam się uzbierało, ale wiadomo jak te dane zaktualizować.