Een rollback is het terugzetten van je software naar een eerdere, werkende versie nadat een nieuwe release misgaat. Introduceert een uitrol een bug, breekt een functie of veroorzaakt downtime, dan zet een rollback de oude werkende versie terug voor gebruikers terwijl het team de oorzaak uitzoekt.
Zie het als een document opslaan voordat je grote aanpassingen doet. Pakt de nieuwe versie slechter uit? Dan open je gewoon de opgeslagen kopie en ga je verder. Een nette repository en een degelijke CI/CD-pijplijn maken dit makkelijk, omdat elke versie wordt bijgehouden en klaarstaat om opnieuw uit te rollen.
Sommige releasestrategieën maken een rollback bijna direct. Bij blue-green deployment blijft de oude versie standby draaien, dus terugschakelen is een kwestie van het verkeer omleiden. Het doel is hoe dan ook hetzelfde: de schade van een slechte release beperken en gebruikers er niets van laten merken. Eén ding om te weten: code terugdraaien is makkelijk, data terugdraaien niet. Heeft de kapotte release de database al aangepast, een kolom verwijderd of records in een nieuw formaat weggeschreven? Dan kan de oude code na het terugschakelen naar data staren die hij niet begrijpt. Goede teams houden hier rekening mee door databasewijzigingen achterwaarts compatibel te maken, zodat de vorige versie blijft werken ook nadat de nieuwe heeft gedraaid. Een rollback die je hebt geoefend is een rustige beslissing van twee minuten. Een rollback die je nooit hebt getest is paniek midden in een storing, precies het moment waarop je geen verrassingen wilt.
Bij TopDevs bouwen we elke uitrol zo dat hij binnen minuten terug te draaien is, waardoor een riskante release nooit een lange storing hoeft te worden.
