Blue-Green-Deployment für Magento: Downtime-freie Releases

1. Was Blue-Green-Deployment bedeutet und warum klassisches Magento-Deployment Downtime verursacht

Blue-Green-Deployment bezeichnet ein Architekturmuster, bei dem zwei vollständig identische Produktionsumgebungen parallel betrieben werden, üblicherweise als "Blue" und "Green" bezeichnet. Zu jedem Zeitpunkt bedient genau eine der beiden Umgebungen den echten Kundenverkehr, während die andere für das nächste Release vorbereitet wird. Ist die neue Version fertig deployt, getestet und über Health-Checks verifiziert, schwenkt ein Load-Balancer den gesamten Traffic in einem einzigen, nahezu atomaren Schritt von der alten auf die neue Umgebung um. Für den Kunden im Browser gibt es dabei keinen erkennbaren Übergang, keine Wartungsseite und keine abgebrochene Session.

Klassisches Magento-Deployment läuft dagegen sequenziell auf derselben Umgebung ab: bin/magento setup:upgrade sperrt Tabellen während der Schema-Migration, setup:di:compile und setup:static-content:deploy benötigen mehrere Minuten, in denen der bestehende generierte Code teilweise überschrieben wird, und ein Neustart von PHP-FPM oder Nginx unterbricht laufende Requests. Selbst mit Wartungsmodus (bin/magento maintenance:enable) bedeutet das für Kunden eine sichtbare Downtime von mehreren Minuten bis zu einer halben Stunde, je nach Shop-Größe und Anzahl der Module. Bei Shops mit internationalem Traffic rund um die Uhr ist jedes Wartungsfenster ein direkter Umsatzverlust.

Blue-Green-Deployment löst genau dieses Problem, indem die riskante Phase, nämlich das Deployment selbst, komplett von der sichtbaren Traffic-Umschaltung getrennt wird. Die neue Version wird in aller Ruhe auf der inaktiven Umgebung installiert, kompiliert und getestet, ohne dass ein einziger Live-Request davon betroffen ist. Erst wenn alles nachweislich funktioniert, erfolgt der Switch, der im Erfolgsfall Millisekunden dauert. Damit unterscheidet sich das Verfahren fundamental von einem Rolling Deployment, bei dem einzelne Server nacheinander aktualisiert werden und für kurze Zeit zwei Versionen gleichzeitig Anfragen beantworten.

2. Infrastruktur-Voraussetzungen: zwei identische Produktionsumgebungen und der Traffic-Switch

Die Grundvoraussetzung für Blue-Green-Deployment ist echte Identität zwischen beiden Umgebungen: gleiche PHP-Version, gleiche Nginx-Konfiguration, gleiche PHP-Extensions, gleiche Ressourcenlimits und idealerweise dieselbe Container-Basis. Unterschiede zwischen Blue und Green sind die häufigste Fehlerquelle in der Praxis, weil ein Bug dann nur in einer der beiden Umgebungen auftritt und schwer reproduzierbar ist. In der Regel wird das über Infrastructure-as-Code gelöst, etwa mit identischen Docker-Images oder Ansible-Playbooks, die beide Umgebungen aus derselben Definition erzeugen.

Jede Umgebung braucht eigene Application-Server, aber beide teilen sich in der Regel dieselbe Datenbank und denselben Redis-Cluster, weil doppelte Datenbanken bei Bestellungen und Kundendaten zu Inkonsistenzen führen würden. Der Traffic-Switch selbst wird typischerweise auf Ebene eines Load-Balancers oder Reverse-Proxys realisiert: Nginx-Upstream-Blöcke, ein HAProxy-Backend-Wechsel oder ein DNS-basiertes Routing bei Cloud-Load-Balancern. Wichtig ist, dass der Switch atomar erfolgt, also nicht schrittweise Server für Server, sondern als einzelne Konfigurationsänderung, die per nginx -s reload ohne Verbindungsabbruch übernommen wird.

