Ein Projekt läuft lokal, aber nach dem Merge ist plötzlich etwas kaputt: ein vergessener Test, ein fehlendes Build-Artefakt oder eine Umgebungsvariable stimmt nicht. Genau hier hilft GitHub Actions: Wiederkehrende Aufgaben werden automatisch ausgeführt, sobald sich Code ändert. Das spart Zeit, reduziert menschliche Fehler und macht Änderungen nachvollziehbarer.
Dieser Artikel erklärt die wichtigsten Konzepte hinter Actions, zeigt typische Workflow-Muster und führt zu einem Setup, das in vielen Webprojekten funktioniert (z. B. Node.js, PHP oder Python). Begriffe werden dabei bewusst einfach gehalten.
Was GitHub Actions im Alltag löst
Actions ist GitHubs eingebauter Automatisierungsdienst: Er reagiert auf Ereignisse im Repository und startet dann definierte Schritte. Häufige Ziele sind:
- Tests bei jedem Pull Request ausführen
- Code-Qualität prüfen (Formatter/Linter)
- Build erstellen (z. B. Frontend-Bundle)
- Artefakte bereitstellen (z. B. ZIP/Build-Ordner)
- Deployment starten (z. B. auf einen Server oder in die Cloud)
Das Ganze läuft nach klaren Regeln: Was genau passieren soll, steht in einer YAML-Datei im Repo. Dadurch ist Automatisierung Teil des Codes und wird mit versioniert.
CI und CD kurz erklärt
Continuous Integration (CI) bedeutet: Änderungen werden regelmäßig integriert, und automatisierte Checks (Tests, Linting, Build) laufen möglichst früh. Das Ziel ist nicht „mehr Automatisierung um jeden Preis“, sondern schnelleres Feedback.
Continuous Delivery/Deployment (CD) baut darauf auf: Wenn CI grün ist, kann ein Release automatisch vorbereitet oder sogar automatisch ausgerollt werden. In vielen Teams ist ein guter Zwischenweg: automatisches Deployment in Staging, manuelles Freigeben für Production.
So ist ein Workflow aufgebaut: Trigger, Jobs, Steps
Ein Workflow ist eine Datei unter .github/workflows (z. B. .github/workflows/ci.yml). Sie beschreibt, wann etwas läuft und welche Befehle ausgeführt werden.
Wichtige Bausteine:
- Workflow: die komplette Automatisierung (Datei)
- Trigger (Ereignis): z. B. Push, Pull Request, manuell
- Jobs: getrennte Aufgabenblöcke, können parallel laufen
- Steps: einzelne Schritte innerhalb eines Jobs
- Runner: die Maschine, auf der der Job läuft (z. B. ubuntu-latest)
Welche Trigger in der Praxis sinnvoll sind
Für CI sind typischerweise zwei Trigger hilfreich:
- pull_request: damit jeder PR automatisch geprüft wird
- push auf main (oder master): damit nach dem Merge alles noch einmal sicher läuft
Für Deployments werden oft zusätzliche Regeln genutzt: nur bei Tags (Release-Versionen) oder nur manuell über „workflow_dispatch“.
Ein solides CI-Setup: Tests, Linting, Build
Ein praxisnahes Minimum ist ein Workflow, der bei Pull Requests dieselben Dinge tut, die lokal ohnehin laufen sollten. Wichtig ist, dass die Checks schnell und stabil sind. Ein Build, der 25 Minuten dauert oder dauernd fluktuiert, wird im Team schnell ignoriert.
Beispiel: Node.js-Projekt (Lint + Tests + Build)
Das folgende Beispiel ist bewusst generisch gehalten. Es zeigt die typische Struktur, die in vielen Projekten funktioniert:
- Checkout des Repos
- Node-Version setzen
- Dependencies installieren
- Linting, Tests, Build laufen lassen
Wer schon npm-Skripte nutzt, hat hier einen Vorteil: Actions ruft dann einfach dieselben Kommandos auf.
Stabilität: Caching und klare Abhängigkeiten
Ein häufiger Performance-Hebel ist Dependency-Caching (z. B. npm/yarn/pnpm Cache). Damit werden wiederkehrende Downloads reduziert. Gleichzeitig sollte die Installation reproduzierbar sein: Lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) gehören ins Repository.
Auch wichtig: Der Workflow sollte nicht „heimlich“ von lokalen Zuständen abhängen. Wenn ein Build lokal nur funktioniert, weil irgendwo eine Datei liegt, muss das im Repo oder in der Konfiguration sichtbar werden.
Secrets und Umgebungsvariablen richtig nutzen
Spätestens beim Deployment taucht die Frage auf: Wohin mit Passwörtern, Tokens und API-Keys? In Actions gehören solche Werte in Secrets. Das sind geschützte Variablen, die im Repository oder in der Organisation hinterlegt werden.
Typische Regeln aus der Praxis:
- Keine Secrets im Code oder in YAML committen.
- Für Staging und Production getrennte Secrets verwenden.
- Tokens klein halten (nur benötigte Rechte).
Hilfreich ist außerdem ein sauberes Verständnis von Umgebungsvariablen. Dazu passt: Environment Variables verstehen – .env sicher nutzen.
Permissions: nur so viel wie nötig
Workflows können Rechte bekommen, z. B. um Releases zu erstellen oder Pakete zu publishen. Sinnvoll ist ein „least privilege“-Ansatz (nur die Rechte, die gebraucht werden). Das reduziert den Schaden, falls ein Token oder Workflow missbraucht wird.
Deployment-Pipeline planen, ohne sich zu verrennen
Ein Deployment mit Actions kann sehr simpel sein (z. B. per SSH auf einen Server) oder komplex (Container, Cloud, mehrere Stages). Der häufigste Fehler ist, zu früh zu viel zu bauen. Besser ist ein klarer Pfad in kleinen Schritten:
- CI stabil machen (Lint + Tests + Build)
- Deployment in eine Testumgebung (Staging)
- Production erst nach Freigabe oder bei Tag/Release
Fallbeispiel aus dem Projektalltag
Ein Team deployt „wenn Zeit ist“: mal nach dem Merge, mal am Ende des Tages. Ergebnis: Fehler werden zu spät bemerkt, und niemand weiß, welcher Commit gerade live ist. Nach der Umstellung auf Actions laufen bei jedem Pull Request Tests und ein Build. Nach dem Merge wird automatisch in Staging deployt. Production wird nur per Release-Tag ausgerollt. Dadurch sind zwei Dinge sofort besser: Die Feedback-Schleife ist kürzer, und die Live-Version ist eindeutig nachvollziehbar.
Kleine Entscheidungshilfe: Welcher Workflow passt?
-
-
Wenn ein Projekt klein ist und nur wenige Änderungen pro Woche bekommt:
- CI bei pull_request (Lint + Tests) reicht oft aus.
- Deploy manuell auslösen (workflow_dispatch), damit es kontrolliert bleibt.
-
Wenn mehrere Personen täglich mergen:
- CI bei pull_request und push auf main.
- Staging-Deploy automatisch nach Merge.
-
Wenn Releases versioniert sind (z. B. SemVer-Tags):
- Production-Deploy nur bei Tag.
- Zusätzlich Release-Notes/Artefakte automatisch erzeugen.
-
So lassen sich Workflows gut pflegen
Actions ist kein „einmal einstellen und vergessen“-Thema. Kleine Pflege spart später viel Ärger:
- Schritte in Jobs trennen: erst Qualität (Lint), dann Tests, dann Build.
- Fehlerausgaben lesbar halten: zu viele Logs erschlagen, zu wenige Logs sind nutzlos.
- Workflows regelmäßig aktualisieren (z. B. Actions-Versionen), aber nicht hektisch.
- Bei Flaky Tests (Tests, die manchmal fehlschlagen) zuerst Stabilität schaffen, bevor CD automatisiert wird.
Kurze Box mit pragmatischen Schritten
- Eine Datei unter .github/workflows/ci.yml anlegen und auf pull_request triggern.
- Checkout, Runtime-Setup (z. B. Node/PHP/Python) und Dependency-Install definieren.
- Lokale Standardkommandos nutzen (z. B. npm test, composer test, pytest).
- Erst wenn CI stabil ist: Staging-Deploy ergänzen.
- Secrets in GitHub hinterlegen und Rechte sparsam vergeben.
Häufige Stolpersteine und wie sie wegfallen
„Bei mir läuft’s“: Unterschiede zwischen lokal und Runner
Runner starten sauber und ohne lokale Extras. Deshalb treten hier Probleme auf, die lokal verborgen bleiben. Abhilfe: Abhängigkeiten explizit installieren, Build-Schritte sauber definieren und Konfiguration (z. B. Umgebungsvariablen) dokumentieren.
Zu viele Workflows, zu wenig Klarheit
Viele kleine YAML-Dateien wirken zunächst ordentlich, werden aber schnell unübersichtlich. Für kleine Teams ist oft besser: eine CI-Datei, eine Deployment-Datei. Später kann aufgeteilt werden, wenn es wirklich nötig ist.
Timeouts und hängende Jobs
Wenn Jobs gelegentlich hängen (z. B. bei Netzwerkproblemen), helfen klare Timeouts und robuste Skripte. Für API-nahe Tests kann es außerdem sinnvoll sein, das Thema Zeitlimits bewusst zu planen: API-Timeouts sinnvoll setzen – robuste Requests ohne Hänger.
Zusammenhang zu sauberer Teamarbeit
Actions bringt den meisten Nutzen, wenn Pull Requests sauber sind und Änderungen gut beschrieben werden. Dann ist auch klar, warum ein Check fehlschlägt. Ergänzend hilft ein konsistenter Review-Prozess: Code Reviews im Team – Pull Requests besser machen. Und wenn CI lange „rot“ bleibt, wird es meist ein Prozessproblem: zu große PRs, zu seltenes Mergen oder fehlende Teststrategie.
Wer Automatisierung Schritt für Schritt aufbaut, bekommt schnell messbaren Nutzen: weniger manuelle Routine, weniger Überraschungen nach dem Merge und mehr Vertrauen in Releases.
