Machs Dir Selbst Solar

Drei Apps, eine Datenbasis — eingebettet in eine Lernplattform

Die Plattform besteht aus drei Angular-21-Apps, die jeweils einen klar abgegrenzten Nutzerkreis bedienen und sich substantielle Teile der Domänenlogik teilen. Sie sind die Werkzeugschicht innerhalb einer größeren Content-Plattform — DIY-Kunden konsumieren in der Regel erst die Lerninhalte (Komponentenkunde, Auslegungsregeln, gesetzliche Rahmenbedingungen, Schritt-für-Schritt-Videos zur Eigenmontage), bevor sie überhaupt anfangen, ihre Anlage im Builder zu modellieren. Das verschiebt die Kundenerwartung: wer hier ankommt, will nicht beraten werden, sondern Werkzeuge.

Builder — die kundenseitige Anfrage-App. Ein interessierter Endkunde gibt seine Adresse ein, modelliert seine Dachflächen direkt im Karten-Editor (Polygon-Zeichen über Satellitenbild), legt Modulflächen pro Segment fest und wählt grob, was er anfragen möchte — Module, Wechselrichter, Speicher. Heraus kommt eine grobe Preisspanne und eine Stückliste der Komponenten und Werkzeuge, die er für ein DIY-Vorgehen brauchen würde. Wer aus den Videos und Anleitungen schon weiß, was eine MC4-Verbindung ist und wie ein String-Layout funktioniert, kommt hier ohne weitere Hilfe durch. Damit hat Solario eine in sich konsistente, realistische Anfrage — und der Kunde eine ehrliche Erwartung.

Configurator — die Detail-Angebots-App, in die der Kunde nach Bearbeitung durch Solario einsteigt. Hier liegt das ausgearbeitete Angebot: konkrete Modulreihen, konkreter Wechselrichter, optionale Komponenten mit Aufpreis, detaillierte Statistiken zur Wirtschaftlichkeit. Der Kunde kann Material wechseln (z. B. Premium-Modul statt Basis), sieht die Auswirkungen sofort an Preis, Ertrag und Payback, und kann das Angebot direkt annehmen — ohne Termin, ohne Telefonat.

Planner — das interne Tool für die Solario-Planer. Es ist auf Automatisierung ausgelegt: aus der Builder-Anfrage erzeugt der Planner einen Vorschlag für das Detail-Angebot, fügt fehlende technische Details aus den Stammdaten hinzu (welche Verkabelung passt, welcher Wechselrichter zu welchem String-Layout, welche Zuschüsse gelten regional), und der Planer prüft nur noch und stößt es ab. Ein einzelner Planer bedient damit ein Anfragevolumen, das im klassischen Vertrieb mehrere Berater binden würde. Stammdatenpflege (Hersteller, Module, Wechselrichter, Elektrobetriebe, Zuschüsse, Strompreis-Annahmen) findet auch hier statt.

Geteilt werden alle drei über libs/economics (Cashflow-Berechnung, Annuität, Strompreis-Eskalation, Payback) und libs/utils. nx affected baut und testet nur das, was eine Änderung wirklich berührt — auf vier Targets pro App (lint, test, build, e2e) ist das der Unterschied zwischen einer angenehmen und einer unzumutbaren CI.

export class EconomicsUtils {
  static DEFAULT_YEARS_FOR_CALCULATION = 25;
  static ELECTRICITY_PRICE_YEARLY_INCREASE_PERCENTAGE = 0.04;

  static calculate_payback_period(profit_list_euro: number[], total_cost_euro: number): number {
    let years = 0;
    let cumulative = 0;
    while (total_cost_euro > cumulative && years < profit_list_euro.length) {
      cumulative += profit_list_euro[years];
      years += 1;
    }
    const remaining = cumulative - total_cost_euro;
    if (remaining > 0 && years > 0) {
      return years - (remaining / profit_list_euro[years - 1]);
    }
    return years;
  }
}

