Blue/Green vs. Symlink-Releases für Magento-Shops

1. Was Blue/Green-Deployment wirklich bedeutet

Blue/Green-Deployment bedeutet, zwei identische Produktionsumgebungen – Blue und Green – parallel zu betreiben. Zu jedem Zeitpunkt ist genau eine Umgebung aktiv und empfängt Traffic. Ein neues Release wird in die inaktive Umgebung deployed, vollständig getestet, und dann wird der Traffic per Load Balancer oder DNS-Wechsel von der alten auf die neue Umgebung umgeschaltet. Rollback ist ein erneuter Traffic-Wechsel zurück zur alten Umgebung – in Sekunden, ohne Datenverlust.

Das klingt elegant und es ist elegant. Aber es hat einen Preis: die doppelte Infrastruktur. Zwei Webserver, zwei PHP-FPM-Instanzen, zwei vollständige Magento-Installationen, ein Load Balancer, der den Traffic-Wechsel durchführen kann. Für einen Magento-Shop mit einer einzelnen Serverinstanz ist das schlicht nicht vorhanden. Für ein Projekt mit mehreren Web-Nodes und einem vorgelagerten Load Balancer ist es machbar, aber mit erheblichem Setup-Aufwand verbunden.

Hinzu kommt die Frage der gemeinsamen Ressourcen: Datenbank, Redis und Mediendateien können nicht verdoppelt werden. Bei Blue/Green-Deployments für Magento zeigen beide Umgebungen auf dieselbe MySQL-Instanz, denselben Redis und dasselbe NFS-Mount für pub/media/. Das begrenzt den echten Isolierungsgrad des Ansatzes: Eine nicht-rückwärtskompatible Datenbankänderung im Green-Release beeinflusst sofort das laufende Blue-Release. Dieses fundamentale Magento-Constraint ist ein weiterer Grund, warum der Vorteil von Blue/Green für die meisten Magento-Setups geringer ist als für zustandslose Webanwendungen.

2. Symlink-Releases: das Capistrano-Modell für Magento

Das Symlink-Release-Modell – bekannt aus Capistrano, Deployer und ähnlichen Werkzeugen – löst dasselbe Problem mit deutlich weniger Infrastruktur. Die Grundstruktur: ein releases/-Verzeichnis mit nummerierten oder timestampten Release-Ordnern, ein current-Symlink, der auf das aktive Release zeigt, und ein shared/-Verzeichnis für Dateien, die über alle Releases hinweg unverändert bleiben. Der Webserver zeigt auf current/, nicht direkt auf ein Release-Verzeichnis.

Ein neues Release wird in ein neues Verzeichnis unter releases/ deployed, alle Magento-Schritte (Shared-Links, SCD, cache:flush) werden auf dem neuen Release-Verzeichnis ausgeführt, und erst dann wird der current-Symlink atomar auf das neue Release gewechselt. Atomar bedeutet: ln -sfn ist ein einzelner Systemaufruf, der nicht unterbrochen werden kann. In dem Moment, in dem der Symlink wechselt, zeigt der Webserver auf das neue Release – ohne Downtime, ohne halbfertigen Zustand.

3. Infrastrukturaufwand: der entscheidende Unterschied

Blue/Green-Deployment erfordert in einem minimalen Setup: zwei Serverinstanzen (oder zwei VMs/Container), einen Load Balancer mit Health-Check-Konfiguration und einem API-Mechanismus für den Traffic-Wechsel, eine Strategie für gemeinsame Ressourcen wie Datenbank und Mediendateien (die ja nicht verdoppelt werden können), und ein Skript, das den Wechsel koordiniert. Der Betriebsaufwand verdoppelt sich, weil beide Umgebungen aktuell gehalten werden müssen.

Symlink-Releases erfordern: einen Server, die korrekte Verzeichnisstruktur auf dem Server und die Berechtigung, Symlinks zu setzen. Das ist alles. Ein einzelner ln -sfn-Befehl führt den Wechsel durch. Für 95% der Magento-Shops, die auf einer einzelnen Serverinstanz betrieben werden, ist die Wahl deshalb keine echte Abwägung – Symlink-Releases sind die einzig sinnvolle Option. Blue/Green wird relevant, wenn mehrere Web-Nodes parallel betrieben werden und ein gemeinsamer Load Balancer vorhanden ist.

4. Rollback-Geschwindigkeit im direkten Vergleich

