GitHub Actions für automatisierte Builds, Tests und Deployments

Einordnung

Überblick

GitHub Actions ist mein Standard für CI/CD, wenn Codequalität, reproduzierbare Builds und automatische Deployments wichtig sind. Workflows laufen versioniert im Repo, sind nachvollziehbar und lassen sich von kleinen Projekten bis zu komplexen Pipelines skalieren.

Schwerpunkt

Typische Workflows

In Projekten decke ich meist Linting/Typechecks, Build‑Jobs, Link‑Checks, Preview/Deployments und automatisierte Releases ab. Durch Caching (npm, Build‑Artefakte) bleiben Pipelines schnell, und Environments (Staging/Production) werden sauber getrennt.

Schwerpunkt

Sicherheit & Deployments

Secrets gehören in GitHub Environments, nicht in Code. Für Cloud‑Deployments nutze ich nach Möglichkeit OIDC statt langfristiger Access Keys. Zusätzlich helfen Branch Protection, Code Owners und Checks, um Releases kontrollierbar zu machen.

GitHub Actions bringt Stabilität in den Delivery‑Prozess: weniger manuelle Schritte, weniger „Works on my machine“ und schnellere Iteration mit klarer Qualitätssicherung.

Praxis

Was die Pipeline im Alltag verhindert

Der größte Nutzen einer Pipeline zeigt sich nicht beim Deployment, sondern davor: Fehlerhafter Stand kommt gar nicht erst in den Hauptbranch. Linting, Typprüfung, Tests und ein vollständiger Build laufen vor jedem Merge, und ein Fehlschlag ist in Minuten sichtbar statt beim Kunden.

Gerade bei kleinen Teams ersetzt das den Kontrollschritt, für den sonst niemand Zeit hat. Niemand muss daran denken, die Tests zu starten, und niemand muss sich darauf verlassen, dass jemand anders es getan hat.

Für den Weg in die Produktion lässt sich beides kombinieren: automatisches Ausrollen nach bestandenen Prüfungen für unkritische Systeme, ein manueller Freigabeschritt für alles, was direkt am Umsatz hängt. Der Ablauf bleibt in beiden Fällen derselbe und ist damit nachvollziehbar.

Aus einem Projekt

Die Pipeline hinter dieser Website

Der Workflow dieser Website führt bei jedem Pull Request nacheinander ESLint, die TypeScript-Prüfung, die Unit-Tests mit Vitest und einen vollständigen Nuxt-Build aus. Danach läuft ein eigenes Skript über das gebaute HTML aller Seiten und prüft, ob jede Seite genau eine H1 hat, ob der Organisationsknoten im JSON-LD eindeutig ist und ob keine doppelten Profile oder Kontaktpunkte entstanden sind.

Ergänzend hält Renovate die Abhängigkeiten aktuell, und ein Skript meldet geänderte Adressen per IndexNow an die Suchmaschinen. Die Läufe laufen auf einem eigenen Runner der Organisation, damit Build-Zeiten kalkulierbar bleiben. Dieselbe Idee lässt sich auf jedes Projekt übertragen: Was im Betrieb nicht kaputtgehen darf, gehört als Prüfung in die Pipeline.