// stack · ci-cd
GitHub Actions ist die Automatisierung, die direkt im Repository wohnt: Workflows liegen als YAML-Datei neben dem Code und starten, sobald jemand pusht oder einen Pull Request öffnet. Bei siteway baut so ein Workflow CSS, Bilder und Suchindex, prüft den Stand und liefert ihn auf Staging und Live aus — reproduzierbar statt per FTP, mit Rollback über die Git-Historie.
// definition
GitHub Actions ist die in GitHub eingebaute Automatisierungsplattform: Ein Workflow ist eine YAML-Datei im Repository, die beschreibt, was bei welchem Ereignis passieren soll. Ein Push auf main, ein neuer Pull Request, ein Zeitplan — GitHub startet daraufhin einen Runner, eine frische virtuelle Maschine, und arbeitet die beschriebenen Schritte darin ab.
Die Bausteine sind schnell erklärt: Der Trigger sagt, wann es losgeht. Ein Job läuft auf einem Runner und besteht aus Steps — entweder ein Shell-Befehl oder eine fertige Action, etwa actions/checkout zum Auschecken des Codes. GitHub Actions ist seit 2019 allgemein verfügbar und heute der Standardweg, um in einem GitHub-Repository zu bauen, zu prüfen und auszuliefern.
// praxis
push → build → deploy
Wir behandeln den Workflow wie Code: Er liegt in .github/workflows/ im selben Repository wie die Website, wird im Pull Request mitgelesen und ist jederzeit auf einen Commit zurückführbar. Ändert sich der Auslieferungsweg, ist das eine Änderung mit Autor, Datum und Grund — nicht eine Einstellung, die irgendwo in einer Oberfläche verstellt wurde und an die sich später niemand erinnert.
Der Build läuft komplett auf dem Runner, nie auf einem Entwickler-Laptop. In fester Reihenfolge: Tailwind kompiliert das CSS, die sharp-Pipeline erzeugt die AVIF- und WebP-Varianten, Pagefind schreibt den Suchindex neu, Sitemap und Markdown-Spiegel entstehen, zuletzt bekommt jede CSS- und JS-Datei ihren Cache-Busting-Hash. Jeder dieser Schritte ist ein benannter Step — bricht einer ab, bricht der Job ab, und ein kaputter Stand erreicht den Server gar nicht erst.
Ausgeliefert wird per SSH mit einem Deploy-Key, der als Secret hinterlegt ist — im Repository steht kein Passwort. Staging und Live sind getrennte Umgebungen mit eigenen Zugängen: Ein Push auf den Arbeitsstand geht auf Staging, nach der Freigabe geht exakt derselbe Commit auf Live. Für den Live-Schritt nutzen wir eine geschützte Environment, sodass er nicht versehentlich mitläuft.
Zwei Details, die viel Ärger sparen: Abhängigkeiten werden gecacht, damit ein Lauf im Minutenbereich bleibt statt bei jedem Deploy alles neu zu installieren. Und fremde Actions werden auf eine feste Version gepinnt — was heute läuft, läuft morgen genauso, auch wenn jemand anderes sein Repository umbaut. Wie sich das in den Gesamtprozess einordnet, steht im Hub Deployment & Betrieb.
// bausteine · 6 details
jeder mit klarem zweck
GitHub Actions kann viel mehr, als wir brauchen. Das sind die sechs Teile, die in unseren Projekten tatsächlich tragen — und der Grund, warum wir sie so einsetzen.
// b-01trigger
Ein Workflow startet nicht auf Zuruf, sondern auf ein Ereignis: Push, Pull Request, Zeitplan oder Handstart über die Oberfläche. Wir binden Build und Prüfung an jeden Push und den Live-Deploy an eine bewusste Freigabe.
zweck: on: push · pull_request
// b-02runner
Jeder Job läuft auf einer frisch aufgesetzten Maschine. Nichts von gestern bleibt liegen, keine lokal installierte Sonderversion verfälscht das Ergebnis. Genau das macht den Build reproduzierbar statt zufällig.
zweck: saubere umgebung
// b-03actions
Fertige Bausteine wie actions/checkout sparen Arbeit — solange sie festgenagelt sind. Wir pinnen jede fremde Action auf eine feste Version, damit ein Fremd-Update nicht unbemerkt in unseren Deploy rutscht.
zweck: wiederverwenden, gepinnt
// b-04zugänge
Deploy-Key und Tokens liegen als Secret außerhalb des Codes und werden in Logs maskiert. Staging und Live sind getrennte Environments mit eigenen Zugängen — ein Workflow erreicht nur, wofür er gedacht ist.
zweck: kein passwort im repo
// b-05tempo
Abhängigkeiten werden zwischen Läufen gecacht, das fertige Build-Ergebnis als Artefakt weitergereicht. So bleibt ein Deploy kurz genug, dass niemand ihn scheut — und derselbe Build geht auf Staging und Live.
zweck: cache + artefakt
// b-06prüfung
Vor dem Merge läuft derselbe Build plus unsere Audits: Meta-Angaben, JSON-LD, interne Links, Heading-Anchors. Was rot ist, geht nicht rein. Reviewer sehen das Ergebnis direkt am Pull Request.
zweck: fehler vor dem merge
// beleg
nicht aus der doku
Diese Website ist das nächstliegende Beispiel. Der Stand, den du gerade liest, ist durch genau den Workflow gegangen, der oben beschrieben ist: CSS gebaut, Bilder in AVIF und WebP erzeugt, Suchindex und Sitemap neu geschrieben, Cache-Busting gesetzt, dann per SSH ausgeliefert. Dass die Startseite mobil bei 100/100/100/100 in PageSpeed Insights liegt, hängt auch daran: Optimierungen, die eine Maschine bei jedem Deploy ausführt, werden nicht vergessen.
Je größer ein Projekt, desto größer der Hebel. Beim Case Spelsberg — TYPO3 in 13 Sprachen, seit 2018 von uns betreut — geht jede Template- und Technik-Änderung erst auf Staging, wo die Redaktion über alle Sprachen gegenprüft, bevor derselbe Commit live geht. Von Hand über 13 Sprachbäume zu bauen wäre eine Frage der Zeit, bis etwas untergeht. Alle Referenzen stehen unter Cases.
// einordnung
werkzeug, nicht dogma
GitHub Actions ist stark, wenn der Code ohnehin auf GitHub liegt und zwischen Commit und Live echte Arbeit passiert. Drei Fälle, an denen wir das festmachen — und was wir empfehlen, wenn ein Punkt nicht zutrifft.
// e-01build
Sobald CSS kompiliert, Bilder konvertiert oder ein Suchindex erzeugt werden muss, lohnt der Workflow sofort: Diese Schritte von Hand zu wiederholen ist die häufigste Quelle für „auf Live fehlt was".
automatisierbare schritte
// e-02team
Arbeiten mehrere Menschen am selben Projekt — oder wechselt die Betreuung —, ist die Pipeline die verlässliche Antwort auf „was ist gerade live und wie kam es dahin". Bei Einzelprojekten ohne Änderungen bleibt der Nutzen klein.
nachvollziehbarkeit
// e-03grenze
Redaktionelle Inhalte kommen aus dem CMS und laufen nicht durch die Pipeline — die liefert Templates, Code und Assets aus. Und liegt der Code auf GitLab oder einer eigenen Instanz, ist deren Runner der passende Weg; das Prinzip bleibt identisch.
cms · andere runner
// faq
GitHub Actions ist die in GitHub eingebaute Automatisierungsplattform. Ein Workflow ist eine YAML-Datei im Ordner .github/workflows des Repositories; sie beschreibt, was bei welchem Ereignis passieren soll — etwa bei einem Push auf main oder beim Öffnen eines Pull Requests. GitHub startet dafür einen Runner, eine frische virtuelle Maschine, und arbeitet die Jobs und Schritte darin ab. GitHub Actions ist seit 2019 allgemein verfügbar. siteway baut damit Build, Prüfung und Deploy jeder Website.
Für alles zwischen Commit und Live. Der Workflow baut das CSS mit Tailwind, erzeugt die AVIF- und WebP-Varianten der Bilder über die sharp-Pipeline, schreibt den Pagefind-Suchindex neu, generiert Sitemap und Markdown-Spiegel und setzt das Cache-Busting an CSS und JavaScript — immer in derselben Reihenfolge. Danach liefert er den fertigen Stand per SSH auf Staging aus, nach der Freigabe denselben Stand auf Live. Bei siteway lädt niemand einzelne Dateien per FTP hoch.
Ein Workflow liegt als YAML-Datei im Repository unter .github/workflows/ und besteht aus drei Teilen: dem Auslöser (on:), also dem Ereignis wie push oder pull_request; einem oder mehreren Jobs, die jeweils auf einem Runner laufen; und den Schritten innerhalb eines Jobs. Ein Schritt ist entweder ein Shell-Befehl oder eine fertige Action, etwa actions/checkout zum Auschecken des Codes. Weil die Datei im Repository liegt, ist jede Änderung an der Pipeline selbst ein Commit — versioniert und nachvollziehbar wie der Code.
Über Secrets. Zugangsdaten wie ein SSH-Deploy-Key oder ein API-Token werden in den Repository- oder Environment-Einstellungen hinterlegt und im Workflow nur als Platzhalter referenziert. Im Repository steht damit nie ein Passwort, und in den Logs werden die Werte maskiert. siteway trennt zusätzlich nach Umgebung: Staging und Live haben eigene Zugänge, sodass ein Workflow nur das erreicht, wofür er gedacht ist.
Die CI/CD-Pipeline ist das Prinzip: der automatisierte Weg vom Commit über Build und Prüfung bis zur Live-Website. GitHub Actions ist das Werkzeug, mit dem siteway dieses Prinzip umsetzt. Dieselbe Pipeline ließe sich auch mit GitLab CI oder einem anderen Runner bauen — die Schritte blieben dieselben. Wie der Gesamtprozess bei siteway aussieht, steht im Stack unter Deployment & Betrieb; diese Seite geht auf das Werkzeug ein.
Für öffentliche Repositories sind die Standard-Runner kostenfrei. Für private Repositories enthält jeder GitHub-Plan ein monatliches Freikontingent an Laufzeit; darüber hinaus wird nach genutzten Minuten abgerechnet. Eine Website-Pipeline mit CSS-Build, Bildverarbeitung und Suchindex läuft pro Deploy im Minutenbereich und bleibt damit in der Regel im Kontingent. siteway hält Workflows bewusst schlank und cached Abhängigkeiten, statt bei jedem Lauf alles neu zu installieren.
Schlägt ein Schritt fehl, bricht der Job ab und der Deploy findet nicht statt — ein kaputter Build erreicht die Live-Seite gar nicht erst. Das Protokoll zeigt Schritt für Schritt, wo es hakte. Ist doch einmal etwas live, das zurück soll, rollt siteway den letzten funktionierenden Commit erneut aus: Weil jeder Deploy an einen Git-Stand gebunden und der Build reproduzierbar ist, ist ein Rollback ein normaler Workflow-Lauf und kein Notfall.
// womit das zusammenhängt
stack & leistung
// stack · hub
Der Gesamtprozess, in dem dieser Workflow steckt: Git als Quelle der Wahrheit, getrennte Umgebungen, atomarer Deploy und Rollback.
zum hub →
// stack · media
Einer der Build-Schritte im Detail: Wie die sharp-Pipeline AVIF und WebP erzeugt, die der Workflow bei jedem Deploy mitliefert.
zur technologie →
// leistung · buchen
Der Workflow liefert aus — diese Leistung hält die Seite im Betrieb: Updates, Backups, Monitoring und Support als Vertrag. Hier wird gebucht.
zur leistung →
// Deploys, die niemand fürchtet?
Projekt anfragen