SluijsensandClaude Sonnet 5
fa389e42ee
Continuous Integration / config (pull_request) Successful in 11s
Continuous Integration / changes (pull_request) Successful in 21s
Continuous Integration / backend-build (pull_request) Successful in 6m10s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m59s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m27s
Continuous Integration / backend-test (pull_request) Failing after 7m48s
Continuous Integration / frontend-build (pull_request) Successful in 2m5s
Continuous Integration / frontend-test (pull_request) Successful in 4m24s
Continuous Integration / frontend-lint (pull_request) Successful in 2m0s
Continuous Integration / publish-test (pull_request) Skipped
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-test (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Unit 1 of the slpsoftware-api feature (FR-1/FR-2/FR-3): a new Client project in the Clients solution folder, intended to eventually become the deployed API for test.slpsoftware.nl/slpsoftware.nl, hosting the same four modules as SlpModularCms.Api plus a future Offerings module. - Extracts SlpModularCms.Api/Program.cs's hosting-pipeline composition into SlpModularCms.Core.Hosting.CmsHost (ConfigureServices/ConfigurePipeline), shared by both Client projects so they cannot drift apart - Moves StaticContentExtensions.cs + WebsitePlaceholder.html from Api into Core, since CmsHost cannot live in Api but Core cannot depend on Api - Adds SlpModularCms.Api.SlpSoftware with its own isolated local dev database and dev ports (5286/7223, distinct from Api's and Api.Slave's) - Adds SlpModularCms.Api.Tests with WebApplicationFactory-based pipeline regression tests (security headers, health check, SPA fallback, rate limiting), scoped to Api per NFR Design - Adds a frontend dev:slpsoftware pnpm script mirroring dev:slave - Fixes GlobalExceptionHandler logging routine 401s (e.g. an expired/missing refresh token) as unhandled errors -- pre-existing, unrelated to this feature's own scope, found while testing the new instance Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
31 lines
3.2 KiB
Markdown
31 lines
3.2 KiB
Markdown
# Infrastructure Design Plan — Unit: SlpSoftware Client Setup
|
|
|
|
Voordat ik vragen stelde, heb ik `aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md` (de bestaande, gedetailleerde deploy-documentatie van de feature die de huidige pipeline bezit) volledig gelezen. Dat geeft keihard bewijs voor bijna elke categorie hieronder — vandaar dat er maar één echte vraag overblijft.
|
|
|
|
## Al opgelost via bestaand bewijs (geen vraag nodig)
|
|
|
|
- **Deployment Environment / Compute**: één Raspberry Pi ("pi-main"), test en productie gescheiden per directory/systemd-unit/poort (5100/5101). Een aparte proxy-Pi regelt TLS-terminatie. Dit verandert niet door deze feature — D-15 is een **cutover**, geen nieuwe, aparte deploy-slot. Zodra de Operations-fase de pipeline omzet, draait `Api.SlpSoftware` **op precies dezelfde plek** als `Api` nu draait: zelfde Pi, zelfde systemd-unitnamen (`slpsoftware-test.service`/`slpsoftware-production.service`), zelfde poorten, zelfde domeinen. Het enige wat verandert is de ExecStart-regel (`SlpModularCms.Api.dll` → `SlpModularCms.Api.SlpSoftware.dll`) en het CI-publish-artefact — en dat is expliciet Operations-werk (D-7), niet iets wat deze Construction-stage of deze unit's Code Generation al hoeft aan te passen.
|
|
- **Networking**: geen nginx-wijziging nodig (al vastgelegd als D-6/NFR-1) — de bestaande proxy-Pi-configuratie blijft ongewijzigd, hij proxied gewoon naar dezelfde poort, ongeacht welke `.dll` daar luistert.
|
|
- **Storage (productie/test)**: zelfde MariaDB-instantie op pi-main, zelfde databasenamen (`SlpSoftwareTest`/`SlpSoftwareProduction`) — logisch gevolg van "cutover, geen nieuwe aparte app".
|
|
- **Monitoring**: zelfde Sentry-project/DSN, onderscheiden via de bestaande `Observability__Environment`-tag — geen wijziging nodig.
|
|
- **Shared Infrastructure/multi-tenancy**: N/A — single-tenant deployment, geen wijziging.
|
|
- **Geen wijzigingen aan `.gitea/workflows/*.yaml` of Gitea Actions-variabelen in deze stage** — dat is expliciet Operations-fase-werk (D-7/D-15). Deze stage documenteert alleen de doelvorm, zodat Code Generation niets bouwt wat daar niet in past.
|
|
|
|
## Uitvoeringschecklist
|
|
|
|
- [x] Stap A — `infrastructure-design.md`: bovenstaande bevindingen + antwoord op Vraag 1 vastleggen
|
|
- [x] Stap B — `deployment-architecture.md`: doelarchitectuur voor `Api.SlpSoftware` na de toekomstige cutover (referentie, geen wijziging nu)
|
|
|
|
---
|
|
|
|
## Vragen
|
|
|
|
### Vraag 1 — Lokale ontwikkeldatabase voor `Api.SlpSoftware`
|
|
Voor productie/test is de databasekeuze al duidelijk (hierboven). Voor **lokale ontwikkeling** (jouw eigen machine) is dat nog niet vastgelegd: moet `Api.SlpSoftware` lokaal dezelfde database gebruiken als `Api` vandaag, of een eigen, aparte lokale database?
|
|
|
|
A) Dezelfde lokale database als `Api` — handig als je makkelijk wilt wisselen tussen beide projecten met dezelfde testdata; risico op onderlinge beïnvloeding tijdens ontwikkeling van de Offerings-module (Unit 2)
|
|
B) Eigen, aparte lokale database voor `Api.SlpSoftware` — geïsoleerde ontwikkelomgeving, geen kans dat het testen van de Offerings-module `Api`'s lokale data raakt; wel een aparte lokale database aanmaken
|
|
X) Anders (beschrijf hieronder na de [Answer]:-tag)
|
|
|
|
[Answer]:B
|