# 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