Een raming maken van een databasemigratie

“Een kolom toevoegen” is een migratie van slechts één regel. De schatting heeft geen betrekking op de kolom.

Bij schemamigraties spelen twee tijdsfactoren een rol. De ene is de SQL: doorgaans snel en meestal routinematig. De andere is de operationele klok: hoe lang wordt de tabel vergrendeld, wat gebeurt er bij gelijktijdige schrijfbewerkingen, hoe kunt u de bewerking ongedaan maken als er iets misgaat, en wat is het noodplan als de bewerking langer duurt dan het implementatievenster? Het team stemt over de SQL, omdat dat op het ticket staat. Het werk vindt plaats op de tweede klok.

Op een klein tafeltje zijn de twee klokken identiek en is het verhaal werkelijk onbeduidend. Op elke tafel die ertoe doet, is dat echter niet het geval. Bij de schatting moet rekening worden gehouden met de backfill, de implementatiestrategie en de terugdraaiing – zaken die iemand moet hebben geoefend voordat de implementatie ook maar in de buurt van de productieomgeving komt.

Wat er in de kamer wordt gezegd

Backend: “Het is slechts een ALTER-opdracht; de migratie is binnen een seconde voltooid.”

SRE: “Op de ordertabel? Met de vergrendelingen ingeschakeld? Om 15.00 uur?”

DBA: “Hoe vullen wij bestaande rijen aan?”

SRE: “Wat is de terugdraaiingsprocedure als de implementatie halverwege mislukt?”

Leidende vraag: “Kan het leesproces het aan dat de kolom een uur lang de waarde ‘null’ heeft?”

Vragen die het waard zijn om te stellen voordat u gaat stemmen

• Hoe groot is de tabel: duizenden, miljoenen of honderden miljoenen rijen?
• Online migratietool of ALTER ter plaatse?
• Backfill-strategie: synchroon, batchverwerking, dubbele schrijfbewerking?
• Wat doet het leespad tijdens de implementatieperiode?
• Rollback: alleen vooruit, of kunnen wij het schema ongedaan maken?
• Heeft iemand het draaiboek voor de oproepdienst met betrekking tot deze migratie doorgenomen?

Als de helft van de aanwezigen voor „de SQL” stemt en de andere helft voor „de uitrol”, dan hebt u geen probleem met het aantal; u hebt te maken met twee verhalen die zich voordoen als één. Splits het op: de schemawijziging is één ticket, het backfill- en uitrolplan is een ander.

Maak een schatting van de implementatie en de terugdraaiing, niet van de ALTER-opdracht. Het risico schuilt in de tweede fase.

Zie het maken van een schatting voor een gegevensmigratie voor de systeemoverschrijdende variant, en de overige praktijkvoorbeelden van schattingen. Start een gratis Planning Poker-sessie zodra de uitrol in grote lijnen is geschetst.