Deployment setup - the parts the workflow deliberately left out
Host setup checklist, real domains and ports, the database backup script the deploy workflow only ever invokes, and a rollback plan. Also drafted the FTPS switch procedure for whenever production moves off the Pi, with a note that shared hosting is likely IIS-based - that's a bigger change than swapping the transport.
This commit is contained in:
+104
@@ -0,0 +1,104 @@
|
||||
# Deployment Setup Plan
|
||||
|
||||
## Context already established (not re-asked)
|
||||
|
||||
The deployment *mechanism* was already decided and built during Construction — this stage is about
|
||||
producing the operational documentation around it, not re-deciding the method:
|
||||
|
||||
- **Method**: Gitea Actions CI/CD (`continuous_integration.yaml` → `deploy-scp.yaml`), built in U5/U6
|
||||
- **Target**: a single Raspberry Pi (`linux-arm64`), test and production on the same host, split by
|
||||
directory only (`infrastructure-design.md` § 1)
|
||||
- **Transport**: SSH/SCP, `sshpass` + plain shell steps (D-05)
|
||||
- **Release strategy**: atomic release-directory switch, 2 releases retained, `systemd --user`
|
||||
services, no sudo (`infrastructure-design.md` §§ 2–3)
|
||||
- **Rollback mechanism**: re-point the `current` symlink to the previous release and restart the
|
||||
service — already fully specified, this stage just needs to write it up as a runnable procedure
|
||||
- **Approval gate for production**: the `workflow_dispatch` + `deploy_production` flag itself is the
|
||||
approval gate (D-09) — no additional gate is needed
|
||||
|
||||
## Question 1: Include Deployment Setup?
|
||||
|
||||
Given all of the above was purpose-built in Construction specifically to be deployed, declining this
|
||||
stage would leave the pipeline built but undocumented for actual first use. Recommended: A.
|
||||
|
||||
A) Yes — produce the deployment documentation (Recommended)
|
||||
B) No — deployment is handled elsewhere or not needed
|
||||
C) Not sure — suggest an approach and I'll decide
|
||||
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]:A
|
||||
|
||||
## Question 2: Deployment Method
|
||||
|
||||
Confirms the method already built — asked per the mandatory format, not because it's genuinely open.
|
||||
|
||||
A) CI/CD pipeline (already built: Gitea Actions, this is a confirmation, not a new choice) (Recommended)
|
||||
B) Something else entirely — describe below
|
||||
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
---
|
||||
|
||||
The remaining questions are the genuinely open items — real host facts that only you know, which
|
||||
`infrastructure-design.md` deliberately left for this stage.
|
||||
|
||||
## Question 3: Real Domains
|
||||
|
||||
`HEALTH_CHECK_URL_TEST` / `_PRODUCTION` and the nginx routing (`infrastructure-design.md` § 1) need
|
||||
real hostnames to write concrete instructions. What should the deployment instructions use?
|
||||
|
||||
A) I'll provide the real domains now — describe them after [Answer]: below (e.g. `test.example.nl`,
|
||||
`example.nl`)
|
||||
B) Use placeholders (`<test-domain>`, `<production-domain>`) in the generated instructions; I'll fill
|
||||
them in myself when configuring Gitea variables
|
||||
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]:A, production: slpsoftware.nl, test: test.slpsoftware.nl
|
||||
|
||||
## Question 4: Database Backup Script
|
||||
|
||||
`deploy-scp.yaml` (U6) invokes `~/scripts/backup-slpmodularcms-db.sh` on the host but does not create
|
||||
it — it's host-side, deliberately kept out of the workflow so no DB credentials ever touch Gitea.
|
||||
Should this stage draft that script's content for you to place on the Pi?
|
||||
|
||||
A) Yes, draft a `sqlcmd`/`BACKUP DATABASE` script now, parameterized by environment (Recommended)
|
||||
B) No, I'll write the backup script myself — just document what it must accept/do (arguments,
|
||||
exit-code contract, where the workflow expects it)
|
||||
C) Not applicable yet — document it as a TODO, I'll come back to this before the first production deploy
|
||||
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]:A
|
||||
|
||||
## Question 5: FTPS Switch Documentation Depth
|
||||
|
||||
D-02 requires the *workflow* to allow adding FTPS later without restructuring (already satisfied by
|
||||
the `transport` input in `deploy-scp.yaml`) — but how much should the *documentation* say about
|
||||
actually switching to it when production eventually moves to shared hosting?
|
||||
|
||||
A) Brief note only: confirm the extension point exists in the workflow, don't draft the FTPS steps
|
||||
themselves (Recommended — shared hosting isn't happening yet, OPEN-04)
|
||||
B) Draft a full FTPS switch procedure now, even though it won't be used until shared hosting happens
|
||||
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]:B
|
||||
|
||||
## Question 6: One-Time Host Setup Checklist
|
||||
|
||||
Several one-time, host-side prerequisites were identified during Infrastructure Design and must be
|
||||
documented somewhere before the first real deploy can succeed:
|
||||
`loginctl enable-linger` (INFRA-U6-01), creating the `systemd --user` unit files, creating the
|
||||
`releases`/`shared`/`current` directory skeleton, and the Gitea secrets/variables from
|
||||
`infrastructure-design.md` § 6. Confirm this belongs in `deployment-instructions.md`?
|
||||
|
||||
A) Yes, include a full one-time host-setup checklist in the deployment instructions (Recommended)
|
||||
B) No, I'll assemble the host setup myself from the Infrastructure Design doc directly
|
||||
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]:A
|
||||
Reference in New Issue
Block a user