Sluijsens
cf80f827ae
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.
4.7 KiB
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 --userservices, no sudo (infrastructure-design.md§§ 2–3) - Rollback mechanism: re-point the
currentsymlink 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_productionflag 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)
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)
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)
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)
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)