Sowohl Blue/Green als auch Symlink-Releases liefern extrem schnelle Rollbacks, aber auf unterschiedliche Weise. Bei Blue/Green ist ein Rollback ein Traffic-Wechsel: Der Load Balancer sendet Traffic wieder an die alte Umgebung. Das dauert Sekunden und hat keinerlei Auswirkung auf die Anwendung selbst – die alte Umgebung war die ganze Zeit parallel aktiv. Das ist der echte Vorteil von Blue/Green: Die alte Version war nie wirklich abgeschaltet.

Bei Symlink-Releases ist ein Rollback ein Symlink-Wechsel: ln -sfn /var/www/releases/20260507-120500 /var/www/current. Das dauert ebenfalls Sekunden und erfordert keinen Neustart des Webservers. Der Unterschied zur Blue/Green-Variante: Neue Requests, die während des Deploy-Prozesses ankamen und das neue Release-Verzeichnis bereits nutzen, werden abrupt auf das alte Release zurückgeworfen. Bei Magento ist das unkritisch für die meisten Request-Typen, kann aber bei laufenden Checkout-Prozessen zu Unterbrechungen führen. In der Praxis ist dieses Fenster extrem kurz.

deploy:production:
  stage: deploy
  environment:
    name: production
    url: https://shop.example.com
  script:
    # Transfer release archive to server
    - scp release-${CI_COMMIT_SHORT_SHA}.tar.gz "${DEPLOY_USER}@${DEPLOY_HOST}:/tmp/"
    # Execute deployment sequence via SSH
    - ssh "${DEPLOY_USER}@${DEPLOY_HOST}" bash -s << 'DEPLOY'
        set -euo pipefail
        readonly RELEASE_ID="$(date +%Y%m%d-%H%M%S)"
        readonly APP_PATH="${DEPLOY_PATH}"
        readonly RELEASE_DIR="${APP_PATH}/releases/${RELEASE_ID}"

        # Create and populate release directory
        mkdir -p "${RELEASE_DIR}"
        tar -xzf "/tmp/release-${CI_COMMIT_SHORT_SHA}.tar.gz" -C "${RELEASE_DIR}"

        # Link shared directories (media, logs, env.php)
        ln -sfn "${APP_PATH}/shared/pub/media" "${RELEASE_DIR}/pub/media"
        ln -sfn "${APP_PATH}/shared/var/log" "${RELEASE_DIR}/var/log"
        cp "${APP_PATH}/shared/app/etc/env.php" "${RELEASE_DIR}/app/etc/env.php"

        # Run Magento release steps on new release directory
        cd "${RELEASE_DIR}"
        php bin/magento setup:static-content:deploy de_DE -f -j 4
        php bin/magento cache:flush

        # Atomic symlink switch — this is the actual "deploy" moment
        ln -sfn "${RELEASE_DIR}" "${APP_PATH}/current"

        # Keep last 5 releases, remove older ones
        ls -dt "${APP_PATH}/releases/"* | tail -n +6 | xargs rm -rf
      DEPLOY
  only:
    - tags

5. Magento-Besonderheiten: Cache, Sessions, Datenbank

Magento hat Besonderheiten, die bei der Wahl der Deployment-Strategie berücksichtigt werden müssen. Der Magento-Cache ist in Redis oder Filesystem gespeichert und wird von der Anwendung unabhängig vom Release-Verzeichnis verwaltet. Bei einem Symlink-Wechsel zeigen alle Anfragen sofort auf das neue Release, aber der Redis-Cache enthält noch Daten aus dem alten Release-Format. Das ist ein Grund, warum cache:flush vor dem Symlink-Wechsel ausgeführt werden sollte – nicht danach.

Sessions sind ein komplexerer Fall. Magento speichert Sessions in Redis oder in Datenbankabellen. Laufende Benutzersitzungen überstehen einen Symlink-Wechsel problemlos, wenn das neue Release die Sitzungsstruktur nicht gebrochen hat. Bei Blue/Green-Deployments ist die Situation ähnlich: Wenn der Traffic-Wechsel passiert, haben laufende Requests aus der Blue-Umgebung noch aktive Sessions. Das gemeinsame Redis-Backend sorgt dafür, dass diese Sessions auch in der Green-Umgebung gültig sind – vorausgesetzt, das Datenformat hat sich nicht geändert.

Die Datenbank ist der dritte kritische Punkt. Beide Deployment-Strategien teilen sich eine gemeinsame MySQL-Instanz. Datenbankmigrationen via setup:upgrade sind weder bei Symlink-Releases noch bei Blue/Green wirklich isoliert – sie gelten sofort für alle Umgebungen. Der Unterschied: Bei Symlink-Releases ist das explizit Teil der Deploy-Sequenz. Bei Blue/Green entsteht die Illusion von Isolation, die aber für geteilte Datenbankressourcen nicht gilt.

