CARGRAPHIC — Deployment & Versionskontrolle

Ist-Zustand

Alles auf einem FTP-Server — Code, 40 GB Bilder, keine Versionierung

Marc, Bernhard und der Web-Server greifen auf denselben FTP-Server zu. Kein Staging, kein Rollback, kein Git.

Marc (Entwickler)

arbeitet auf seinem Computer

Bernhard

meldet sich im Browser an und pflegt die Seite

lädt Code hoch

holt Datenbank-Kopie

meldet sich an und ändert Inhalte

Beim Anbieter (Hosting)

Dateiablage

Webseitencode + alle Bilder gemischt

Webseitencode (Design, Vorlagen, Erweiterungen)

Alle Bilder — 40 GB

Kein Rückgängig-Knopf, kein Versionsstand

lädt Webseitencode

Die Webseite

cargraphic.de

Änderungen von Marc gehen direkt hier hin

Kein Test vorher möglich

liest Texte & Inhalte

Inhaltsdatenbank

alle Texte, Seitenstruktur, Produkte · kein Bild drin

Protokoll & Änderungshistorie2.570 MB

Zwischenspeicher330 MB

Echter Inhalt~600 MB

Bernhard lädt Bild hoch

Bernhard ändert Text

Marcs Änderungen landen sofort auf der Live-Webseite — ein Testlauf vorher ist nicht möglich.

Marcs Workflow

Bevor ich anfangen kann ...

1 DB-Dump vom Provider ziehen und lokal importieren

2 FTP-Stand herunterladen — TYPO3-Code und 40 GB fileadmin

3 Lokales TYPO3 starten gegen lokale MySQL + lokales fileadmin

Hat Bernhard zwischenzeitlich einen Inhalt geändert — Dump veraltet, von vorne.

Wenn ich fertig bin ...

1 Geänderte Dateien per FTP auf den Server hochladen

2 DB-Änderungen als SQL-Statement direkt auf der Live-DB ausführen

3 Kein Staging — Änderungen sind sofort live. Kein Rollback möglich.

Ein Fehler im SQL-Statement trifft direkt die Live-Datenbank — ohne Rückweg.

FTP als einziger Zugang Aktuell im Einsatz

Änderungen werden direkt per FTP auf den Produktiv-Server gespielt — kein Zwischenschritt, keine Prüfung.
Code und Mediendateien (40 GB Bilder) liegen im selben Verzeichnis — Code und Bilder sind nicht trennbar.
Kein Versionsverlauf: wer was wann geändert hat, ist nicht nachvollziehbar.
Kein Rollback: ein Fehler überschreibt die Datei sofort — rückgängig machen ist manuell und fehleranfällig.

Kein lokales Arbeiten möglich Marcs Alltag

40 GB fileadmin/ auf FTP — lokal kopieren dauert Stunden, ist also keine Option.
Sobald Bernhard einen Inhalt ändert, ist Marcs lokaler DB-Stand veraltet — neuer Dump nötig.
Ohne aktuellen Dump sieht die lokale Version anders aus als Live — Fehler, die lokal auftauchen, existieren auf Produktion nicht, und umgekehrt.

Datenbank: 83 % Ballast Gemessen an der Live-Datenbank

sys_log: 2.155 MB — reines Zugriffslog, für Entwicklung wertlos, wächst ungebremst.
sys_history: 414 MB — TYPO3-Versionierungshistorie aller Redaktionsänderungen.
tx_realurl_*: 242 MB — URL-Caches, werden beim nächsten Aufruf ohnehin neu befüllt.
Echter Inhalt (Seiten, Texte, Produkte): nur ~600 MB — der Rest ist sicher wegwerfbar.

Soll-Zustand

Git + Object Storage — Staging als PRD-Klon, lokales ddev

Code in Git, Bilder im Bucket. Staging ist immer ein Klon von PRD. Lokal: ddev + Slim-Dump + Reverse Proxy — ohne 40 GB herunterzuladen.

Bernhard

