28 lines
2.1 KiB
Markdown
28 lines
2.1 KiB
Markdown
# 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
|