6. Symlink-Release in GitLab CI implementieren

Die Implementierung eines vollständigen Symlink-Release-Prozesses in GitLab CI braucht drei Dinge: die korrekte Verzeichnisstruktur auf dem Server, ein Deploy-Skript, das den Symlink-Wechsel durchführt, und einen Rollback-Job in der Pipeline. Die Serverstruktur wird einmalig eingerichtet: mkdir -p /var/www/magento/{releases,shared/{pub/media,var/{log,session},app/etc}}. Das shared/-Verzeichnis enthält alle Dateien, die über Releases hinweg persistent sind.

Der kritische Schritt ist die Reihenfolge der Operationen: Artefakt auspacken, Shared-Links setzen, Magento-spezifische Schritte ausführen (SCD, setup:upgrade wenn nötig), cache:flush, und erst dann den Symlink wechseln. Nach dem Symlink-Wechsel empfangen neue Requests das neue Release, aber der Webserver muss nicht neu gestartet werden. PHP-FPM und Nginx/Apache lesen den Symlink bei jedem Request neu auf – der Wechsel ist sofort wirksam.

7. Wann Blue/Green für Magento sinnvoll wird

Blue/Green wird für Magento-Shops sinnvoll, wenn mehrere Bedingungen gleichzeitig erfüllt sind: Es gibt mehr als einen Web-Node, einen Load Balancer, der programmierbar umgeschaltet werden kann, und ein Team, das die doppelte Infrastruktur betreiben kann. Darüber hinaus ist Blue/Green attraktiv bei Shops mit extrem hohem Traffic, bei denen auch ein kurzes Fenster von Requests auf ein halb-deployed Release inakzeptabel ist.

Ein weiterer Anwendungsfall für Blue/Green: Datenbankmigrationen, die nicht rückwärtskompatibel sind. Bei Symlink-Releases muss das neue Release mit dem alten Datenbankschema kompatibel sein, bis der Symlink gewechselt wird (Expand/Contract-Muster). Bei Blue/Green kann die Migration in der inaktiven Umgebung durchgeführt und getestet werden, bevor der Traffic wechselt. Dieser Vorteil gilt allerdings nur, wenn die Datenbank nicht geteilt wird – was in Magento-Setups mit einer gemeinsamen MySQL-Instanz ohnehin der Fall ist.

7b. Webserver-Konfiguration für Symlink-Releases

Ein häufig übersehener Aspekt bei Symlink-Releases ist die Nginx-Konfiguration. Der root-Pfad im Nginx-Server-Block muss auf /var/www/magento/current/pub zeigen – auf den Symlink, nicht auf ein festes Release-Verzeichnis. Nginx folgt dem Symlink bei jedem Request, sodass ein Symlink-Wechsel sofort wirksam ist ohne Nginx-Reload. Das gilt auch für PHP-FPM: Der fastcgi_param SCRIPT_FILENAME Parameter enthält den über den Symlink aufgelösten Pfad, den PHP-FPM korrekt verarbeitet.

Ein wichtiges Detail für Nginx mit realpath-Auflösung: Manche Nginx-Konfigurationen aktivieren root_path-Caching, was dazu führt, dass Nginx den Symlink nur einmal auflöst und danach den alten Pfad verwendet. Für Symlink-Releases muss sichergestellt sein, dass Nginx den Symlink bei jedem Request neu auflöst – oder ein kurzer Nginx-Reload nach dem Symlink-Wechsel ist explizit Teil der Deploy-Sequenz. Die meisten Standard-Nginx-Konfigurationen folgen Symlinks dynamisch, aber gerade bei gehärteten Konfigurationen sollte dieser Punkt explizit getestet werden.

Ein einfacher Test nach dem ersten Symlink-Wechsel: Den aktuellen Symlink-Pfad in der Nginx-Konfiguration als statische root-Direktive setzen und dann auf einen neuen Release-Pfad wechseln. Wenn Nginx anschließend noch immer die alte Version ausliefert, ist Symlink-Caching aktiv und ein explizites nginx -s reload muss in die Deploy-Sequenz aufgenommen werden. Dieser Test dauert zwei Minuten und verhindert ein schwer diagnostizierbares Problem in der Produktion.

Für Apache-Webserver gilt dasselbe Prinzip: AllowOverride All und Options +FollowSymLinks müssen gesetzt sein, damit Apache Symlinks aus dem Magento-Verzeichnis verfolgt. Ohne diese Einstellung liefert Apache 403-Fehler für Requests, die über einen Symlink-Pfad aufgelöst werden. Beide Webserver-Optionen sollten einmalig beim Server-Setup überprüft und dokumentiert werden, damit beim Aufbau neuer Server keine Symlink-Konfigurationsprobleme entstehen.