pflegt Texte und Bilder im Browser wie gewohnt

Versionsverwaltung fuer Code

jede Änderung von Marc ist gespeichert und rückgängig machbar

wie "Änderungen nachverfolgen" in Word

Bilder werden hier nicht gespeichert

Gemeinsamer Bildspeicher

Hetzner Cloud · ~5 Euro/Monat

Alle 40 GB Bilder an einem Ort

Bernhard lädt hoch → erscheint sofort überall

pflegt Live-Seite

Code wird automatisch uebernommen

Bilder werden direkt geladen

Live-Webseite

cargraphic.de

Code kommt aus der Versionsverwaltung

Bilder kommen aus dem Bildspeicher

Texte und Inhalte — Bernhard pflegt hier

Bernhard arbeitet hier wie bisher

Testumgebung

staging.cargraphic.de

Code kommt aus der Versionsverwaltung

Bilder kommen aus dem Bildspeicher

Inhalte = Kopie der Live-Seite

Marc prueft hier neue Funktionen, bevor sie live gehen

ist immer ein Abbild der Live-Seite

Marcs Rechner

localhost — nur fuer Entwicklung

Code kommt aus der Versionsverwaltung

Bilder werden bei Bedarf von der Live-Seite geladen

Inhalte = Kopie der Live-Seite (~600 MB statt 3,5 GB)

Kein 40 GB Download mehr noetig

Bernhard lädt ein Bild hoch — Marc und die Testumgebung sehen es sofort. Keine manuelle Übertragung mehr.

Marcs neuer Workflow

Lokal starten

1 git clone — Code lokal, fertig

2 ./sync-db.sh — Slim-Dump ziehen und importieren (~1 Min.)

3 ddev start — TYPO3 läuft lokal, Bilder kommen per Proxy von PRD

Kein 40 GB Download. Immer auf PRD-Stand.

Änderung deployen

1 Lokal entwickeln und testen

2 git push → Staging zieht automatisch per git pull

3 Auf Staging prüfen → git pull auf PRD

Kein FTP. Kein SQL auf der Live-DB. Rollback per git revert.

Git für den Code Versionskontrolle + Deployment

TYPO3-Code in Git — jede Änderung nachvollziehbar, jederzeit rückrollbar per git revert.
Deploy auf Staging und PRD per git pull — kein FTP mehr, kein manuelles Datei-Übertragen.
fileadmin/ bleibt per .gitignore außen vor — Bilder gehören in den Bucket.

Warum externer Bucket statt FTP? Object Storage · Hetzner ~5 €/Monat

FTP-Verzeichnis: am PHP-Server geklebt — nur per FTP erreichbar, kein direkter HTTP-Zugriff, kein CDN, kein Sharing zwischen Umgebungen.
Externer Bucket: unabhängig vom Server — alle Umgebungen (PRD, Staging, Lokal) greifen direkt per HTTPS drauf zu. Kein Server dazwischen.
Bernhard lädt ein Bild hoch → liegt sofort im Bucket → Staging und Lokal sehen es ohne jeglichen Sync.
Bucket ist CDN-ready: Bilder werden am Rand ausgeliefert, nicht vom PHP-Server — schnellere Ladezeiten, weniger Last.
Serverumzug oder Hosting-Wechsel? Der Bucket bleibt — fileadmin ist nicht mehr an einen bestimmten Server gebunden.

FTP-VerzeichnisExterner Bucket

Zugriff nur FTP HTTPS · direkt

Alle Umgebungen nein ja · ein Bucket

CDN nein ja

Serverunabhängig nein ja

Sync nötig ja · manuell nein

Slim-Dump statt Full-Backup DB-Sync in ~1 Minute

DB ohne sys_log, sys_history und Caches: 3,5 GB → ~600 MB.
Ein Script (./sync-db.sh) zieht den Dump und importiert ihn lokal — vor jeder Session, bei Bedarf.
Staging bekommt denselben Dump — ist damit immer ein exakter Klon des PRD-Inhaltsstands.