siteway

// stack · deployment

Deployment & Betrieb.

Jede Änderung an einer Website von siteway läuft über Git und eine CI/CD-Pipeline mit GitHub Actions: Versionskontrolle, automatisierte Builds und getrennte Umgebungen für Staging und Live. Reproduzierbare Deploys statt manuelles FTP — das ist der technische Weg vom Commit bis zur fertigen Seite.

stack ci/cd: git · github actions umgebungen: staging · live seit: 2006
Projekt anfragen Wie wir ausliefern

// definition

Was ist eine CI/CD-Pipeline?

Eine CI/CD-Pipeline ist der automatisierte Weg vom Code-Commit bis zur Live-Website. CI steht für Continuous Integration: Änderungen laufen in Git zusammen und werden gebaut. CD steht für Continuous Delivery — das geprüfte Ergebnis wird automatisch auf die Server ausgeliefert. Zwischen Commit und Live liegen Build, Prüfung und Deploy als Schritte, die eine Maschine ausführt statt ein Mensch von Hand.

Der entscheidende Punkt ist die Versionskontrolle: Git ist die einzige Quelle der Wahrheit. Jeder Stand ist benannt, jede Änderung nachvollziehbar, jeder Deploy an einen Commit gebunden. Damit ist zu jedem Zeitpunkt klar, was live ist — und jeder Zustand lässt sich wiederherstellen.

// so setzen wir das ein

Wie wir ausliefern.

git → build → staging → live

Bei uns gibt es keinen Ordner voller Dateien, die jemand per Hand hochlädt. Der Code liegt in Git, ein Push löst einen Workflow in GitHub Actions aus, und ab da läuft alles automatisch. Der Build passiert in der Pipeline, nicht auf einem Entwickler-Laptop: Tailwind baut das CSS, die Bild-Pipeline erzeugt AVIF und WebP, der Suchindex wird neu geschrieben, Sitemap und Cache-Busting werden gesetzt — in fester Reihenfolge, jedes Mal identisch.

Ausgeliefert wird auf zwei getrennte Umgebungen. Eine Änderung geht zuerst auf Staging — eine nicht öffentliche Kopie mit derselben Technik wie Live. Dort prüfen wir in beiden Themes, auf allen Breiten und mit echten Inhalten, deine Redaktion kann Beiträge vorab ansehen. Erst wenn der Stand passt, geht exakt derselbe geprüfte Commit auf Live. Niemand testet an der produktiven Seite.

Weil jeder Deploy an einen Git-Stand gebunden und der Build reproduzierbar ist, gibt es kein „läuft nur bei mir“ und keinen halben Zustand im Live-Betrieb. Der Deploy wird atomar umgeschaltet; geht etwas schief, rollen wir den letzten funktionierenden Commit erneut aus — ein Rollback ist bei uns ein normaler Deploy, kein Notfall.

// prinzipien · 6

Worauf unser Deployment steht.

jede regel ein grund

Sechs technische Entscheidungen, die hinter jedem Deploy stehen. Sie unterscheiden eine Pipeline von einem FTP-Upload — und machen den Betrieb einer Website vorhersehbar statt fragil.

// p-01git

Versionskontrolle.

Git ist die einzige Quelle der Wahrheit. Jede Änderung ist ein benannter Commit — mit Autor, Zeitpunkt und Grund. Was live ist, hängt an einem Stand, nicht an einem Bauchgefühl.

git · commit-historie

// p-02pipeline

Automatisierter Build.

GitHub Actions baut CSS, Bilder, Suchindex, Sitemap und Cache-Busting — in fester Reihenfolge, auf einem sauberen Stand. Kein Handgriff, keine vergessene Datei.

github actions · workflow

// p-03umgebungen

Staging und Live.

Zwei getrennte Umgebungen mit identischer Technik. Änderungen werden auf Staging geprüft, bevor derselbe Stand auf Live geht. Getestet wird nie an der produktiven Seite.

staging · live

// p-04reproduzierbar

Reproduzierbare Deploys.

Derselbe Commit ergibt jeden Durchlauf dasselbe Ergebnis. Der Build läuft in der Pipeline, nicht auf einem Laptop — kein „läuft nur bei mir“, keine Überraschung auf dem Server.

deterministischer build

// p-05atomar

Atomar & Rollback.

Ein Deploy ist ganz da oder gar nicht — umgeschaltet, nicht Datei für Datei überschrieben. Geht etwas schief, rollen wir den letzten guten Commit in Sekunden zurück.

atomarer switch · rollback

// p-06kein ftp

Kein manuelles FTP.

Kein Hochladen einzelner Dateien, kein Rätselraten, welcher Stand gerade läuft. Die Auslieferung geht über SSH aus der Pipeline — nachvollziehbar, wiederholbar, ohne offene Handgriffe.

ssh-deploy statt ftp

// ablauf · 4 schritte

Der Weg jeder Änderung.

vom commit · bis live

  1. // schritt 01 · commit

    Commit & Push.

    Eine Änderung wird als Commit festgehalten und nach Git gepusht — mit Grund und Autor. Der Stand ist damit benannt und nachvollziehbar.

    output: git-commit

  2. // schritt 02 · build

    Pipeline baut.

    GitHub Actions startet automatisch: CSS, AVIF/WebP-Bilder, Suchindex, Sitemap und Cache-Busting entstehen in fester Reihenfolge auf einem sauberen Stand.

    output: build-artefakt

  3. // schritt 03 · staging

    Auf Staging prüfen.

    Der Deploy geht zuerst auf die Staging-Umgebung. Dort prüfen wir Darstellung, beide Themes und echte Inhalte — deine Redaktion sieht Änderungen vorab.

    output: geprüfter stand

  4. // schritt 04 · live ● ergebnis

    Live schalten.

    Nach der Freigabe geht exakt derselbe Commit atomar auf Live. Bleibt etwas hängen, rollen wir den letzten guten Stand zurück — kein halber Zustand im Betrieb.

    output: live-deploy

