Hur man undviker att skjuta sig själv i foten med Liquibase

Aldrig har det varit så, och nu igen!

I vårt senaste projekt bestämde vi oss för att använda Liquibase från början för att undvika problem i framtiden. Det visade sig att inte alla unga medlemmar i teamet vet hur man använder det på rätt sätt. Jag håll en intern workshop som jag sedan bestämde mig för att omvandla till en artikel.

Artikeln innehåller användbara tips och en beskrivning av tre av de mest uppenbara fällorna man kan gå i när man arbetar med verktyg för migrering av relationsdatabaser, särskilt Liquibase. Den är avsedd för Java-utvecklare på junior- och mellannivå, medan mer erfarna utvecklare kan finna den intressant för att strukturera och repetera sådant de troligen redan känner till.

Liquibase och Flyway är de två huvudsakliga konkurrerande teknologierna för att hantera versionering av relationsstrukturer i Java-världen. Den första är helt gratis och brukar praktiskt taget oftare väljas för användning, därför är det Liquibase som valts som huvudämne för publiceringen. Trots detta kan vissa av de beskrivna praktikerna vara universella beroende på arkitekturen av din applikation.

Migrering av relationsstrukturer har blivit ett nödvändigt sätt att hantera den svaga flexibiliteten hos relationsdatabaslagring. Under den tid då OOP var populärt innebar arbetet med databaser att vi en gång beskrev schemat och inte skulle ändra det igen. Men verkligheten är alltid sådan att allt förändras och förändringar i tabellstrukturer krävs ganska ofta. Naturligtvis kan själva processen vara smärtsam och obehaglig.

Jag kommer inte att gå djupare in på beskrivningen av teknologin och instruktionerna för att lägga till biblioteket i ditt projekt, det har redan skrivits tillräckligt med artiklar om det:

• Användning av Liquibase för att hantera databasstrukturen i ett Spring Boot-projekt. Del 1
• Användning av Liquibase för att hantera databasstrukturen i ett Spring Boot-projekt. Del 2
• Liquibase och Maven
• Metoder för att versionera databasändringar
• Spring MVC/Security, REST, Hibernate, Liquibase startar i två rader

Dessutom har det redan funnits en utmärkt artikel med användbara tips:

• Använda Liquibase utan huvudvärk. 10 tips från verklig utveckling

Tips

Jag vill dela med mig av mina tips och kommentarer som föddes genom svett, blod och smärta från att lösa migrationsproblem.

1. Innan arbetet påbörjas bör man bekanta sig med avsnittet om bästa praxis på webbplats Liquibase

Där Enkla men viktiga aspekter beskrivs här, utan vilka användningen av biblioteket kan bli komplicerad. Till exempel, en icke-strukturerad metod för hantering av changsets leder förr eller senare till förvirring och trasiga migrationer. Om man gör beroende förändringar av databasstrukturen och tjänsternas logik utan att utföra dem samtidigt, ökar risken för att detta resulterar i röda tester eller en trasig miljö. Dessutom innehåller rekommendationerna för användning av Liquibase på den officiella webbplatsen ett avsnitt om att utveckla och testa rollback-skript tillsammans med huvud-migreringsskripten. Nåväl, i artikeln https://habr.com/ru/post/178665/ finns exempel på kod som rör migrationer och rollback-mekanismen.

2. Om ni har börjat använda migrationsverktyg – tillåt inte manuella ändringar i databasstrukturen.

Som man säger: "En gång Persil - alltid Persil". Om er applikationsdatabas har börjat hanteras av Liquibase, leder alla manuella ändringar omedelbart till ett inkonsekvent tillstånd, och tilliten till changsets sjunker till noll. Potentiella risker inkluderar timmar av arbete för att återställa databasen, och i värsta fall – en kraschad server. Om det finns en DBA-arkitekt i ert team "av den gamla skolan", förklara tålmodigt och eftertänksamt hur illa det kan bli om han redigerar databasen efter eget tycke i något hypotetiskt SQL Developer.

3. Om changset redan har pushats till repositoriet, undvik att redigera.

Om en annan utvecklare gör en pull och tillämpar ett changset som senare kommer att redigeras – kommer han definitivt att nämna dig med vänliga ord när han får ett fel vid start av applikationen. Om redigeringen av changset på något sätt läcker in i utvecklingsmiljön – måste man navigera den hala vägen av hotfixar. Problemet handlar om validering av ändringar via hash-värde – den grundläggande mekanismen i Liquibase. När kod i changset redigeras ändras hash-värdet. Redigering av changsets är endast möjligt när det finns möjlighet att återställa hela databasen från början utan datarförlust. I sådana fall kan refactoring av SQL- eller XML-koden faktiskt underlätta arbetet och göra migrationer mer läsbara. Ett exempel kan vara situationen när schemat för den ursprungliga databasen godkändes inom teamet i början av applikationen.

