SluijsensandClaude Sonnet 5
cfb06b28b6
Implements Unit 2 "Offerings" (backend module, admin CRUD UI with drag-and-drop reordering, public GET /api/v1/offerings endpoint) and executes the feature's D-15 CI/CD cutover, switching the deploy pipeline's build/publish target from SlpModularCms.Api to SlpModularCms.Api.SlpSoftware. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
2.9 KiB
Deployment Setup — slpsoftware-api (D-15 Cutover)
This feature does not own a separate deployment pipeline. Per D-7, its Operations phase extends
the pipeline owned by gitea-deployment-workflow rather than duplicating it. Full instructions
(host setup, systemd units, TLS, Gitea variables, database backup, rollback) remain at:
aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.mdaidlc-docs/features/gitea-deployment-workflow/operations/deployment/rollback-plan.md
What This Feature Changed
Per D-15 (cutover, not side-by-side): SlpModularCms.Api.SlpSoftware replaces SlpModularCms.Api
as the artifact built, tested, and deployed to test.slpsoftware.nl / slpsoftware.nl.
| File | Change |
|---|---|
.gitea/workflows/continuous_integration.yaml |
publish-test/publish-production's "Build admin frontend" and "Publish" steps retargeted from src/SlpModularCms.Api to src/SlpModularCms.Api.SlpSoftware (6 lines). Everything else — the six CI gates, deploy-scp.yaml calls, Gitea variables/secrets, SlpModularCms.Api.Tests (Unit 1's own regression suite, scoped to Api per NFR-CS-01) — is unchanged. |
deploy-scp.yaml |
No change. It never hardcodes an entry-point .dll name; it uploads whatever the artifact contains and restarts a service_name input string. |
gitea-deployment-workflow/operations/deployment/deployment-instructions.md § 1.6 |
systemd unit ExecStart documentation updated to SlpModularCms.Api.SlpSoftware.dll, with an explicit note that this is a manual, host-side edit for already-existing units — this session cannot reach the Pi to apply it. |
rollback-plan.md |
No change. Operates on the release-directory/symlink level, not a specific .dll name. |
| nginx (proxy Pi) | No change (D-6) — the proxy forwards to a port, not a named executable. |
| Database, Gitea Actions variables/secrets | No change — same customer, same domain, same paths, same service names. |
Action Required From You
The Pi's slpsoftware-test.service/slpsoftware-production.service unit files (created during the
original gitea-deployment-workflow setup) still point at SlpModularCms.Api.dll. Edit both by
hand on the Pi (see the updated § 1.6 above for the exact ExecStart line and login-shell caveat),
then systemctl --user daemon-reload and restart both services — the CI pipeline deploys the new
SlpModularCms.Api.SlpSoftware build correctly starting with the next run regardless, but the
existing systemd unit will keep launching the old SlpModularCms.Api.dll from that release
directory until you make this edit.
SlpModularCms.Api itself is not removed from the repository or decommissioned (D-8) — it remains
the local development host, same role as Api.Slave today. Only its production/test deployment for
the slpsoftware customer instance is retired, per this cutover.