Achtergrond van de kwestie
Werken aan grote projecten vereist dat de structuur van de database zich gelijktijdig ontwikkelt met de applicatiecode. Zonder programmatische versiecontrole van wijzigingen in het schema (toevoegen, verwijderen en wijzigen van tabellen, indexen, sleutels) raakt het team snel uit sync, neemt het risico op verlies van wijzigingen toe, misschien mislukkingen van migraties en wordt het moeilijker om fouten terug te draaien of te reproduceren.
Probleem
De traditionele benadering – handmatige wijzigingen van de database via SQL-scripts – leidt tot een onduidelijke volgorde van uitvoering van wijzigingen, problemen bij het terugdraaien, en inconsistenties in versies tussen omgevingen (dev, test, prod). Zonder een gemeenschappelijk hulpmiddel voor het opslaan van migraties is het moeilijk te begrijpen wie, wanneer en waarom het schema heeft gewijzigd.
Oplossing
Voor deze taak worden schema-migratiesystemen en database versioning praktijken gebruikt. Het toepassen van tools (bijvoorbeeld Liquibase, Flyway, Alembic voor verschillende DBMS) maakt het mogelijk om SQL-scripts van schema-wijzigingen direct in het versiecontrolesysteem (git) op te slaan, een strikte volgorde van migraties te vormen en schema-updates op alle omgevingen te automatiseren.
Voorbeeld van code (migratie via Flyway):
-- V002__add_column_email.sql ALTER TABLE users ADD COLUMN email VARCHAR(255) NOT NULL;
Integratie van Flyway (bijvoorbeeld voor Java):
Flyway.configure().dataSource(url, user, pass).load().migrate();
Kernkenmerken:
Kan ik de "oorspronkelijke staat" van het schema (snapshot) opslaan in plaats van migraties? Op het eerste gezicht is een "dump" van het hele schema eenvoudiger dan migraties. Maar dan ontstaan er problemen bij het terugdraaien, het herstellen van tussenstaten en het samenvoegen van wijzigingen uit verschillende takken. Migraties stellen je in staat om alleen nieuwe wijzigingen sequencerend en in de juiste volgorde toe te passen.
Moet ik migraties handmatig synchroniseren tussen verschillende omgevingen? Nee, moderne systemen respecteren versiebeheer en passen alleen die migraties toe die nog niet in de database aanwezig zijn. Het belangrijkste is niet handmatige synchronisatie, maar geautomatiseerde toepassing van migraties bij het deployen.
Is het voldoende om alleen de SQL-scripts van migraties op te slaan of moet ik ook iets anders opslaan? Een goede praktijk is om naast SQL-scripts ook hun beschrijving (doel, auteur, datum) op te slaan, evenals tests-validoren voor nieuwe structurele wijzigingen, om de kwaliteitscontrole van migraties te automatiseren.
Het project maakte gebruik van gewone dumps van schema's en "handmatige" toepassing van wijzigingen door ontwikkelaars. Na de lancering van de update merkte de klant op dat sommige nieuwe kolommen niet verschenen in de productie-database, en sommige indexen verdubbelden na elke poging om het schema bij te werken.
Voordelen:
Snel voor zeer kleine projecten.
Nadelen:
Problemen met onderhoud; niet duidelijk wat precies is gewijzigd en door wie; geen mogelijkheid om terug te draaien; verschillende omgevingen gaan uit elkaar.
Het team integreerde Flyway, alle structurele wijzigingen worden gedaan via migraties met code-review, het terugdraaien van elke versie duurde enkele minuten, en het was eenvoudig om tests en controles uit te voeren op alle omgevingen.
Voordelen:
Automatisering, geschiedenis, lage kans op bugs bij het deployen.
Nadelen:
Vereist iets langere documentatie van elke wijziging in de structuur.