Ein oft unterschätzter Punkt: Beide Umgebungen müssen dieselben externen Abhängigkeiten erreichen können, etwa Zahlungsanbieter-Webhooks, Fulfillment-APIs oder das ERP-System. Wenn ein Webhook nur die IP-Adresse der aktuell aktiven Umgebung kennt, muss diese Konfiguration beim Blue-Green-Deployment-Switch mit umgezogen werden, sonst laufen eingehende Callbacks nach dem Wechsel ins Leere.

# /etc/nginx/conf.d/upstream.conf
# Blue-Green upstream definition: only the active block is enabled

upstream magento_blue {
    server 10.0.1.11:8080 max_fails=2 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=2 fail_timeout=10s;
    keepalive 32;
}

upstream magento_green {
    server 10.0.2.11:8080 max_fails=2 fail_timeout=10s;
    server 10.0.2.12:8080 max_fails=2 fail_timeout=10s;
    keepalive 32;
}

# The active pointer: swapped by the deploy script, then reloaded
map $host $active_upstream {
    default magento_green;   # currently live environment
}

server {
    listen 443 ssl http2;
    server_name shop.example.com;

    location / {
        proxy_pass http://$active_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

3. Datenbank-Migrationen kompatibel halten: das Expand-Contract-Pattern in db_schema.xml

Weil Blue und Green sich dieselbe Datenbank teilen, ist die größte technische Herausforderung beim Blue-Green-Deployment nicht der Traffic-Switch, sondern die Datenbank-Migration. Ein db_schema.xml-Update, das eine Spalte umbenennt oder eine bestehende Spalte löscht, würde die noch aktive alte Umgebung sofort zerstören, weil deren Code noch auf die alte Spaltenstruktur zugreift. Die Lösung ist das Expand-Contract-Pattern, auch als Parallel-Change bekannt: Jede Schemaänderung wird in additive und destruktive Schritte aufgeteilt, die in getrennten Releases ausgerollt werden.

In der Expand-Phase wird ausschließlich hinzugefügt: eine neue Spalte, ein neuer Index, eine neue Tabelle. Der alte Code ignoriert die neue Spalte einfach, der neue Code schreibt sowohl in die alte als auch in die neue Spalte oder liest bevorzugt aus der neuen mit Fallback auf die alte. Erst wenn die alte Umgebung nach mehreren erfolgreichen Blue-Green-Deployment-Zyklen sicher nicht mehr aktiv geschaltet wird, folgt die Contract-Phase, in der die alte Spalte per separatem db_schema.xml-Update entfernt wird. Zwischen Expand und Contract sollten mindestens ein bis zwei vollständige Release-Zyklen liegen.

Auch Datentyp-Änderungen folgen diesem Muster: Statt eine Spalte direkt von varchar auf int zu ändern, wird eine neue Spalte mit dem Zieltyp angelegt, ein Data-Patch synchronisiert die Werte, und erst nach vollständiger Umstellung des Codes auf die neue Spalte wird die alte entfernt. bin/magento setup:db-declaration:generate-whitelist hilft dabei, jede Schemaänderung nachvollziehbar in der db_schema_whitelist.json zu dokumentieren, was bei einem Blue-Green-Deployment mit mehreren parallelen Release-Branches zusätzliche Sicherheit gibt.

<!-- app/code/Mironsoft/CustomerLoyalty/etc/db_schema.xml -->
<!-- Expand phase: add new column, keep old one untouched -->
<schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Setup/Declaration/Schema/etc/schema.xsd">
    <table name="customer_loyalty_points">
        <!-- Legacy column, still read by the currently active environment -->
        <column xsi:type="int" name="points_balance" nullable="false" default="0"
                comment="Legacy points balance column, scheduled for removal"/>

        <!-- New column added in the expand step, additive only -->
        <column xsi:type="decimal" name="points_balance_v2" scale="4" precision="12"
                nullable="false" default="0.0000"
                comment="New decimal points balance, dual-written during migration"/>

        <index referenceId="CUSTOMER_LOYALTY_POINTS_V2" indexType="btree">
            <column name="points_balance_v2"/>
        </index>
    </table>
</schema>

<!-- Contract phase: separate release, only after all traffic
     has run against the new column for at least one full cycle -->
<!--
<table name="customer_loyalty_points">
    <column xsi:type="int" name="points_balance" nullable="false" default="0" disabled="true"/>
</table>
-->

4. Geteilter State zwischen Blue und Green: Redis-Sessions, Cache-Backend, Message Queue

Ein häufiger Denkfehler beim Blue-Green-Deployment ist die Annahme, beide Umgebungen müssten komplett isoliert sein. Für Session-Daten gilt das Gegenteil: Sessions liegen bei Magento in Redis (session.save = redis), und dieser Redis-Cluster muss von Blue und Green gleichermaßen erreichbar sein. Würde jede Umgebung ihren eigenen Session-Store betreiben, würde jeder Traffic-Switch alle eingeloggten Kunden ausloggen und alle Warenkörbe verwerfen, was das gesamte Ziel des Zero-Downtime-Ansatzes zunichtemachen würde.

Beim Cache-Backend gilt eine differenziertere Regel. Der Full-Page-Cache und der Objekt-Cache können sich denselben Redis-Server teilen, solange Cache-Keys versionsspezifisch invalidiert werden können, denn eine neue Codeversion serialisiert Objekte teilweise anders als die alte. Magento löst das über den Konfigurationswert id_prefix im env.php, der pro Umgebung oder pro Deployment-Version unterschiedlich gesetzt werden sollte, damit Blue und Green niemals denselben Cache-Eintrag mit inkompatibler Struktur lesen. Nach jedem Blue-Green-Deployment-Switch ist ein gezieltes bin/magento cache:flush auf der neu aktiven Umgebung sinnvoll, um veraltete Fragmente sicher auszuschließen.

Message-Queue-Consumer, etwa für asynchrone Order-Verarbeitung über RabbitMQ, laufen unabhängig von der aktiven Web-Umgebung weiter und sollten idealerweise auf beiden Umgebungen gleichzeitig konsumieren können, sofern die Nachrichtenverarbeitung idempotent implementiert ist. Ist das nicht der Fall, muss der Consumer-Prozess Teil des Traffic-Switches sein: Erst wird der alte Consumer sauber beendet (bin/magento queue:consumers:stop beziehungsweise Signal-Handling im Consumer selbst), dann startet der neue auf der frisch aktivierten Umgebung.

5. Suchindex ohne Downtime umschalten: Elasticsearch/OpenSearch Index-Alias-Strategie

Der Produktkatalog-Suchindex ist einer der komplexesten Bestandteile eines Blue-Green-Deployment-Setups, weil eine vollständige Reindizierung mehrere Minuten bis Stunden dauern kann und währenddessen niemals ein halbfertiger Index live geschaltet werden darf. Magento löst dieses Problem bereits im Standard-Indexer-Modus schedule mit einer eigenen Alias-Strategie: Bei jedem Full-Reindex wird ein komplett neuer physischer Index angelegt, etwa magento2_product_1_v123, während der Alias magento2_product_1 weiterhin auf den alten, funktionsfähigen Index zeigt.

Erst wenn der neue Index vollständig befüllt und validiert ist, verschiebt Magento den Alias atomar per Elasticsearch- beziehungsweise OpenSearch-API auf den neuen physischen Index, und der alte wird anschließend gelöscht. Für ein Blue-Green-Deployment bedeutet das: Solange beide Umgebungen denselben Elasticsearch-Cluster und damit denselben Alias verwenden, funktioniert die Indexumschaltung unabhängig vom Web-Traffic-Switch. Kritisch wird es nur, wenn ein neues Release das Such-Schema ändert, etwa neue Facetten-Attribute oder ein geändertes Mapping einführt: Dann muss auch hier das Expand-Contract-Prinzip greifen, indem der alte Code mit dem alten Mapping kompatibel bleibt, bis die Contract-Phase erreicht ist.

In der Praxis empfiehlt sich, den Indexer-Modus konsequent auf schedule zu belassen und die Reindizierung über den Cron des bin/magento cron:run laufen zu lassen, statt sie manuell im Deploy-Skript mit reindex im Modus realtime auszulösen. So bleibt die alte Umgebung bis zum eigentlichen Blue-Green-Deployment-Switch voll funktionsfähig, während im Hintergrund bereits der Index für die neue Version aufgebaut wird.

6. Static-Content-Deployment und Build-Pipeline für beide Umgebungen parallel

Statische Assets wie kompiliertes CSS, JavaScript und die generierten di.xml-Interceptor-Klassen müssen für jede Umgebung vollständig und unabhängig gebaut werden, bevor der Blue-Green-Deployment-Switch stattfindet. Der Befehl bin/magento setup:static-content:deploy de_DE -t Mironsoft/default -f läuft komplett auf der inaktiven Umgebung, während die aktive weiterhin ihre eigenen, unveränderten statischen Dateien ausliefert. Genau diese Trennung ist der Kern der Downtime-Freiheit: Es gibt keinen Moment, in dem pub/static auf der aktiven Umgebung halb alt, halb neu ist.

Für Hyvä-Themes kommt zusätzlich der Tailwind-Build hinzu, der ebenfalls vollständig vor dem Switch abgeschlossen sein muss: bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build erzeugt das finale CSS, das anschließend Teil des setup:static-content:deploy-Laufs wird. Da beide Umgebungen dieselbe Codebasis, aber unterschiedliche generierte Verzeichnisse (var/view_preprocessed, generated/code) besitzen, empfiehlt es sich, vor jedem Blue-Green-Deployment diese Verzeichnisse auf der Zielumgebung vollständig zu leeren, um Reste einer älteren Kompilierung auszuschließen.

Ein CDN vor beiden Umgebungen sollte Assets über versionierte Pfade oder Query-Strings ausliefern, damit ein Browser-Cache aus der Blue-Phase nicht versehentlich veraltete Assets an Kunden liefert, die gerade auf die Green-Umgebung umgeschaltet wurden. Magentos Magento_Deploy-Modul setzt dafür standardmäßig einen Content-Version-Hash im Static-Content-Pfad, der sich bei jedem Deployment ändert und damit automatisch für saubere Cache-Invalidierung sorgt.

7. Der Traffic-Switch-Mechanismus: Load-Balancer/Nginx-Upstream-Wechsel und Health-Checks vor der Umschaltung

Der eigentliche Traffic-Switch ist der kritischste Moment im gesamten Blue-Green-Deployment-Prozess, weil er den Punkt ohne Rückweg markiert, ab dem echte Kunden die neue Version sehen. Deshalb darf der Switch niemals blind erfolgen, sondern nur nachdem ein automatisierter Health-Check-Endpunkt auf der neuen Umgebung mehrfach hintereinander erfolgreich geantwortet hat. Ein solcher Endpunkt sollte mehr prüfen als nur "PHP antwortet": Datenbankverbindung, Redis-Erreichbarkeit, Elasticsearch-Status und die Existenz der kompilierten di.xml-Klassen gehören in jeden ernsthaften Health-Check.

<?php
declare(strict_types=1);

namespace Mironsoft\DeployHealth\Controller\Health;

use Magento\Framework\App\Action\HttpGetActionInterface;
use Magento\Framework\App\ResponseInterface;
use Magento\Framework\Controller\Result\JsonFactory;
use Magento\Framework\Controller\ResultInterface;
use Magento\Framework\App\ResourceConnection;
use Magento\Framework\App\Cache\Type\FrontendPool;

/**
 * Health check endpoint used to gate the blue-green traffic switch.
 * Verifies database, cache backend and compiled code before a deploy
 * script is allowed to flip the active upstream.
 */
final class Check implements HttpGetActionInterface
{
    /**
     * @param JsonFactory $resultJsonFactory Factory for JSON result responses.
     * @param ResourceConnection $resourceConnection Database connection resource.
     * @param FrontendPool $cacheFrontendPool Cache frontend pool for backend checks.
     */
    public function __construct(
        private readonly JsonFactory $resultJsonFactory,
        private readonly ResourceConnection $resourceConnection,
        private readonly FrontendPool $cacheFrontendPool,
    ) {
    }

    /**
     * Executes all readiness checks and returns a JSON status payload.
     *
     * @return ResultInterface JSON response with overall status and per-check details.
     */
    public function execute(): ResultInterface
    {
        $checks = [
            'database' => $this->checkDatabase(),
            'cache' => $this->checkCache(),
            'generated_code' => $this->checkGeneratedCode(),
        ];

        $healthy = !in_array(false, $checks, true);
        $result = $this->resultJsonFactory->create();
        $result->setHttpResponseCode($healthy ? 200 : 503);

        return $result->setData(['healthy' => $healthy, 'checks' => $checks]);
    }

    /**
     * Verifies the primary database connection responds to a trivial query.
     *
     * @return bool True when the connection is reachable.
     */
    private function checkDatabase(): bool
    {
        try {
            $connection = $this->resourceConnection->getConnection();
            return (bool) $connection->fetchOne('SELECT 1');
        } catch (\Throwable) {
            return false;
        }
    }

    /**
     * Verifies the configured cache backend accepts read and write operations.
     *
     * @return bool True when the cache backend is reachable.
     */
    private function checkCache(): bool
    {
        try {
            $frontend = $this->cacheFrontendPool->get('default');
            $frontend->getBackend()->save('ok', 'deploy_health_probe', [], 30);
            return $frontend->getBackend()->load('deploy_health_probe') === 'ok';
        } catch (\Throwable) {
            return false;
        }
    }

    /**
     * Verifies that compiled DI classes exist for the new deployment.
     *
     * @return bool True when the generated code directory is populated.
     */
    private function checkGeneratedCode(): bool
    {
        return is_dir(BP . '/generated/code/Magento') && (count(scandir(BP . '/generated/code/Magento') ?: []) > 2);
    }
}

Erst wenn dieser Health-Check über mehrere Iterationen stabil grün ist, führt das Deploy-Skript den eigentlichen Nginx-Upstream-Wechsel aus. Der Wechsel selbst ändert nur den Wert der map-Direktive und führt anschließend ein nginx -s reload aus, das bestehende Verbindungen sauber ausklingen lässt, statt sie hart zu kappen. Genau dieser Health-Check-gate-Mechanismus ist es, der ein Blue-Green-Deployment von einem riskanten, manuellen Umschalten unterscheidet.

#!/usr/bin/env bash
# deploy-switch.sh: health-check-gated blue-green traffic switch
set -euo pipefail

readonly TARGET_ENV="${1:?Usage: deploy-switch.sh blue|green}"
readonly HEALTH_URL="http://${TARGET_ENV}-internal.example.com/health/check"
readonly MAX_ATTEMPTS=10
readonly SLEEP_SECONDS=5

echo "[INFO] Gating switch to ${TARGET_ENV} on health check success"

attempt=1
while (( attempt <= MAX_ATTEMPTS )); do
  status_code="$(curl -s -o /dev/null -w '%{http_code}' "$HEALTH_URL" || echo '000')"
  if [[ "$status_code" == "200" ]]; then
    echo "[OK] Health check passed on attempt ${attempt}"
    break
  fi
  echo "[WAIT] Attempt ${attempt}/${MAX_ATTEMPTS} returned ${status_code}"
  attempt=$((attempt + 1))
  sleep "$SLEEP_SECONDS"
done

if (( attempt > MAX_ATTEMPTS )); then
  echo "[ABORT] ${TARGET_ENV} never reported healthy, switch cancelled" >&2
  exit 1
fi

echo "[INFO] Flipping active upstream to magento_${TARGET_ENV}"
sed -i "s/default magento_.*/default magento_${TARGET_ENV};/" /etc/nginx/conf.d/upstream.conf
nginx -t && nginx -s reload

echo "[DONE] Traffic switched to ${TARGET_ENV}, previous environment kept warm for rollback"

8. Rollback-Strategie: sofortiger Rückschwenk auf die vorherige Umgebung bei Fehlern

Der größte praktische Vorteil eines Blue-Green-Deployment gegenüber jeder anderen Deployment-Strategie ist die Rollback-Geschwindigkeit. Weil die vorherige Umgebung nach dem Switch nicht sofort abgeschaltet, sondern für einen definierten Zeitraum warmgehalten wird, bedeutet ein Rollback lediglich einen zweiten Traffic-Switch in die entgegengesetzte Richtung. Es ist kein erneutes Deployment, kein Wiederherstellen aus einem Backup und kein manuelles Debugging unter Zeitdruck notwendig, um den Shop wieder online zu bringen.

Damit dieser Rollback tatsächlich funktioniert, müssen zwei Bedingungen erfüllt sein: Erstens darf die Contract-Phase einer Datenbank-Migration erst erfolgen, nachdem mehrere Blue-Green-Deployment-Zyklen ohne Rollback verlaufen sind, denn ein Rückschwenk auf Code, der eine bereits gelöschte Spalte erwartet, würde sofort scheitern. Zweitens müssen Monitoring und Alerting scharf genug eingestellt sein, um Fehler innerhalb von Sekunden nach dem Switch zu erkennen, etwa über Fehlerraten-Schwellenwerte in New Relic oder Grafana, kombiniert mit synthetischen Checkout-Transaktionen, die den kompletten Bestellprozess automatisiert durchlaufen.

In der Praxis definiert man ein Zeitfenster, üblicherweise 15 bis 60 Minuten nach jedem Blue-Green-Deployment, in dem die alte Umgebung aktiv überwacht und nicht heruntergefahren wird. Erst nach Ablauf dieses Fensters ohne Auffälligkeiten wird die alte Umgebung für das nächste Release wiederverwendet oder bewusst zurückgesetzt. Bestellungen, die während dieses Fensters auf der neuen Umgebung eingehen, bleiben auch nach einem Rollback in der gemeinsamen Datenbank korrekt erhalten, da Datenbank und Redis ja nicht Teil des Switches sind.

9. CI/CD-Integration: ein automatisierter Blue-Green-Workflow in der Pipeline

Ohne Automatisierung bleibt Blue-Green-Deployment ein theoretisches Konzept, das in der Praxis an manuellen Fehlern scheitert. Eine CI/CD-Pipeline, etwa in GitLab CI, sollte den kompletten Ablauf abbilden: Zielumgebung ermitteln, Code deployen, Migrationen ausführen, Health-Check abwarten, Traffic switchen und im Fehlerfall automatisch zurückschwenken. Jeder dieser Schritte sollte als eigener, wiederholbarer Pipeline-Job modelliert sein, damit ein fehlgeschlagener Schritt die Pipeline sauber stoppt, statt in einem inkonsistenten Zwischenzustand zu enden.

Ein zentraler Baustein ist die Ermittlung, welche Umgebung gerade inaktiv ist, damit die Pipeline automatisch weiß, wohin deployt werden muss. Das lässt sich über einen einfachen Abgleich mit der aktuellen Nginx-Konfiguration oder über eine kleine State-Datei in einem gemeinsam genutzten Object-Storage lösen. Erst nach erfolgreichem Deployment auf die inaktive Umgebung und bestandenem Health-Check ruft die Pipeline denselben deploy-switch.sh auf, der auch für manuelle Blue-Green-Deployment-Wechsel verwendet wird, damit Automatisierung und manueller Eingriff exakt denselben Codepfad nutzen.

Post-Deployment-Jobs wie automatisierte Smoke-Tests gegen die neu aktive Umgebung und eine Slack-Benachrichtigung mit Rollback-Link runden den Workflow ab. So bleibt jedes Blue-Green-Deployment nachvollziehbar dokumentiert, und ein Rollback ist für das Team jederzeit mit einem einzigen Klick oder Pipeline-Trigger auslösbar, ohne dass jemand die genaue Sequenz der Befehle im Kopf haben muss.

# .gitlab-ci.yml: automated blue-green rollout for Magento
stages:
  - determine-target
  - deploy
  - migrate
  - health-check
  - switch
  - smoke-test

determine-target:
  stage: determine-target
  script:
    - ./ci/determine-inactive-environment.sh > target.env
  artifacts:
    reports:
      dotenv: target.env

deploy-to-target:
  stage: deploy
  needs: ["determine-target"]
  script:
    - ssh deploy@${TARGET_ENV}-host "cd /var/www/magento && git pull origin main"
    - ssh deploy@${TARGET_ENV}-host "bin/composer install --no-dev -o"
    - ssh deploy@${TARGET_ENV}-host "bin/magento setup:di:compile"
    - ssh deploy@${TARGET_ENV}-host "bin/magento setup:static-content:deploy de_DE -f"

run-migrations:
  stage: migrate
  needs: ["deploy-to-target"]
  script:
    - ssh deploy@${TARGET_ENV}-host "bin/magento setup:upgrade --keep-generated"

wait-for-health:
  stage: health-check
  needs: ["run-migrations"]
  script:
    - ./ci/wait-for-health.sh "${TARGET_ENV}"

switch-traffic:
  stage: switch
  needs: ["wait-for-health"]
  script:
    - ./ci/deploy-switch.sh "${TARGET_ENV}"
  when: on_success

smoke-test:
  stage: smoke-test
  needs: ["switch-traffic"]
  script:
    - ./ci/checkout-smoke-test.sh
  after_script:
    - if [ "$CI_JOB_STATUS" == "failed" ]; then ./ci/rollback-switch.sh; fi

10. Zusammenfassung

Blue-Green-Deployment für Magento löst das Downtime-Problem klassischer Releases, indem zwei identische Produktionsumgebungen parallel betrieben werden und ein kontrollierter Traffic-Switch den Kundenverkehr in Millisekunden zwischen ihnen umschaltet. Die technische Kernarbeit steckt nicht im Switch selbst, sondern in der Kompatibilität: Datenbank-Migrationen folgen dem Expand-Contract-Pattern in db_schema.xml, Sessions und Cache liegen in gemeinsam genutztem Redis, und der Elasticsearch-Suchindex wird über Alias-Umschaltung unabhängig vom Web-Traffic aktualisiert.

Static-Content-Deployment und der Tailwind-Build für Hyvä-Themes laufen vollständig auf der inaktiven Umgebung, bevor ein Health-Check-Endpunkt den Switch freigibt. Genau dieser Health-Check-gate-Mechanismus, kombiniert mit einer warmgehaltenen vorherigen Umgebung, macht Rollbacks bei einem Blue-Green-Deployment zu einer Sache von Sekunden statt Stunden. Eine automatisierte CI/CD-Pipeline bildet den gesamten Ablauf, von der Zielumgebungs-Ermittlung bis zum automatischen Rückschwenk bei fehlgeschlagenen Smoke-Tests, reproduzierbar ab und macht Zero-Downtime-Releases für Magento-Shops zur Routine statt zur Ausnahme.

11. FAQ: Blue-Green-Deployment für Magento