Har holdt 1.022 migrationer fri for skemadrift

Situation. Et skema er beskrevet to gange i de fleste projekter: én gang af den indledende opsætning, der bygger det fra bunden, og én gang af de ophobede migrationer, der har fået det til at vokse. Begge skal give den samme database. Intet tjekker, at de gør det, så de glider fra hinanden — og afvigelsen er usynlig, indtil et nyopsat miljø opfører sig anderledes end produktion, som regel på det værst tænkelige tidspunkt.

Opgave. De to beskrivelser skulle automatisk og beviseligt være identiske, i stedet for at man en gang imellem bare troede, at de var det.

Handling. Databasen er versioneret som 1.022 migrationer, nummereret fra 036 til 1102, og rækkefølgedisciplinen omkring dem er kedelig og ikke til forhandling. Det, der får den til at holde, er et CI‑job, der bygger databasen to gange ved hver ændring: én gang fra et helt nyt startskema, én gang fra startskemaet plus hver eneste migration afspillet i rækkefølge — og så sammenligner de to. Ikke bare strukturen, som er den nemme halvdel, men også de seedede data, for en migration, der backfiller en opslagstabel forkert, er præcis lige så skadelig som en, der glemmer en kolonne, og kun den ene af dem dukker op i en skema‑diff. Enhver afvigelse får buildet til at fejle, og forskellen bliver skrevet ud.

Resultat. Et nyopsat miljø og et, der har kørt længe, er den samme database, og det bliver kontrolleret, ikke antaget. Prisen lander hos den, der skriver en migration: den skal virke, når den afspilles, og den skal virke fra bunden, hvilket kræver mere omtanke, end et hurtigt ALTER som regel får. Det er netop pointen — alternativet er at finde ud af det under en gendannelse, hvor svaret betyder noget, og der ikke er tid til at regne det ud.