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

Deployment Instructions

Overview

Deployment gebeurt via Gitea Actions, opgesplitst in twee bestanden:

• .gitea/workflows/continuous_integration.yaml — build/test/lint-gate, plus de deploy-test job.
• .gitea/workflows/deploy.yaml — herbruikbare workflow die dist/ via SCP naar een omgeving uploadt.

Sinds deze stap wordt er automatisch gedeployed naar een testomgeving: een Raspberry Pi die de site serveert via nginx, bereikbaar achter een tweede Raspberry Pi met een nginx reverse proxy.

Pipeline Files

• continuous_integration.yaml — getriggerd door pull_request (build/test/lint-gate, ongeacht branch), push naar master (build/test/lint-gate + deploy-test), en handmatig via workflow_dispatch.
  • Heeft bovenaan een env:-blok met alle aanpasbare waarden op één plek: NODE_VERSION, PNPM_VERSION, ARTIFACT_NAME (dist), ARTIFACT_PATH (dist/), DEPLOY_ENVIRONMENT (test) en DEPLOY_PATH (/html/test/slpsoftware).
  • prepare → build (uploadt de artifact, naam/pad uit env.ARTIFACT_NAME/env.ARTIFACT_PATH) → test (lint + unit tests)
  • Een losse config-job zet deze env-waarden om in job-outputs (zie hieronder waarom dat nodig is).
  • deploy-test (alleen bij workflow_dispatch of een push naar master) roept deploy.yaml aan met artifact_name/environment/deploy_path afkomstig van needs.config.outputs.* (dus indirect uit het env:-blok).
• deploy.yaml — download de artifact (naam/lokaal pad = inputs.artifact_name) en upload de inhoud via appleboy/scp-action naar de opgegeven deploy_path op de host uit de meegegeven secrets.

Waarom een aparte config-job in plaats van rechtstreeks het env:-blok?

Gitea/GitHub Actions ondersteunt geen env-context in de with:-sectie waarmee een reusable workflow wordt aangeroepen (jobs.<job_id>.with) — dat werkt alléén binnen jobs.<job_id>.steps. De oplossing is een klein voorloop-job (config) dat de gewenste env-waarden via $GITHUB_OUTPUT naar job-outputs schrijft; die outputs (needs.config.outputs.*) zijn wél bruikbaar in jobs.<job_id>.with. Zo hoef je, om de artifact-naam/pad of de testdeploy-bestemming te wijzigen, alléén het env:-blok bovenaan continuous_integration.yaml aan te passen — niet de deploy-test-job zelf.

Eenmalige Setup — Gitea Secrets

Voeg deze secrets toe in Gitea: Repository → Settings → Actions → Secrets:

Secret	Waarde
PI_MAIN_HOST	Intern IP-adres van de webserver-Pi (192.168.1.103)
PI_MAIN_PORT	SSH-poort (2224)
PI_MAIN_USERNAME	SSH-gebruikersnaam (webadmin)
PI_MAIN_PASSWORD	Het SSH-wachtwoord van deze gebruiker

Deze secrets heten PI_MAIN_* (niet PI_TEST_*), omdat dezelfde Pi (Pi Main) en dezelfde inloggegevens naar verwachting ook voor toekomstige omgevingen/webhosts gebruikt worden. Mocht dat later veranderen, dan worden hiervoor alsnog omgeving-specifieke secrets geïntroduceerd.

Eenmalige Setup — Domeinnaam & DNS

• Test: test.slpsoftware.nl → moet als DNS A-record wijzen naar het publieke IP van de reverse-proxy-Pi.
• Productie (nog niet automatisch gedeployed, maar domein al bekend): slpsoftware.nl (en www.slpsoftware.nl) → zelfde reverse-proxy-Pi, zodra productie wordt opgezet.

Eenmalige Setup — nginx & SSL op de Raspberry Pi's

1. Kopieer operations/deployment/nginx/webserver-nginx.conf.example naar /etc/nginx/sites-available/ op de webserver-Pi, maak een symlink in sites-enabled/, en herlaad nginx.
2. Kopieer operations/deployment/nginx/reverse-proxy-nginx.conf.example naar /etc/nginx/sites-available/slpsoftware-test.conf op de reverse-proxy-Pi, maak een symlink in sites-enabled/, en herlaad nginx. Dit bestand gebruikt al test.slpsoftware.nl als server_name.
3. Vraag op de reverse-proxy-Pi een SSL-certificaat aan met certbot (Let's Encrypt), nadat het DNS-record klopt: sudo certbot --nginx -d test.slpsoftware.nl. Certbot regelt automatisch de HTTPS-configuratie en de HTTP→HTTPS-redirect (net zoals je gewend bent van certbot).
4. Zorg dat de map /html/test/slpsoftware bestaat op de webserver-Pi en schrijfbaar is voor de gebruiker webadmin (bijv. sudo mkdir -p /html/test/slpsoftware && sudo chown webadmin:webadmin /html/test/slpsoftware).
5. Voor later, wanneer productie wordt opgezet: zie operations/deployment/nginx/reverse-proxy-nginx-production.conf.example (domein slpsoftware.nl, certbot-commando alvast gedocumenteerd).

How to Deploy to Test

Automatisch

Merge een pull request naar master — de deploy-test job draait dan automatisch na een groene build/test-run.

Handmatig

1. In Gitea, open de repository's Actions tab.
2. Selecteer de Continuous Integration workflow.
3. Klik Run workflow, kies de gewenste branch/ref, en start.

Verifying a Deployment

1. Bevestig dat de Gitea Actions run succesvol is (alle jobs groen, inclusief deploy-test).
2. Open de testomgeving in de browser (via het adres/IP dat je bij de reverse-proxy hebt ingesteld) en controleer dat de site correct laadt (check de browserconsole op fouten, zoals in de handmatige smoke test in construction/build-and-test/integration-test-instructions.md).

Future Work

• Van wachtwoord naar SSH-key: vervang password: ${{ secrets.PI_MAIN_PASSWORD }} in deploy.yaml door key: ${{ secrets.PI_MAIN_SSH_KEY }} (een nieuwe secret met de private key-inhoud), en zet de bijbehorende public key in ~/.ssh/authorized_keys van de webadmin-gebruiker op de webserver-Pi. Verwijder daarna het wachtwoord-secret.
• Productie-omgeving: voeg een deploy-production-job toe zodra de definitieve productiehosting bekend is (zie deployment-plan.md's "Open Item"), en pas nginx/reverse-proxy-nginx-production.conf.example (domein slpsoftware.nl) toe zodra de webserver-locatie voor productie vastligt.