4. Ha verifierade databackups, om möjligt

Här är jag säker på att allt är klart. Om migrationen misslyckas kan allt återställas. I Liquibase finns ett verktyg för att ångra ändringar, men skripten för att ångra behöver också skrivas av utvecklaren själv, och de kan ha lika stora problem som skripten för den ursprungliga förändringsuppsättningen. Detta innebär att det är bra att vara förutseende med backup.

5. Använd verifierade databackups i utvecklingen, om möjligt

Om det inte strider mot avtal och sekretess, om databasen inte innehåller personuppgifter och inte väger som två solar — innan migrationen till levande servrar kan det vara bra att testa hur det fungerar på utvecklarens maskin och beräkna nästan 100% av de potentiella problemen vid migreringen.

6. Kommunicera med andra utvecklare i teamet

I en välorganiserad utvecklingsprocess vet alla i teamet vem som gör vad. I verkligheten är det ofta inte så, så om du gör ändringar i databasstrukturen inom din uppgift, är det bra att informera hela teamet om detta. Om någon gör ändringar parallellt — bör du organisera er noggrant. Det är bra att kommunicera med kollegor även efter att jobbet är klart, inte bara i början. Många potentiella problem med förändringsuppsättningar kan lösas i kodgranskningen.

7. Tänk på vad du gör!

Det verkar som en självklarhet, tillämplig i alla situationer. Men många problem skulle kunnat undvikas om utvecklaren analyserade en gång till vad han gör och vilken påverkan det kan ha. Att arbeta med migrationer kräver alltid extra uppmärksamhet och noggrannhet.

Fällor

Låt oss nu se på typiska fällor man kan hamna i om man inte följer ovanstående råd, och vad man egentligen ska göra?

Situation 1. Två utvecklare försöker samtidigt lägga till nya förändringsuppsättningar

Vanya och Petya vill skapa förändringsuppsättning version 4 utan att veta om varandra. De har gjort ändringar i databasstrukturen och skickat pull request med olika filer för förändringsuppsättningen. Följande mekanism föreslås:

Hur man löser

1. På något sätt måste kollegorna komma överens om i vilken ordning deras förändringsuppsättningar ska gå, låt oss säga att Petyas ska tillämpas först.
2. Någon måste lägga till den andra till sig själv och markera Vasas changset med version 5. Detta kan göras genom Cherry Pick eller en noggrann merge.
3. Efter ändringarna bör man alltid kontrollera giltigheten av de utförda åtgärderna.
   I själva verket tillåter Liquibase-mekanismerna att ha två changsets i version 4 i repositoryn, så det går bra att lämna allt som det är. Det vill säga att ni bara kommer att ha två förändringar av version 4 med olika namn. Med detta tillvägagångssätt blir det mycket svårt att navigera i databaskversionerna senare.

Dessutom, precis som hobbitarnas hem, döljer Liquibase många hemligheter. En av dem är nyckeln validCheckSum, som introducerades i version 1.7 och gör det möjligt att ange ett giltigt värde för hash-summan för ett specifikt changset oavsett vad som lagras i databasen. Dokumentationen https://www.liquibase.org/documentation/changeset.html säger följande:

Lägg till en checksumma som anses vara giltig för detta changeSet, oavsett vad som lagras i databasen. Används främst när du behöver ändra ett changeSet och inte vill ha fel på databaser där det redan har körts (inte en rekommenderad procedur)

Ja, ja, en sådan procedur rekommenderas inte. Men ibland behärskar en mäktig ljus magiker även de mörka teknikerna.

Situation 2. Migration som beror på data

Anta att du inte har möjlighet att använda säkerhetskopior av databaser från aktiva servrar. Petya skapade ett changset, kontrollerade det lokalt och med full självsäkerhet gjorde han en pull request till utvecklingen. Projektledaren kollade för säkerhets skull om Petya hade kontrollerat det och sedan fusionerade han. Men deployment på utvecklingsservern misslyckades.

I själva verket är detta möjligt, och ingen är skyddad mot det. Detta sker om tabellstrukturerna på något sätt är kopplade till specifika data från databasen. Det är uppenbart att om Petyas databas bara är fylld med testdata, så kan den kanske inte täcka alla problematiska fall. Till exempel, vid borttagning av en tabell visar det sig att det finns poster i andra tabeller via Foreign Key som är kopplade till poster i den borttagna. Eller vid ändring av kolumntypen visar det sig att inte 100% av data kan konverteras till den nya typen.

