Applikationskod har legat i Git i åratal. I många team gör databasen det fortfarande inte. Schemat lever i produktion, ändringar skrivs som skript på någons laptop, och den enda fullständiga bilden av vad som har ändrats är databasen själv.
Det gör varje annan förbättring svårare. Ni kan inte granska en ändring ni inte ser, inte testa en driftsättning ni inte kan upprepa och inte automatisera en release när ingen vet säkert i vilket skick måldatabasen är.
I tidigare artiklar tittade vi på vad Redgate Flyway är och varför databasförseningar minskar avkastningen på automatisering. Den här artikeln handlar om det första praktiska steget: att få in en befintlig databas i versionshantering.
Vad versionshantering ger er
När databasen ligger i Git har varje ändring en upphovsperson, ett datum och ett skäl. Ändringar går genom samma pull requests som applikationskoden, så att en databasspecialist kan granska dem innan de når produktion i stället för efteråt. Och eftersom skripten ligger i repot kan varje miljö byggas från samma källa.
Det ändrar också samtalet om releaser. Frågan är inte längre vem som körde vad, och var. Frågan är vilken version en databas är på.
Börja med det som körs i dag
De flesta team börjar inte med en tom databas. Det första jobbet är att fånga det nuvarande läget som utgångspunkt.
Med Flyway finns två vanliga vägar. Ni kan skripta det befintliga schemat som en första migrering, så att en ny miljö kan byggas från grunden. Eller så använder ni flyway baseline för att tala om för Flyway att en befintlig databas redan är på en viss version, så att bara senare ändringar tillämpas. De flesta team behöver båda: ett skript som bygger en ren databas för utveckling och test, och en baseline för de produktionsdatabaser som redan finns.
Jämför era miljöer innan ni fångar något. Utveckling, test och produktion stämmer sällan exakt överens. Ett index som lades till under en incident eller en procedur som rättades direkt i produktion är lättare att reda ut nu än efter att det har orsakat en misslyckad driftsättning.
Versionera varje ändring därefter
Från baselinen och framåt är varje ändring ett migreringsskript i repot. Flyway tillämpar versioned migrations i ordning och registrerar var och en i en schemahistoriktabell i databasen, så att Flyway alltid vet vilka skript en databas redan har fått.
Några överenskommelser gör att det fungerar i praktiken:
- En ändring per migrering, med ett namn som säger vad den gör.
- En migrering som har körts redigeras aldrig. En rättelse är en ny migrering.
- Vyer, lagrade procedurer och funktioner kan hållas som repeatable migrations, som Flyway tillämpar igen så fort innehållet ändras.
- Referensdata som applikationen är beroende av hör också hemma i versionshanteringen. Kunddata gör det inte.
Låt pipelinen sköta driftsättningen
Med databasen i Git kan pipelinen ta över det arbete som tidigare gjordes för hand. En pull request kör migreringarna mot en testdatabas, så att ett trasigt skript fallerar i bygget i stället för i ett underhållsfönster. Efter godkännande går samma skript i samma ordning genom test, acceptans och produktion.
Flyway körs från kommandoraden och passar därför i Azure DevOps, GitHub Actions eller vilket annat CI-system som helst. Team på GitHub kan använda Redgates Flyway Actions.
Beroende på utgåva och databasplattform lägger Flyway till kontroller som hjälper granskare: rapporter över vad en driftsättning kommer att ändra, automatiska kodkontroller och driftdetektering som stoppar en release när produktion har ändrats utanför processen.
Vanliga farhågor
Vår databas är för stor eller för gammal. Storleken spelar roll för data, inte för schemat. En baseline fångar strukturen, och Flyway tillämpar bara de ändringar som kommer efter den.
Våra DBA:er tappar kontrollen. De får mer av den. De granskar varje ändring i pull requesten, och produktion får bara det som har godkänts. Åtkomsten till produktion kan fortsätta vara begränsad till pipelinen.
Vi gör akuta rättningar direkt i produktion. Ibland är det nödvändigt. Kom överens om att varje akut rättning läggs till i repot i efterhand, och använd driftdetektering för att hitta de rättningar där det inte skedde.
Var ni börjar
Välj en applikation vars databas ändras ofta och skapar friktion. Jämför dess miljöer, fånga en baseline och låt nästa ändring gå genom en pull request och en pipeline. En rutinändring som når produktion utan något manuellt steg är ett bättre argument än vilken presentation som helst.
Masterminds är sedan länge Redgate Gold Partner. Våra DevOps- och datateam hjälper till med den första bedömningen, baselinen och pipelinen, se Database Automation med Redgate Flyway. Kontakta oss om ni vill få in er första databas i versionshantering.
