SLP_Software/SlpSoftware
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add automated test-environment deploy via SCP with nginx reverse proxy, domain names and SSL (certbot) setup

Browse Source 
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
Sluijsens
2026-07-24 15:52:16 +02:00
co-authored by Junie
parent a437bad95b
commit 1ffe884eba
9 changed files with 273 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/react-frontend/operations/deployment/rollback-plan.md
+9 -10
View File
@@ -1,24 +1,23 @@
# 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.
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
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.
## 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 naar `/html/test/slpsoftware` op de webserver-Pi, 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 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`).
- 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
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).
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