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

Rollback Plan

Strategy

Since there is no automated upload step yet (deployment is manual — see deployment-instructions.md), "rollback" today means re-uploading a previous known-good build to the host by hand, rather than the pipeline reverting anything automatically.

Rolling Back the Live Site

1. Identify the previous good release/* branch (or its last commit) that was actually uploaded to the host.
2. Re-run the Build, Test and Package Release workflow manually against that branch/commit in Gitea Actions.
3. Download the resulting release-dist artifact.
4. Upload its contents to the host manually, overwriting the current (bad) files — the same manual step used for a normal deployment.
5. Verify the live site reflects the rolled-back version.

Keeping Rollback Possible

• Do not delete release/* branches after they've been deployed; keep them (or tag them, e.g. release/1.0.0 → v1.0.0) 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 30 days, see .gitea/workflows/deploy.yml).

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

Once an automatic upload step is added (see deployment-plan.md's "Open Item"), this rollback plan should be revisited: at that point, rollback can likely be automated too (e.g. re-triggering the pipeline for a previous branch/tag and letting it redeploy automatically, instead of a manual file upload).

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