// im einsatz

Pipeline in echten Projekten.

nicht nur doku · praxis

Je größer und mehrsprachiger eine Website, desto mehr zählt ein sauberer Auslieferungsprozess. Beim Case Spelsberg — eine TYPO3-Website in 13 Sprachen — heißt das: Änderungen an Templates und Technik gehen erst auf Staging, wo die Redaktion Inhalte über alle Sprachen hinweg gegenprüfen kann, bevor derselbe Stand live geht. Ein Build von Hand über 13 Sprachbäume wäre fehleranfällig; die Pipeline macht ihn wiederholbar.

Auch unsere eigene Seite läuft so: Jede Änderung baut CSS, Bilder, Suchindex und Sitemap in der Pipeline und geht versioniert über Git und GitHub Actions auf getrennte Umgebungen. Was wir hier beschreiben, setzen wir täglich selbst ein — die Cases zeigen den Rest.

// faq

Häufige Fragen.

Was ist eine CI/CD-Pipeline?

Eine CI/CD-Pipeline ist der automatisierte Weg vom Code-Commit bis zur Live-Website. CI steht für Continuous Integration — Änderungen laufen in Git zusammen und werden gebaut. CD steht für Continuous Delivery bzw. Deployment — das fertige Ergebnis wird automatisch auf die Server ausgeliefert. Zwischen Commit und Live liegen Build, Prüfung und der eigentliche Deploy als reproduzierbare Schritte, die eine Maschine ausführt statt ein Mensch von Hand.

Warum kein manuelles FTP mehr?

Weil manuelles FTP nicht nachvollziehbar und nicht wiederholbar ist. Wer einzelne Dateien per Hand hochlädt, weiß nicht sicher, welcher Stand gerade live ist, kann eine Änderung schwer zurücknehmen und lädt im Zweifel eine halbfertige Datei mitten im Betrieb hoch. Wir liefern stattdessen über eine Pipeline aus: Git kennt jeden Stand, der Build ist identisch reproduzierbar und ein Deploy ist entweder ganz da oder gar nicht.

Was ist der Unterschied zwischen Staging und Live?

Staging ist eine eigene, öffentlich nicht sichtbare Kopie der Website mit derselben Technik wie Live. Dort landet eine Änderung zuerst: Wir prüfen sie in beiden Themes, auf allen Breiten und mit echten Inhalten, deine Redaktion kann Beiträge vorab ansehen. Erst wenn alles passt, geht derselbe geprüfte Stand auf die Live-Umgebung. So testet niemand am offenen Herzen der produktiven Seite.

Was bedeutet reproduzierbarer Deploy?

Reproduzierbar heißt: Aus demselben Git-Stand entsteht bei jedem Durchlauf exakt dasselbe Ergebnis. Der Build — CSS, Bild-Pipeline, Suchindex, Cache-Busting — läuft in der Pipeline auf einem sauberen Stand, nicht auf dem Rechner eines Entwicklers. Damit gibt es kein „läuft nur bei mir“. Jeder Deploy ist ein bekannter, wiederholbarer Zustand, den wir jederzeit erneut ausrollen können.

Wie funktioniert ein Rollback, wenn etwas kaputt geht?

Weil jeder Stand in Git liegt und jeder Deploy reproduzierbar ist, ist ein Rollback kein Notfall, sondern ein normaler Deploy: Wir rollen den letzten funktionierenden Commit erneut aus. Da der Deploy atomar umgeschaltet wird, ist die alte Version in Sekunden wieder live — ohne halbe Zustände, ohne verlorene Dateien.

Ist die Pipeline dasselbe wie laufende Wartung und Betreuung?

Nein. Die Pipeline ist die Technik, mit der wir ausliefern — der Weg, den jede Änderung nimmt. Die laufende Betreuung, also Updates, Backups, Monitoring und Support als vereinbarte Leistung, ist ein eigener Baustein: Betrieb, Wartung & Support. Die Pipeline ist die Grundlage dafür, die Betreuung ist der Vertrag darüber.

// womit das zusammenhängt

Womit das zusammenhängt.

leistung & stack

// ci/cd · im detail

GitHub Actions.

Die Pipeline im Detail: Workflows als YAML im Repo, Build und Deployment auf Staging und Live.

weiterlesen →

// leistung · betrieb

Betrieb, Wartung & Support.

Die Pipeline liefert aus — diese Leistung hält die Seite im Betrieb: Updates, Backups, Monitoring und Support als vereinbarter Vertrag. Hier buchst du die laufende Betreuung.

zur leistung →

// stack · frontend

Frontend.

Das CSS, das die Pipeline baut, entsteht hier: HTML5, Tailwind und Vanilla JavaScript. Der Build übersetzt es in schlanke Bundles, bevor der Deploy es ausliefert.

zur technologie →

// stack · media

Bild- & Videoformate.

Die AVIF- und WebP-Varianten entstehen in derselben Pipeline: Die Bild-Pipeline läuft als Build-Schritt, sodass optimierte Bilder mit jedem Deploy mitkommen.

zur technologie →

// Website, die sauber ausgeliefert wird?

Projekt anfragen