8. Shared-Verzeichnisse in beiden Modellen

Das Shared-Konzept ist in beiden Deployment-Modellen notwendig. Bei Symlink-Releases ist es ein physisches shared/-Verzeichnis auf dem Server, aus dem mit Symlinks auf die Release-Verzeichnisse verwiesen wird. Die Dateien existieren einmal, werden aber von jedem Release-Verzeichnis genutzt. Bei Blue/Green ist das Shared-Konzept auf Infrastrukturebene gelöst: Beide Umgebungen teilen sich dieselben persistenten Volumes für pub/media/, und beide verbinden sich zur selben Datenbank und Redis-Instanz.

Das gemeinsame Problem beider Modelle: app/etc/env.php ist umgebungsspezifisch und muss in jedes Release-Verzeichnis kopiert oder verlinkt werden. Bei Symlink-Releases wird sie aus dem shared/-Verzeichnis kopiert. Bei Blue/Green kann sie als Datei in einem gemeinsamen Volume liegen oder über eine Secrets-Management-Lösung dynamisch erzeugt werden. Die Datei darf niemals im Repository oder im Artefakt landen – das gilt für beide Deployment-Strategien gleichermaßen.

9. Vergleich: Blue/Green vs. Symlink für Magento

Die Tabelle bestätigt die Grundaussage: Für die überwiegende Mehrheit der Magento-Shops ist das Symlink-Release-Modell die richtige Wahl. Es erreicht dieselbe Rollback-Geschwindigkeit wie Blue/Green, erfordert aber einen Bruchteil des Infrastrukturaufwands. Blue/Green sollte nur gewählt werden, wenn die Infrastruktur ohnehin mehrere Web-Nodes und einen programmierbaren Load Balancer umfasst.

10. Zusammenfassung

Die Wahl zwischen Blue/Green und Symlink-Releases ist für Magento-Shops in den meisten Fällen keine echte Abwägung: Symlink-Releases bieten Zero-Downtime-fähige Deployments mit sekunden-schnellem Rollback bei minimalem Infrastrukturaufwand. Blue/Green fügt erhebliche Komplexität hinzu, ohne für Einzelserver-Setups einen echten Mehrwert zu liefern. Die Rollback-Zeiten sind praktisch identisch; der Unterschied liegt in der Infrastruktur, nicht im Ergebnis.

Wer Symlink-Releases konsequent umsetzt – mit einer korrekten releases/shared/current-Struktur, atomaren Symlink-Wechseln und einem getesteten Rollback-Skript – hat einen Deployment-Prozess, der zuverlässiger ist als manches Blue/Green-Setup, das nie für einen echten Fehlerfall geübt wurde. Die beste Deployment-Strategie ist die, die das Team versteht, regelmäßig übt und im Ernstfall in Sekunden ausführen kann. Beide Ansätze verlangen dasselbe: Vorbereitung, Dokumentation und regelmäßige Übung des Rollback-Pfads – nicht erst bei einem produktiven Fehler.

Ein konkreter Tipp für Teams, die noch kein Deployment-Modell etabliert haben: Mit Symlink-Releases anfangen, die Struktur einmal sauber aufbauen und dann drei Deployments konsequent nach demselben Schema durchführen. Nach diesen drei Deployments ist das Modell verstanden, geübt und vertrauenswürdig. Blue/Green kann als Erweiterung hinzukommen, wenn die Infrastruktur es erfordert – aber das Fundament, das Symlink-Releases legen, bleibt auch dann gültig.

Die Reife eines Deployment-Prozesses zeigt sich nicht im ersten erfolgreichen Deployment, sondern im ersten schnellen Rollback unter Druck. Teams, die ihren Rollback-Pfad monatlich testen – zum Beispiel durch geplante Rollback-Übungen auf Staging – bauen das Vertrauen auf, das im echten Fehlerfall den Unterschied zwischen Panik und Routine ausmacht. Diese Übung kostet fünf Minuten und spart im Ernstfall Stunden.

11. FAQ: Blue/Green vs. Symlink-Releases für Magento

Blue-Green und Symlink-Switch schließen sich nicht aus — in reifen Umgebungen kombiniert man beide Ansätze: ein Symlink-Switch als atomare Operation innerhalb eines der beiden Blue-Green-Slots sorgt für maximale Flexibilität bei minimalem Deployment-Risiko.

Wer mit einem einfachen Symlink-Modell startet, hat immer noch die Option, später auf Blue-Green zu migrieren — die Investition in eine saubere Release-Struktur zahlt sich in beiden Deployment-Modellen aus.