Innan ni anställer fler utvecklare eller investerar i ännu en leveransplattform är det värt att titta på hur länge färdiga ändringar faktiskt väntar innan de når kunderna. Om databasändringar fortfarande hanteras i en separat process och måste köras manuellt leder mer utvecklingskapacitet inte automatiskt till snabbare leveranser.
Utvecklingen är redan betald. Så länge funktionen inte är i produktion uteblir också de intäkter eller besparingar som den förväntas ge.
Var kostnaderna uppstår
Ta en uppdatering av en kundportal som berör fyra applikationer och deras databaser. Utvecklingen är klar, men databasändringarna måste fortfarande samordnas mellan flera specialister och planeras in i lämpliga underhållsfönster.
En del av den förberedelsen är nödvändig. Frågan är hur mycket tid som faktiskt går till riskbedömning och hur mycket som går till samordning, överlämningar och planering.
Om varje release kräver så mycket arbete blir det naturligt att samla flera ändringar i samma release. Färdiga funktioner får vänta på annat arbete, och när något går fel blir det svårare att snabbt hitta orsaken. Mindre releaser gör fel enklare att identifiera och åtgärda.
Samtidigt lägger erfarna databasspecialister tid på att köra redan godkända skript i stället för att arbeta med prestanda, tillförlitlighet och förbättringar av plattformen.
Det påverkar även planeringen. Ett projekt kan enligt utvecklingsrapporteringen ligga helt i fas samtidigt som databasändringarna fortfarande står i en separat kö. Realistiska lanseringsdatum måste ta hänsyn till båda.
Gör databasen till en del av releaseprocessen
Med Redgate Flyway kan databasändringar bli en del av samma automatiserade releaseprocess som applikationsändringar. Team lagrar ändringar som versionshanterade skript i källkodshanteringen. Flyway kör väntande migreringar i rätt ordning och registrerar vilka ändringar som har genomförts i varje databas.
Databasspecialister kan granska ändringar redan under utvecklingen, medan pipelinen sedan hanterar den godkända körningen. Problem upptäcks tidigare och en driftsättning är inte längre beroende av att någon manuellt går igenom en serie skript.
Team som använder GitHub bör också titta på Redgates Flyway Actions. De lanserades tidigare i år och innehåller återanvändbara steg för att kontrollera och driftsätta databasändringar.
Behåll kontrollen över produktion
Flyway Enterprise kan upptäcka oväntade ändringar i databasstrukturen, till exempel en akut ändring som aldrig fördes tillbaka in i den ordinarie releaseprocessen. En korrekt konfigurerad pipeline kan då stoppa driftsättningen så att avvikelsen först kan undersökas.
Beroende på utgåva och databasplattform erbjuder Flyway även förhandsgranskning av planerade ändringar och automatiserade kodkontroller. Det ger granskare bättre underlag innan de godkänner en driftsättning.
Befintliga godkännanden och åtkomstbegränsningar behöver inte tas bort. Bestäm vem som får godkänna ändringar, hur akuta ändringar dokumenteras och var information om godkännanden och driftsättningar sparas.
Stora datamigreringar behöver fortfarande förberedas och testas noggrant, och vissa ändringar kräver fortfarande ett underhållsfönster. Automatisering ersätter varken specialistkunskap eller en bra återställningsplan.
Börja med en applikation
Börja med en applikation där databasarbete regelbundet försenar leveransen. Låt applikations- och databasteamen tillsammans fastställa nuläget, lösa skillnader mellan miljöerna och automatisera de kommande ändringarna.
Mät sedan väntetid, manuellt arbete och misslyckade driftsättningar över flera releaser. Ta även med licens- och införandekostnader i bedömningen. Målet är kortare väntetider och mindre manuellt arbete utan att antalet incidenter ökar.
Ett första resultat kan vara så enkelt som att en rutinändring går i produktion den här veckan i stället för att vänta på nästa månads underhållsfönster.
Masterminds har varit Redgate Gold Partner i många år. Våra DevOps- och Data-team arbetar tillsammans med den inledande kartläggningen, automatiseringen och de första driftsättningarna, inklusive de gransknings- och undantagsprocesser som produktionsteamen behöver.
Boka ett samtal för att gå igenom en nyligen försenad release och se var databasautomatisering hade kunnat göra skillnad.
