Applicatiecode staat al jaren in Git. In veel teams de database nog niet. Het schema leeft in productie, wijzigingen worden als scripts op iemands laptop geschreven, en het enige volledige overzicht van wat er veranderd is, is de database zelf.
Dat maakt elke andere verbetering lastiger. U kunt geen wijziging reviewen die u niet ziet, geen deployment testen die u niet kunt herhalen, en geen release automatiseren als niemand zeker weet in welke staat de doeldatabase is.
In eerdere artikelen keken we naar wat Redgate Flyway is en waarom vertraging bij databases het rendement van automatisering verlaagt. Dit artikel gaat over de eerste praktische stap: een bestaande database onder versiebeheer brengen.
Wat versiebeheer u oplevert
Zodra de database in Git staat, heeft elke wijziging een auteur, een datum en een reden. Wijzigingen gaan door dezelfde pull requests als applicatiecode, zodat een databasespecialist ze kan beoordelen voordat ze productie bereiken in plaats van erna. En omdat de scripts in de repository staan, kan elke omgeving vanuit dezelfde bron worden opgebouwd.
Het verandert ook het gesprek over releases. De vraag is niet meer wie wat heeft uitgevoerd, en waar. De vraag is op welke versie een database staat.
Begin bij wat er vandaag draait
De meeste teams beginnen niet met een lege database. De eerste taak is de huidige staat vastleggen als vertrekpunt.
Met Flyway zijn er twee gangbare routes. U kunt het bestaande schema uitschrijven als eerste migratie, zodat een nieuwe omgeving vanaf nul kan worden opgebouwd. Of u gebruikt flyway baseline om Flyway te laten weten dat een bestaande database al op een bepaalde versie staat, zodat alleen latere wijzigingen worden toegepast. De meeste teams hebben beide nodig: een script dat een schone database bouwt voor ontwikkeling en test, en een baseline voor de productiedatabases die er al zijn.
Vergelijk uw omgevingen voordat u iets vastlegt. Ontwikkeling, test en productie komen zelden precies overeen. Een index die tijdens een incident is toegevoegd of een procedure die direct in productie is aangepast, lost u nu makkelijker op dan nadat die een mislukte deployment heeft veroorzaakt.
Versioneer vanaf dan elke wijziging
Vanaf de baseline is elke wijziging een migratiescript in de repository. Flyway past versioned migrations op volgorde toe en registreert elke migratie in een schemageschiedenistabel in de database, zodat het altijd weet welke scripts een database al heeft gehad.
Een paar afspraken maken dit in de praktijk werkbaar:
- Eén wijziging per migratie, met een naam die zegt wat die doet.
- Een migratie die al is uitgevoerd, wordt nooit meer aangepast. Een correctie is een nieuwe migratie.
- Views, stored procedures en functies kunt u bewaren als repeatable migrations, die Flyway opnieuw toepast zodra de inhoud verandert.
- Referentiedata waar de applicatie van afhangt, hoort ook onder versiebeheer. Klantdata niet.
Laat de pipeline de deployments doen
Met de database in Git kan de pipeline het werk overnemen dat mensen voorheen met de hand deden. Een pull request voert de migraties uit op een testdatabase, zodat een kapot script faalt in de build in plaats van in een onderhoudsvenster. Na goedkeuring gaan dezelfde scripts in dezelfde volgorde door test, acceptatie en productie.
Flyway draait vanaf de commandline en past daardoor in Azure DevOps, GitHub Actions of elk ander CI-systeem. Teams op GitHub kunnen de Flyway Actions van Redgate gebruiken.
Afhankelijk van de editie en het databaseplatform voegt Flyway controles toe die reviewers helpen: rapporten van wat een deployment gaat veranderen, geautomatiseerde codecontroles en driftdetectie die een release stopt wanneer productie buiten het proces om is gewijzigd.
Veelgehoorde zorgen
Onze database is te groot of te oud. Omvang telt voor data, niet voor het schema. Een baseline legt de structuur vast, en Flyway past alleen de wijzigingen toe die daarna komen.
Onze DBA's verliezen de controle. Ze krijgen er juist meer. Ze beoordelen elke wijziging in de pull request, en productie krijgt alleen wat is goedgekeurd. Toegang tot productie kan beperkt blijven tot de pipeline.
Wij doen noodfixes direct in productie. Soms is dat nodig. Spreek af dat elke noodfix achteraf aan de repository wordt toegevoegd, en gebruik driftdetectie om de fixes te vinden waarbij dat niet is gebeurd.
Waar u begint
Kies één applicatie waarvan de database vaak verandert en die wrijving oplevert. Vergelijk de omgevingen, leg een baseline vast, en laat de volgende wijziging via een pull request en een pipeline lopen. Eén routinewijziging die zonder handmatige stap in productie komt, is een beter argument dan welke presentatie ook.
Masterminds is al jaren Redgate Gold Partner. Onze DevOps- en Data-teams helpen bij de eerste beoordeling, de baseline en de pipeline, zie Database Automation met Redgate Flyway. Neem contact op als u uw eerste database onder versiebeheer wilt brengen.
