SlpSoftware/aidlc-docs/features/react-frontend/operations/deployment/rollback-plan.md

Rollback Plan

Strategy

Sinds deze stap wordt de testomgeving automatisch gedeployed door de deploy-test job (zie deployment-instructions.md). "Rollback" betekent hier: de workflow opnieuw laten draaien tegen een eerdere, bekend-goede commit/branch, zodat die build automatisch opnieuw naar de test-Pi wordt geüpload en de huidige (foutieve) bestanden overschrijft.

Rolling Back the Live Site (Test-omgeving)

1. Identificeer de laatste bekend-goede commit op master (of een eerdere release/*-branch/tag) die succesvol gedeployed was.
2. Trigger de Continuous Integration workflow handmatig (workflow_dispatch) tegen die commit/branch/tag in Gitea Actions.
3. De deploy-test job uploadt automatisch de resulterende dist/-build via SCP naar /html/test/slpsoftware op de webserver-Pi — dit relatieve pad staat t.o.v. de root van de SCP-gebruiker (/mnt/storage1/www), waardoor nginx dezelfde bestanden serveert vanaf het volledige pad /mnt/storage1/www/html/test/slpsoftware (zie de uitleg hierover in deployment-instructions.md) — en overschrijft daarmee de huidige (foutieve) bestanden.
4. Verify de live testomgeving reflecteert de teruggedraaide versie (via het adres achter de reverse proxy).

Keeping Rollback Possible

• Do not delete release/* branches (or tags) after they've been deployed, so you can always re-run the pipeline against a known-good point.
• Optionally keep a local/manual copy of the last few uploaded dist/ artifacts as an extra safety net, since Gitea Actions artifacts expire after the configured retention period (currently 1 day, see .gitea/workflows/continuous_integration.yaml).

Database / Stateful Rollback Considerations

Not applicable — this unit (react-frontend-app) is a static marketing site with no database and no server-side state. There is nothing to roll back beyond the static files themselves.

Future Work

Zodra ook productie geautomatiseerd wordt (zie deployment-plan.md's "Open Item"), moet dit rollback-plan uitgebreid worden met een vergelijkbare procedure voor de deploy-production-job.

Post-Rollback Checklist

• Confirm the Gitea Actions run for the rollback build completed successfully
• Confirm the live site reflects the rolled-back version (spot-check a recently changed section/copy)
• Note the rollback (which release was restored and why) somewhere the team can find it
• If the rollback was due to a bug, track a fix before re-attempting the failed release