diff --git a/.gitea/workflows/continuous_integration.yaml b/.gitea/workflows/continuous_integration.yaml index df41b8b..d8330b0 100644 --- a/.gitea/workflows/continuous_integration.yaml +++ b/.gitea/workflows/continuous_integration.yaml @@ -170,11 +170,17 @@ jobs: - name: Build env: - # Zelfde Umami/Sentry-variabelen als de testbuild hierboven, want er - # is (nog) geen apart productie-Umami-website-ID of -Sentry-project - # gekozen. Splits deze pas op zodra dat nodig blijkt. + # Umami-website-ID's zijn NIET gedeeld tussen omgevingen: elke Umami + # "website"-entry (test.slpsoftware.nl vs slpsoftware.nl) heeft een + # eigen ID, anders komt productieverkeer in de teststatistieken + # terecht (of andersom). Vereist dus een eigen Umami-website + + # Gitea-variable VITE_UMAMI_WEBSITE_ID_PRODUCTION — zie umami-setup.md. VITE_UMAMI_SCRIPT_URL: ${{ vars.VITE_UMAMI_SCRIPT_URL }} - VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID }} + VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_PRODUCTION }} + # VITE_SENTRY_DSN wordt wél gedeeld met de testbuild: één Sentry- + # project voor beide omgevingen, VITE_APP_ENV hieronder tagt de + # events al als 'test' vs 'production'. Splits dit pas op als je + # ooit aparte Sentry-projecten per omgeving wilt. VITE_SENTRY_DSN: ${{ vars.VITE_SENTRY_DSN }} VITE_APP_ENV: ${{ env.DEPLOY_ENVIRONMENT_PRODUCTION }} run: pnpm run build diff --git a/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md b/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md index d606010..dec63d7 100644 --- a/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md +++ b/aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md @@ -74,7 +74,10 @@ Productie deployt **nooit** automatisch bij een push naar `master` — alleen vi 4. Vink **`deploy_production`** aan voordat je de run start. 5. Dit triggert naast de gebruikelijke `build`/`test`/`deploy-test` ook `build-production` en `deploy-production`. -Vereist eenmalig vooraf: de Gitea-variable `DEPLOY_PATH_PRODUCTION` (zie boven) en de productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — Domeinnaam & DNS"). +Vereist eenmalig vooraf: +- De Gitea-variable `DEPLOY_PATH_PRODUCTION` (zie boven). +- De Gitea-variable `VITE_UMAMI_WEBSITE_ID_PRODUCTION` (zie `umami-setup.md` stap 4/5) — zónder deze wordt productieverkeer per ongeluk meegeteld bij de teststatistieken. +- De productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — Domeinnaam & DNS"). ## Verifying a Deployment 1. Bevestig dat de Gitea Actions run succesvol is (alle relevante jobs groen — `deploy-test` altijd, `build-production`/`deploy-production` alleen als je `deploy_production` had aangevinkt). diff --git a/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md b/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md index e8df008..93ebab3 100644 --- a/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md +++ b/aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md @@ -185,28 +185,36 @@ uit stap 0.3 is hiervoor al gezet, dus deze service blijft ook draaien zonder da wijzigen na eerste login**). ## 4. Website registreren in Umami en het website-ID ophalen +Maak een **aparte Umami-website-entry per omgeving** aan — test en productie zijn +verschillende domeinen en horen dus niet in dezelfde statistieken te belanden: 1. Log in op `https://analytics.slpsoftware.nl` en wijzig direct het standaardwachtwoord. -2. Ga naar **Settings → Websites → Add website** en vul in: - - Name: `SLP Software` (of naar keuze) - - Domain: het domein van de daadwerkelijke website (bv. `slpsoftware.nl` of - `test.slpsoftware.nl`, afhankelijk van welke omgeving je eerst wilt meten) -3. Na het opslaan toont Umami een **Website ID** (een UUID) — dit heb je nodig voor de - volgende stap. +2. Ga naar **Settings → Websites → Add website** en maak een entry voor de testomgeving: + - Name: `SLP Software (test)` (of naar keuze) + - Domain: `test.slpsoftware.nl` +3. Na het opslaan toont Umami een **Website ID** (een UUID) voor deze entry — nodig voor + `VITE_UMAMI_WEBSITE_ID` in de volgende stap. +4. Herhaal stap 2-3 voor productie zodra die omgeving wordt opgezet: een tweede website- + entry met Domain `slpsoftware.nl`, met een eigen Website ID voor + `VITE_UMAMI_WEBSITE_ID_PRODUCTION`. ## 5. Tracking script koppelen aan de website (build-configuratie) De React-app (`src/components/UmamiAnalytics.tsx`) injecteert het Umami tracking-script -automatisch, mits de volgende twee build-time variabelen zijn ingesteld — beide zijn -**geen secrets** (client-side zichtbaar), dus als Gitea Actions **repository variables** +automatisch, mits de volgende build-time variabelen zijn ingesteld — geen van deze zijn +**secrets** (client-side zichtbaar), dus als Gitea Actions **repository variables** (niet secrets), net als `VITE_SENTRY_DSN`: | Variabele | Waarde | |---|---| -| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` | -| `VITE_UMAMI_WEBSITE_ID` | het Website ID uit stap 4 | +| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` (gedeeld tussen test en productie — zelfde Umami-instance/endpoint voor beide) | +| `VITE_UMAMI_WEBSITE_ID` | het Website ID van de **test**-website-entry uit stap 4 | +| `VITE_UMAMI_WEBSITE_ID_PRODUCTION` | het Website ID van de **productie**-website-entry uit stap 4 (pas nodig vóór de eerste `deploy_production`-run) | -Stel deze in via **Gitea → Repository Settings → Actions → Variables**. Zodra beide -bestaan, pakt de eerstvolgende build ze automatisch op; zonder deze variabelen slaat de -app het inladen van het script gewoon over (geen crash, geen tracking). +Stel deze in via **Gitea → Repository Settings → Actions → Variables**. Zodra ze bestaan, +pakt de eerstvolgende build ze automatisch op; zonder deze variabelen slaat de app het +inladen van het script gewoon over (geen crash, geen tracking). Let op: +`continuous_integration.yaml`'s `build`-job (test) leest `VITE_UMAMI_WEBSITE_ID`, de +`build-production`-job leest `VITE_UMAMI_WEBSITE_ID_PRODUCTION` — verwissel deze niet, +anders komt productieverkeer in de teststatistieken terecht (of andersom). **Lokaal (`pnpm dev`)**: het tracking-script wordt hier bewust nooit geladen (zie `UmamiAnalytics.tsx`), zodat lokaal testen de bezoekersstatistieken niet vervuilt. Wil je @@ -220,8 +228,9 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie - [ ] Systemd user-service instellen (onder de `umami`-user) voor auto-start na reboot. - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi. - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login. -- [ ] Website aanmaken in Umami en het Website ID overnemen. +- [ ] Website aanmaken in Umami voor de testomgeving en het Website ID overnemen. - [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID` als Gitea repository variables instellen. +- [ ] Zodra productie wordt opgezet: aparte website aanmaken in Umami voor `slpsoftware.nl` en het Website ID als `VITE_UMAMI_WEBSITE_ID_PRODUCTION` instellen (zie stap 4/5 hierboven — vereist vóór de eerste `deploy_production`-run). ## Vervolgstappen voor toekomstige self-hosted diensten Dit dedicated-user-patroon (stap 0 hierboven) is bewust generiek gehouden zodat het