Seite 6 - GitLab

Die Build-Stage ist der Grundstein des gesamten Deployment-Prozesses. Wer hier auf Serverabhängigkeiten setzt, einen undefinierten Node-Cache mitschleppt oder DI Compile auf der Produktionsmaschine ausführt, schafft Risiken, die später als Deployment-Probleme auftauchen. Eine saubere Build-Stage erzeugt ein vollständiges, server-unabhängiges Artefakt.

Laufende Cron-Jobs und Queue Consumer während eines Deployments sind eine unterschätzte Fehlerquelle. Ein Consumer, der im alten Release-Code läuft während der Symlink auf das neue Release wechselt, kann zu Datenkonsistenz-Problemen führen. Dieser Artikel erklärt, wie Cron und Consumer im GitLab-Deployment-Prozess zuverlässig kontrolliert werden.

Eine .gitlab-ci.yml, die nur drei Jobs hat und keine Stages definiert, ist kein Deployment-Prozess – sie ist ein Skript, das irgendwann bricht. Wer Magento sauber deployt, braucht eine vollständige Pipeline-Struktur: reproduzierbare Build-Artefakte, definierte Freigaben, serverseitige Release-Verzeichnisse, kontrollierte Magento-Schritte und einen fachlich abgeschlossenen Verify-Job.

Drei Wege, ein Ziel: Magento sicher auf den Server bringen. Shell-Skripte sind einfach, aber schwer wartbar. Deployer PHP kennt Release-Strukturen und Rollback. Ansible ist mächtig, aber overkill für viele Teams. Welcher Ansatz passt wann — und wie sieht das in einer GitLab-Pipeline aus?

Ein Release-Artefakt, das unbemerkt verändert wurde, ist gefährlicher als ein offensichtlich fehlgeschlagener Build. SHA256-Checksums, GPG-Signaturen und automatische Verifizierungsschritte in der GitLab-Pipeline schließen diese stille Angriffsfläche für Magento-Deployments.

Diese Anleitung deckt den vollständigen Weg ab: GitLab Runner einrichten, Pipeline Schritt für Schritt aufbauen, Release-Struktur auf dem Server anlegen, atomaren Symlink-Wechsel implementieren, Verify-Jobs konfigurieren und Rollback in Sekunden zuverlässig durchführen. Zero Downtime ist das Ergebnis dieser konkreten Entscheidungen.

Deployer PHP und GitLab CI/CD ergänzen sich für Magento-Deployments ideal: GitLab baut und testet, Deployer übernimmt die Release-Struktur, den Symlink-Wechsel und den Rollback-Pfad. Wer beide Werkzeuge richtig kombiniert, bekommt einen reproduzierbaren, teamfähigen Deployment-Prozess ohne Wartungsfenster-Roulette.

Code, der nicht getestet und nicht analysiert wird, akkumuliert stille Fehler. PHPUnit, PHPStan, PHPCS und composer audit als parallele GitLab-CI-Jobs gebündelt liefern nach jedem Commit Rückmeldung über Tests, Typsicherheit, Stil und bekannte Sicherheitslücken – automatisch und ohne manuellen Aufwand.

env.php gehört nicht ins Repository und nicht in den Build-Artefakt. Wer das missachtet, baut ein Release-Modell, das beim ersten Umgebungswechsel bricht. Dieser Beitrag erklärt, wie app/etc, Shared-Verzeichnisse und config.php korrekt im Symlink-Release-Modell mit GitLab CI/CD zusammenspielen.