# 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