Hur man löser

• Skriva speciella skript som en gång kommer att användas tillsammans med migreringen för att föra data i rätt skick. Detta är en generell väg för att lösa problemet med att överföra data till nya strukturer efter att migreringarna har utförts, men något liknande kan tillämpas även före, i vissa fall. Sådana lösningar är självklart inte alltid tillgängliga, eftersom att redigera data på aktiva servrar kan vara riskabelt och till och med katastrofalt.
• En annan komplex väg är att redigera den befintliga changset. Komplikationen ligger i att alla databaser där den har tillämpats i sin nuvarande form måste återställas. Det är fullt möjligt att hela backend-teamet tvingas lokalt installera databasen från grunden.
• Och den mest universella vägen är att flytta problemet med data till utvecklarens miljö genom att återskapa samma situation och lägga till en ny changset, före den trasiga, som gör det möjligt att kringgå problemet.
  

Generellt sett, ju mer databasen i fråga liknar produktionsserverns databaser, desto mindre chans är det att migrationsproblem uppstår. Och självklart, innan man skickar changset till ett repository, bör man tänka flera gånger på om det kommer att krossa något.

Situation 3. Liquibase börjar tillämpas först efter produktionslanseringen.

Anta att teamledaren har bett Petja att ansluta Liquibase i projektet, men projektet är redan i produktion och det finns redan en befintlig databasstruktur.

Problemet är således att på varje nya servrar eller utvecklarmaskiner måste de här tabellerna återskapas från grunden, medan den redan existerande miljön måste förbli i ett konsekvent tillstånd, redo att ta emot nya changset.

Hur man löser

Här finns också flera möjliga vägar:

• Det första och mest uppenbara är att ha ett separat skript som måste tillämpas manuellt vid initiering av en ny miljö.
• Det andra, mindre uppenbara, är att ha en Liquibase-migrering som tillhör en annan Liquibase-kontext och tillämpa den. Mer information om Liquibase-kontext kan läsas här: https://www.liquibase.org/documentation/contexts.html. Övergripande är detta en intressant mekanism som kan tillämpas framgångsrikt, till exempel för testning.
• Den tredje vägen består av flera steg. Först måste en migrering skapas för de redan existerande tabellerna. Sedan måste den tillämpas i en viss miljö för att få dess hashvärde. Nästa steg är att initiera tomma Liquibase-tabeller på vår icke-tomma server, och i tabellen med historik för tillämpade changsets kan man manuellt lägga till en post om ett "som om tillämpat" changset med redan befintliga förändringar i databasen. På så sätt börjar historiken på den redan existerande servern från version 2, och alla nya miljöer kommer att bete sig identiskt.
  

Situation 4. Migreringarna blir enorma och hinner inte genomföras

I början av utvecklingen av tjänsten används oftast Liquibase som ett externt beroende, och alla migreringar hanteras vid appens start. Men med tiden kan du stöta på följande fall:

• Migreringarna blir enorma och tar lång tid att genomföra.
• Det uppstår behov av migrering i distribuerade miljöer, till exempel på flera instanser av databasservrar samtidigt.
  I sådana fall kommer en alltför lång tillämpning av migreringarna att leda till timeouts vid appens start. Dessutom kan tillämpningen av migreringar för varje instans av applikationen separat leda till att olika servrar hamnar i ett osynkroniserat tillstånd.

Hur man löser

I sådana fall är ditt projekt redan stort, kanske till och med vuxet, och Liquibase börjar fungera som ett separat externt verktyg. Anledningen är att Liquibase som bibliotek packas i en jar-fil och kan fungera både som beroende inom projektet och autonomt.

I autonomt läge kan tillämpningen av migreringar läggas på din CI/CD-miljö eller på de starka axlarna hos dina systemadministratörer, som är specialister på driftsättning. För detta behövs kommandoraden för Liquibase. https://www.liquibase.org/documentation/command_line.html. I det läget finns möjlighet att starta applikationen först efter att alla nödvändiga migreringar har genomförts.

Utdata

Det finns faktiskt många fler fällor när man arbetar med databasmigreringar, och många av dem kräver ett kreativt tillvägagångssätt. Det är viktigt att förstå att om verktyget används korrekt, så kan de flesta av dessa fällor undvikas. Personligen har jag i olika former stött på alla nämnda problem, och vissa av dem har varit ett resultat av mina egna misstag. Oftast händer detta på grund av oförsiktighet, men ibland på grund av en kriminell oförmåga att använda verktyget.

Källa: habr.com