Bepaal wat sinds de release is veranderd
Een vorige codeversie terugzetten is niet hetzelfde als de hele applicatie terugzetten. De nieuwe versie kan databasevelden hebben gewijzigd of al orders, uploads en andere gegevens hebben verwerkt.
Noteer de actieve release, het startmoment van de fout en uitgevoerde migraties. Bewaar de foutmelding en een kopie van de huidige gegevens voordat u ingrijpt. Spreek af of nieuwe schrijfacties tijdelijk moeten stoppen.
Controleer of de oude code nog past
Een toegevoegde kolom vormt een andere situatie dan een verwijderde kolom of omgezette gegevensstructuur. Laat de ontwikkelaar bepalen of de vorige code met de huidige database kan werken.
Bij Laravel draait migrate:rollback migraties uit een batch terug volgens hun down-methode. Dat herstelt niet automatisch verwijderde gegevens en kan zelf tabellen of kolommen verwijderen. Voer zo'n opdracht daarom niet uit als algemeen antwoord op een mislukte release.
Kies het passende herstelpad
Als de database compatibel is, kan het activeren van de vorige release voldoende zijn. Controleer daarbij caches, frontendbestanden en processen die oude of nieuwe code in het geheugen houden.
Als de database niet compatibel is, kiest de ontwikkelaar tussen een gerichte herstelwijziging en databaseherstel. Bij een backup moet ook worden bepaald hoe nieuwere gegevens behouden blijven. Een backup van vóór de release bevat bijvoorbeeld geen daarna geplaatste bestellingen.
Test na het terugschakelen
Controleer de fout die aanleiding gaf tot herstel én de belangrijkste bedrijfsfunctie. Controleer queue workers, geplande taken en externe koppelingen op dubbele of gemiste verwerking.
Leg vast welke versie nu draait en welke gegevens zijn behouden of nog moeten worden hersteld. Geef de omgeving pas vrij wanneer de betrokken beheerder en verantwoordelijke voor de applicatie de uitkomst hebben gecontroleerd.