Was die Preview-Infrastruktur wirklich tut

Das herausragende Stück Infrastruktur in diesem Projekt ist nicht eine einzelne App, sondern die preview.yml. Sie macht aus jedem Pull Request eine vollständige, isolierte Test-Umgebung: eine eigene Postgres-Datenbank, drei eigene Container, drei eigene URLs.

Im Detail durchläuft der Workflow für jedes PR diese Schritte:

1. Supabase-Branch sicherstellen. Der Workflow ruft die Supabase Management API, sucht die zur PR-Branch passende Preview-Branch oder erstellt sie. Er pollt bis zu 15 Minuten auf ACTIVE_HEALTHY und liest danach Branch-spezifische Credentials aus (DB-Pass, Anon-Key, JWT-Secret).
2. Edge-Function-Secrets synchronisieren. Preview-Branches erben Funktionen aus dem Parent-Projekt, aber nicht deren Secrets. Ohne diesen Schritt würde Deno.env.get(...) in jeder Function undefined zurückgeben.
3. Dashboard-only-Schemas bootstrappen. Das supabase_functions-Schema und der http_request-Trigger existieren in Production, weil sie dort einmal per Dashboard-Klick angelegt wurden. Auf einem Branch fehlen sie — der Workflow installiert einen No-op-Stub mit identischer Signatur, damit Migrations-Trigger nicht fehlschlagen.
4. Vault-JWT-Secret setzen. Custom-JWT-Signing-Funktionen lesen app.jwt_secret aus dem Postgres Vault. Auf einer frischen Branch fehlt der Eintrag — der Workflow legt ihn mit dem Branch-eigenen JWT-Secret an, sodass PostgREST/GoTrue die selbst-ausgestellten Tokens verifizieren können.
5. Migrationen und Edge-Functions ausrollen. supabase db push --include-all und supabase functions deploy synchronisieren die Branch mit dem PR-HEAD. Bei opened oder reopened läuft zusätzlich seed.sql, bei synchronize nicht (der Seed ist nicht idempotent).
6. Affected-Apps bauen und deployen. nx show projects --affected --type=app liefert die Liste der zu deployenden Apps. Für jede gebaut wird ein Docker-Image mit PR-spezifischen Build-Args, ins GHCR gepusht und Coolifys /api/v1/deploy mit dem neuen Tag getriggert.
7. PR-Kommentar aktualisieren. Ein Sticky-Comment listet die drei Preview-URLs. Bei opened geht parallel eine Nextcloud-Talk-Nachricht raus — Team weiß, dass der Preview steht.
8. Teardown bei closed. Supabase-Branch löschen, drei Coolify-Previews per DELETE /api/v1/applications/<uuid>/previews/<pr> abräumen.

Tiefe Einblicke

- name: Build, push to GHCR, trigger Coolify deploy
  env:
    SUPABASE_URL: ${{ steps.supabase.outputs.url }}
    SUPABASE_ANON_KEY: ${{ steps.supabase.outputs.anon }}
    PLANNER_URL: ${{ steps.urls.outputs.planner }}
  run: |
    image="ghcr.io/$repo/${name}:pr-${PR_NUMBER}"
    docker buildx build \
      --build-arg "SUPABASE_URL=${SUPABASE_URL}" \
      --build-arg "SUPABASE_ANON_KEY=${SUPABASE_ANON_KEY}" \
      --build-arg "PLANNER_URL=${PLANNER_URL}" \
      --tag "$image" --push .

    curl -sS -X POST -H "Authorization: Bearer $COOLIFY_TOKEN" \
      "$COOLIFY_URL/api/v1/deploy?uuid=$uuid&pr=$PR_NUMBER&docker_tag=pr-${PR_NUMBER}"

