Level 0
Manuell / FTP / SSH
Dateien werden direkt auf dem Server angepasst oder per FTP hochgeladen.
- • schnell eingerichtet
- • hohe Fehleranfälligkeit
- • kaum reproduzierbar, kein Rollback
Releases · CI/CD · Zero-Downtime & Rollback
TYPO3 Deployment: Von manuellen FTP-Uploads
zu stabilen, reproduzierbaren Releases
Viele TYPO3-Projekte werden immer noch per FTP, ZIP-Upload oder manuellen SSH-Befehlen deployed – und jeder Release fühlt sich wie ein kleiner Nervenkitzel an. Moderne Deployments sind das Gegenteil: reproduzierbar, testbar, dokumentiert und mit Rollback-Plan versehen. Diese Seite zeigt, wie Sie Ihre Release-Prozesse Schritt für Schritt dorthin entwickeln.
Fokus: TYPO3 v10–v13, CI/CD & Zero-Downtime
Für IT, Dev-Teams & Projektverantwortliche
Praxisbeispiele & konkrete Handlungsschritte
Was bedeutet „sauberes Deployment“ bei TYPO3 konkret?
Ein Deployment ist mehr als „Code auf den Server kopieren“. In professionellen Umgebungen ist es ein standardisierter, wiederholbarer Prozess, der die gleichen Schritte immer in der gleichen Reihenfolge ausführt – egal, wer im Team das Release anstößt.
Im TYPO3-Kontext bedeutet das u. a.:
- • Klare Trennung von Build (Composer, Assets) und Deploy (Rollout auf Servern).
- • Schreibgeschütztes Webroot – keine Änderungen per FTP oder Live-Editor.
- • Konfiguration nach Umgebung (Test, Staging, Live) statt „alles in einer Instanz“.
- • Datenbank-Migrationen als Teil des Prozesses, nicht als Nachgedanke.
- • Rollback-Möglichkeit, falls nach dem Release etwas schief geht.
Ziel ist ein Prozess, bei dem Releases nicht von einzelnen „Heldentaten“ abhängen, sondern sicher im Team skaliert werden können – auch unter Zeitdruck.
Deployment-Strategien im Überblick: Von „Quick & Dirty“ zu CI/CD
Nicht jedes Projekt braucht sofort Kubernetes und Blue-Green-Deployments. Entscheidend ist, wo Sie heute stehen – und welches nächste sinnvolle Level ist. Ein grober Überblick:
Level 1
Git-Pull & Skripte
Releases erfolgen über Git-Pull auf dem Server, ergänzt um Skripte (Composer, Caches).
- • erste Standardisierung
- • weniger Copy&Paste-Fehler
- • aber oft noch Downtime & „Snowflake“-Server
Empfohlen
CI/CD & (Near-)Zero-Downtime
Build auf separaten Runnern, Deploy über Pipelines (z. B. GitLab CI, Deployer) mit Rollback-Option.
- • reproduzierbare Deployments
- • automatisierte Checks & Tests
- • kontrollierter Rollout & Rollback
In vielen Projekten reicht es, von Level 0 auf 1 oder von 1 auf 2 zu kommen – in klar definierten Schritten, statt alles auf einmal umzuwerfen.
Bausteine einer modernen TYPO3-Deployment-Pipeline
Unabhängig davon, welches Tool Sie nutzen (GitLab CI, GitHub Actions, Deployer, Jenkins o. ä.), folgen stabile Deployments meist einem ähnlichen Muster:
1. Saubere Basis: Versionskontrolle & Composer
- • Alles Relevante (Code, Konfigurationen, Deploy-Skripte) liegt in Git.
- • TYPO3 wird per Composer verwaltet, nicht via TER-Downloads auf Live.
- • Sensible Daten werden über .env/Secrets und nicht im Repository gepflegt.
2. Build-Schritt außerhalb von Live
- • Composer-Install, Asset-Build (CSS/JS), ggf. Tests laufen auf Build-Runnern.
- • Das Ergebnis ist ein Artefakt (z. B. Release-Ordner), der deployt wird.
- • Live-System bleibt während des Builds unberührt.
3. Kontrollierter Rollout & Rollback
- • Deploy per SSH/Deployer, rsync oder Container-Rollout – nicht mehr per Hand.
- • Symlink-Strategien ermöglichen (nahezu) Zero-Downtime.
- • Rollback heißt: auf vorheriges Release verweisen, nicht „Backup suchen“.
4. Tests, Health-Checks & Monitoring
- • Smoke-Tests, grundlegende Funktionsprüfungen, ggf. Functional-Tests.
- • Health-Checks nach Deploy (HTTP-Status, wichtige Seiten, Logs).
- • Monitoring & Alerts, wenn Fehler- oder Last-Spitzen auftreten.
Wie weit Sie gehen, hängt von Risiko, Budget und Kritikalität Ihres Systems ab. Entscheidend ist, dass der Ablauf dokumentiert ist und im Team verstanden wird – nicht nur von einer einzelnen Person.
Zero-Downtime & Rollback: Warum es mehr ist als „nice to have“
Insbesondere bei Behördenportalen, Verbänden oder größeren Unternehmens-Websites sind lange Downtimes nicht akzeptabel. Selbst wenige Minuten können Support-Hotlines auslasten oder intern für Unruhe sorgen.
Typische Anforderungen aus der Praxis
- • Deployments auch während der Arbeitszeit fahren können.
- • Notfall-Rollback innerhalb von Minuten – nicht Stunden.
- • Keine inkonsistenten Zustände während des Deployments (z. B. halbfertige Assets).
Das ist mit sauber gestalteten Deployments und passenden Hosting-Setups erreichbar – ohne dass die Infrastruktur unnötig komplex werden muss.
Bausteine für (Near-)Zero-Downtime
- • Build des neuen Releases im Hintergrund (separater Ordner / Container).
- • Atomic Switch: Symlink-Wechsel oder Container-Rollout in einem Schritt.
- • Schreibrechte & Caches so konfigurieren, dass sie deploy-sicher sind.
- • Aufeinander abgestimmte Datenbank-Migrationen und Release-Zeitpunkte.
→ Für eine Einschätzung, wie weit Sie davon entfernt sind: TYPO3 Release-Check
Praxisbeispiele: Wie sich stabile Deployments im Alltag auswirken
Einige anonymisierte, vereinfachte Beispiele aus Projekten zeigen, wie sich eine verbesserte Deployment-Strategie bemerkbar macht:
Behördenportal · GitLab CI & Deployer
Ausgangslage: Manuelle Releases, hohe Nervosität vor Go-Lives. Nach Einführung einer GitLab-CI-Pipeline mit Deployer und klaren Rollback-Szenarien: planbare Releases, kürzere Wartungsfenster und bessere Nachvollziehbarkeit für IT & Fachbereich.
Mittelstand · Upgrade + Deployment-Modernisierung
Ausgangslage: Upgrade v8 → v12, parallel stark gewachsene Produktdatenbank. Im Zuge des Upgrades wurde eine standardisierte Release- und Migrations-Strategie etabliert. Ergebnis: Weniger „Feuerwehr-Einsätze“, schnellere Weiterentwicklungen.
Digitalagentur · Standardisierung über mehrere Kunden
Ausgangslage: Jedes Projekt hatte eigene Scripts & Workflows. Ergebnis nach Einführung eines gemeinsamen Deployment-Frameworks: bessere Wartbarkeit, geringere Einarbeitungszeiten und weniger Abhängigkeit von einzelnen Entwickler:innen.
Häufige Fragen zu TYPO3 Deployment & CI/CD
In Gesprächen mit IT, Dev-Teams und Projektverantwortlichen tauchen einige Fragen immer wieder auf:
Brauchen wir wirklich CI/CD – unser Projekt ist doch „nur“ eine Website? ›
CI/CD bedeutet nicht automatisch „komplexe Enterprise-Infrastruktur“. Es bedeutet in erster Linie:
klar definierte, automatisierte Schritte, die Deployments sicherer machen.
Auch kleinere Sites profitieren davon, weil Fehler seltener werden und Releases nicht an Einzelpersonen hängen.
Wir deployen noch per FTP – müssen wir alles komplett umbauen? ›
Nein. Häufig ist es sinnvoll, in kleinen Schritten vorzugehen:
zunächst Git + Composer etablieren, dann Skripte für wiederkehrende Schritte,
danach erst eine Pipeline. Wichtig ist ein klarer Zielzustand,
nicht der sofortige Big-Bang-Umbau.
Wie hängt das Thema Deployment mit einem Upgrade zusammen? ›
Viele Upgrade-Projekte scheitern nicht am Code, sondern an fehlenden Prozessen:
kein Staging, keine reproduzierbaren Deployments, kein Rollback. Ein Upgrade ist daher ein idealer
Zeitpunkt, auch die Deployment-Strategie zu modernisieren –
von Audit
über Upgrade-Check
bis hin zu neuen Pipelines.
Wie lange dauert es, eine sinnvolle Deployment-Pipeline aufzubauen? ›
Das hängt von Größe & Historie Ihres Systems ab. Für viele TYPO3-Installationen reichen
wenige Sprints, um von „manuell & riskant“ auf „standardisiert & reproduzierbar“
zu kommen. Der Schlüssel ist, sich zunächst auf die wichtigsten Schritte
(Build, Deploy, Rollback) zu konzentrieren – und nicht alles auf einmal zu automatisieren.
Sie möchten Releases ohne Bauchschmerzen fahren?
Ob Upgrade, Relaunch oder laufende Weiterentwicklung – stabile Deployments sind die Grundlage für entspannte Releases. In einem kurzen Erstgespräch klären wir, wie Ihre aktuelle Release-Pipeline aussieht und welche Schritte sinnvoll sind, um sie zu modernisieren.