Terugdraaien (Rollback) in ontwikkeling: wat het is, manieren en hoe het werkt

Wat is terugdraaien en rollback in ontwikkeling

Terugdraaien (rollback) — de bewerking om het systeem terug te brengen naar een eerdere stabiele toestand. In de context van ontwikkeling kan dit het ongedaan maken van een commit in Git, het terugdraaien van een transactie in een database of het herstellen van een eerdere versie van de applicatie op de server betekenen. De term komt uit het Engelse “rollback” en is stevig verankerd in de woordenschat van ontwikkelaars van alle platforms.

De noodzaak tot terugdraaien ontstaat wanneer een nieuwe wijziging functionaliteit breekt, fouten veroorzaakt of de kwaliteitscontrole niet doorstaat. In een goed georganiseerd ontwikkelproces is terugdraaien geen teken van falen, maar een standaardprocedure die in de workflow is ingebouwd. Hoe sneller een team een problematische wijziging kan terugdraaien, hoe kleiner de impact van de bug op gebruikers.

Verschillende hulpmiddelen bieden verschillende terugdraaimechanismen: Git geeft de keuze tussen veilige revert en destructieve reset, databases ondersteunen transactionele rollback, en CI/CD-systemen kunnen verkeer tussen versies schakelen. De keuze van de aanpak hangt af van de context en de vereisten voor het behoud van de wijzigingsgeschiedenis.

Git revert vs git reset: wat is het verschil

Git revert — een veilige manier van terugdraaien die een nieuwe commit maakt die de wijzigingen van de vorige ongedaan maakt. De geschiedenis blijft lineair, alle oude commits blijven behouden. Dit is de enige juiste keuze voor terugdraaien in een gedeelde branch waar meerdere ontwikkelaars aan werken. De opdracht git revert verwijdert de geschiedenis niet — het voegt het feit van terugdraaien toe als een nieuwe wijziging.

Git reset verplaatst de wijzer van de huidige branch naar de opgegeven commit en negeert alle volgende wijzigingen. Afhankelijk van de vlag — soft, mixed of hard — behandelt reset de werkdirectory en index verschillend. De hard-modus verwijdert wijzigingen volledig uit de geschiedenis, wat het gevaarlijk maakt voor gedeelde branches en alleen geschikt voor lokaal werk.

Wanneer revert gebruiken

Revert wordt toegepast in gedeelde branches: main, develop, release. Het behoudt de geschiedenis en stelt andere ontwikkelaars in staat te begrijpen dat een wijziging is teruggedraaid. Na revert kan veilig git pull worden uitgevoerd — het systeem genereert geen conflicten gerelateerd aan herschreven geschiedenis. In teamwerk is revert de standaard.

# Maak de laatste commit ongedaan door een nieuwe commit te maken
git revert HEAD

# Maak een specifieke commit ongedaan via hash
git revert a1b2c3d

Wanneer reset gebruiken

Reset is geschikt in een lokale branch waar u nog geen wijzigingen heeft gepubliceerd. Als u heeft geëxperimenteerd en de geschiedenis volledig wilt opschonen — reset hard doet dat. In een lokale branch kunt u reset mixed gebruiken om commits ongedaan te maken, maar de wijzigingen in de werkdirectory te bewaren voor een nieuwe commit.

# Maak de laatste commit ongedaan, behoud wijzigingen in de werkdirectory
git reset HEAD~1

# Volledig ongedaan maken — wijzigingen zijn permanent verwijderd
git reset --hard HEAD~2

Rollback in databases: transacties en ACID

Transactierollback — de bewerking die alle wijzigingen binnen de huidige transactie ongedaan maakt en de database terugbrengt naar de toestand op het moment van starten. Dit garandeert atomiciteit — een van de vier principes van ACID (Atomicity, Consistency, Isolation, Durability). Als er in een van de fasen van de transactie een fout optreedt, wordt rollback uitgevoerd en keren de gegevens terug naar hun oorspronkelijke staat.

Het rollback-mechanisme wordt geïmplementeerd via write-ahead log (WAL). Voordat een gegevenspagina wordt gewijzigd, schrijft het DBMS de oude en nieuwe waarde naar het logboek. Bij rollback leest het systeem het logboek en herstelt de oorspronkelijke waarden voor alle gewijzigde pagina’s. Dit garandeert dat zelfs bij stroomuitval de transactie correct kan worden teruggedraaid.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: gedeeltelijk terugdraaien

In lange transacties is het handig om savepoint te gebruiken — tussenliggende opslagpunten waar u naar kunt terugkeren zonder de hele transactie te beeïndigen. Dit maakt het mogelijk om fouten binnen een complexe bewerking af te handelen zonder voortgang in andere delen ervan te verliezen. Savepoint wordt ondersteund door de meeste relationele DBMS: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Terugdraaien bij implementatie: strategieën en hulpmiddelen

Implementatie terugdraaien — het terugbrengen van een werkende applicatie naar de vorige versie na een mislukte implementatie. Dit is een cruciale mogelijkheid voor de productieomgeving: hersteltijd (MTTR) heeft directe invloed op SLA en gebruikerservaring. Moderne platforms bieden verschillende terugdraaistrategieën, afhankelijk van de architectuur en beschikbaarheidsvereisten.

Blue-green deployment

Blue-green — een strategie waarbij twee identieke omgevingen gelijktijdig werken: blue (huidige versie) en green (nieuwe versie). Verkeer wordt naar green geschakeld na een succesvolle implementatie. Als de nieuwe versie niet correct werkt, keert de verkeersschakelaar terug naar blue. Terugdraaien gebeurt onmiddellijk, zonder opnieuw implementeren — het wijzigen van de routering is voldoende.

Canary release met automatisch terugdraaien

Canary deployment stuurt een klein deel van het verkeer naar de nieuwe versie en bewaakt statistieken: aantal fouten, responstijd, percentage succesvolle verzoeken. Als de statistieken verslechteren, draait het systeem automatisch de canary terug en stuurt al het verkeer naar de stabiele versie. Kubernetes en service meshes (Istio, Linkerd) ondersteunen deze strategie uit de doos.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Praktische voorbeelden van terugdraaien in ontwikkeling

Laten we drie typische scenario’s bekijken waarin een ontwikkelaar wijzigingen moet terugdraaien. Elk scenario vereist zijn eigen aanpak — van een eenvoudig commando in de terminal tot een meerstappenprocedure met CI/CD.

Scenario 1: per ongeluk commit in main

U heeft per ongeluk een commit met een bug naar main gepusht. Uw taak is de wijzigingen terug te draaien zonder de geschiedenis voor het team te verliezen. Gebruik git revert om een terugdraaiende commit te maken en vervolgens git push. Alle teamleden zullen het feit van terugdraaien zien en kunnen zonder conflicten verder werken. Dit is de veiligste en meest transparante methode.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Scenario 2: mislukte databasemigratie

De databasemigratie is met een fout geeïndigd en een deel van de gegevens is beschadigd. Gebruik transactionele rollback in het migratiescript en herstel uit backup voor reeds toegepaste wijzigingen. In een goed ontworpen systeem is elke migratie ingepakt in een transactie — bij een fout voert het DBMS automatisch rollback uit.

Scenario 3: implementatie met kritieke bug

Na implementatie van de nieuwe versie heeft u ontdekt dat authenticatie niet werkt. Als u blue-green gebruikt, is terugdraaien het terugschakelen van de router. Bij rolling update — de opdracht kubectl rollout undo brengt de vorige versie terug. Idealiter moet het terugdraaiproces geautomatiseerd zijn en niet langer dan een minuut duren.