deadline=$(( $(date +%s) + 900 ))  # 15m
while : ; do
  branch=$(curl -sS -H "Authorization: Bearer $TOKEN" \
            "https://api.supabase.com/v1/branches/$branch_id")
  status=$(echo "$branch" | jq -r '.status // empty')
  case "$status" in
    ACTIVE_HEALTHY|FUNCTIONS_DEPLOYED|MIGRATIONS_PASSED)
      break ;;
    MIGRATIONS_FAILED|FUNCTIONS_FAILED)
      echo "::error::Preview branch failure: $status"
      exit 1 ;;
  esac
  [[ $(date +%s) -ge $deadline ]] && { echo "::error::timeout"; exit 1; }
  sleep 10
done

CREATE SCHEMA IF NOT EXISTS supabase_functions;
DO $bootstrap$
BEGIN
  IF NOT EXISTS (
    SELECT 1 FROM pg_proc p
      JOIN pg_namespace n ON p.pronamespace = n.oid
    WHERE n.nspname = 'supabase_functions' AND p.proname = 'http_request'
  ) THEN
    EXECUTE $body$
      CREATE FUNCTION supabase_functions.http_request() RETURNS trigger
      LANGUAGE plpgsql AS $fn$ BEGIN RETURN NEW; END $fn$
    $body$;
  END IF;
END $bootstrap$;

- name: Compute affected apps
  id: affected
  run: |
    if [[ "${{ github.event.action }}" != "synchronize" ]]; then
      # Bei opened/reopened: alle drei Apps bauen
      { echo "builder=true"; echo "planner=true"; echo "configurator=true"; } \
        >> "$GITHUB_OUTPUT"
      exit 0
    fi
    affected=$(pnpm exec nx show projects --affected --type=app)
    for app in builder planner configurator; do
      if echo "$affected" | grep -qx "$app"; then
        echo "${app}=true" >> "$GITHUB_OUTPUT"
      else
        echo "${app}=false" >> "$GITHUB_OUTPUT"
      fi
    done

# Suspenders: is_default != true garantiert, dass wir nie die Prod-Branch wählen.
branch=$(echo "$branches" | jq -c \
           --arg g "$PR_BRANCH" \
           '[.[] | select(.git_branch == $g and .is_default != true)] | .[0] // empty')
if [[ -z "$branch" ]]; then
  echo "No Supabase preview branch for $PR_BRANCH — nothing to delete"
  exit 0
fi
branch_id=$(echo "$branch" | jq -r '.id')
curl -sS --fail -X DELETE \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  "https://api.supabase.com/v1/branches/$branch_id" > /dev/null

Was sich nach einem Jahr Betrieb gezeigt hat

Drei Beobachtungen, die wir am Tag 1 nicht so klar gesehen hätten:

Die Preview-Pipeline ist Onboarding-Werkzeug. Neue Entwickler in das Setup zu heben dauert ungefähr null Minuten — sie öffnen ein PR, kriegen drei URLs, klicken sich rein. Die wahre Stärke der Pipeline ist nicht Code-Review, sondern dass externe Beteiligte (Solario-Vertrieb, Designer) ohne lokales Setup an einer realen Version arbeiten können.

Edge-Function-Secrets sind das stille Stolperthema. Auf der Hälfte der Probleme, die wir bei Previews gesehen haben, war der Auslöser ein neues Secret in apps/supabase/functions/.env, das nicht in der Preview-Sync-Liste landete. Wir haben das mittlerweile als CODEOWNERS-Regel: wer .env im Functions-Ordner ändert, kriegt automatisch den Preview-Workflow zur Review.

Build-Args eliminieren eine ganze Klasse von „funktioniert lokal aber nicht in Preview”-Bugs. In der ersten Version haben wir Werte zur Build-Zeit aus Env-Vars in environment.preview.ts substituiert (ein apply-preview-env.sh-Skript, das sed über Platzhalter laufen lässt). Das funktioniert, ist aber fragil: jedes neue Env muss in zwei Listen synchron gehalten werden. Build-Args sind ein einziger Ort.