SlpSoftware/aidlc-docs/features/react-frontend/operations/deployment/deployment-plan.md

Deployment Plan

Chosen Method

Gitea Actions, opgesplitst in twee workflow-bestanden:

• .gitea/workflows/continuous_integration.yaml — draait de build/test/lint-gate, automatisch bij elke pull request (ongeacht branch) en bij elke push/merge naar master, of handmatig via workflow_dispatch. De deploy-test-job zelf blijft daarnaast ook beperkt tot master/workflow_dispatch via een eigen if-check.
• .gitea/workflows/deploy.yaml — een herbruikbare (workflow_call) job die de dist/ build via SCP (over SSH) uploadt naar de webroot van een omgeving.

Sinds deze stap is er een echte, geautomatiseerde upload naar een testomgeving: een Raspberry Pi die de statische site serveert via nginx, achter een tweede Raspberry Pi die als nginx reverse proxy fungeert.

How It Works

1. Bij elke pull request draait automatisch de build/test/lint-gate (prepare → build → test), zodat merge requests direct gevalideerd worden.
2. Zodra een pull request naar master gemerged wordt (of de workflow handmatig via workflow_dispatch gestart wordt), draait aanvullend de deploy-test job.
3. deploy-test roept de herbruikbare deploy.yaml workflow aan met artifact_name/environment/deploy_path, en geeft via secrets: inherit de Pi-inloggegevens door. Deze drie waarden (samen met de artifact-naam/pad die de build-job gebruikt) staan als variabelen in het env:-blok bovenaan continuous_integration.yaml (ARTIFACT_NAME, ARTIFACT_PATH, DEPLOY_ENVIRONMENT, DEPLOY_PATH), en worden via een kleine config-job als job-outputs doorgegeven aan deploy-test (nodig omdat de env-context zelf niet werkt in de with:-sectie van een reusable-workflow-aanroep). DEPLOY_PATH zelf is geen hardcoded waarde meer, maar wordt gelezen uit de Gitea repository variable DEPLOY_PATH_TEST (Repository → Settings → Actions → Variables), zodat het uploadpad aangepast kan worden zonder de workflow te wijzigen — zie deployment-instructions.md.
4. deploy.yaml downloadt de artifact en uploadt de inhoud via een scp-commando (met sshpass voor het wachtwoord) in een gewone shell-stap naar de webserver-Pi op het interne netwerk (192.168.1.103, poort 2224). Dit vervangt de eerdere appleboy/scp-action (Docker-container-action), die faalde op de zelf-gehoste Podman-runner (failed to attach to container: unable to upgrade to tcp, received 409).
5. nginx op de webserver-Pi serveert de bestanden vanaf /mnt/storage1/www/html/test/slpsoftware; de reverse-proxy-Pi stuurt binnenkomend verkeer door naar deze webserver-Pi. Voorbeeldconfiguraties staan in operations/deployment/nginx/ en zijn de daadwerkelijk in gebruik zijnde configuraties (niet langer illustratieve concepten).
6. De reverse-proxy-Pi is ook verantwoordelijk voor SSL: certificaten worden net als voorheen aangevraagd via certbot (Let's Encrypt) en HTTP-verkeer wordt doorverwezen naar HTTPS.

Environments

• Test (nieuw, geautomatiseerd): zoals hierboven beschreven — de enige omgeving die op dit moment daadwerkelijk automatisch gedeployed wordt. Domeinnaam: test.slpsoftware.nl (SSL via certbot op de reverse-proxy-Pi).
• Productie: nog niet geautomatiseerd. Zodra de definitieve productiehosting bekend is, kan een vergelijkbare deploy-production-job worden toegevoegd die deploy.yaml aanroept met environment: production en de productie-secrets/pad. Domeinnaam ligt al vast: slpsoftware.nl (SSL eveneens via certbot). Er is (nog) geen productie-nginx-voorbeeldconfiguratie; deze is op verzoek verwijderd totdat er een goed-werkende, foutloze versie is, en kan later opnieuw opgebouwd worden naar analogie van de testomgeving-configuraties.

Automation Level

Volledig geautomatiseerd voor de testomgeving: build, test, lint én upload naar de test-Pi gebeuren zonder handmatige tussenstap, zodra er gemerged wordt naar master (of handmatig getriggerd wordt). Alleen productie is nog niet geautomatiseerd.

Rollback Strategy

Zie rollback-plan.md — voor de testomgeving kan een eerdere commit/branch opnieuw gebouwd en geüpload worden door de workflow opnieuw te triggeren.

Secrets & Configuration

Voor de testomgeving zijn de volgende Gitea Actions Secrets (repository-niveau) vereist:

• PI_MAIN_HOST — 192.168.1.103 (intern IP van de webserver-Pi)
• PI_MAIN_PORT — 2224
• PI_MAIN_USERNAME — webadmin
• PI_MAIN_PASSWORD — het SSH-wachtwoord van deze gebruiker

Deze secrets heten bewust PI_MAIN_* in plaats van PI_TEST_*: alle webhosts gebruiken op dit moment dezelfde inloggegevens (dezelfde Pi), dus de naam is niet omgeving-specifiek. Mocht dat in de toekomst veranderen, dan worden alsnog omgeving-specifieke secrets geïntroduceerd.

Dit is bewust wachtwoord-authenticatie (voor nu, zoals gekozen), zodat de testomgeving snel werkend is. Zie "Future Work" in deployment-instructions.md voor de overstap naar SSH-key-authenticatie.

Open Item — Productie-deploy Nog Niet Geautomatiseerd

Zodra de definitieve productiehosting bekend is (en of dit dezelfde soort Raspberry Pi-opstelling is, of een externe hostingpartij), voeg een deploy-production-job toe aan continuous_integration.yaml die deploy.yaml aanroept met environment: production. Zolang het dezelfde webhost (Pi Main) blijft, kunnen de bestaande PI_MAIN_* secrets hergebruikt worden; pas dit pas aan naar omgeving-specifieke secrets als productie daadwerkelijk op een andere host komt. Voor het uploadpad hoort een eigen Gitea variable (DEPLOY_PATH_PRODUCTION), analoog aan DEPLOY_PATH_TEST — zie deployment-instructions.md. Domeinnaam (slpsoftware.nl) en SSL-aanpak (certbot/Let's Encrypt op de reverse-proxy-Pi) liggen al vast; er is bewust (nog) geen productie-nginx-voorbeeldconfiguratie, deze wordt later opnieuw opgebouwd zodra er een goed-werkende, foutloze versie is.

Verified Build Prerequisite

Dit plan bouwt voort op de Build and Test-stage (construction/build-and-test/build-and-test-summary.md): pnpm run build produceert een statische dist/-bundel zonder server-side vereisten, geschikt om direct door nginx geserveerd te worden.