Seite 2 - GitLab

Ein eigener GitLab Runner gibt Teams volle Kontrolle über Build-Umgebung, Sicherheit und Zugriffspfade. Dieser Artikel erklärt die Installation auf Linux, die Registrierung mit Docker-Executor, Tags, Sicherheitseinstellungen und die Magento-spezifische Konfiguration — Schritt für Schritt und vollständig.

CI/CD Variables sind der Konfigurationsvertrag jeder GitLab-Pipeline. Wer SSH-Keys, Composer-Auth-Token und ENV-Dateien falsch hinterlegt, riskiert unsichere Secrets, gebrochene Builds und unklare Umgebungstrennung. Dieser Artikel zeigt, wie Variables in GitLab korrekt angelegt, gescopedt und in Pipelines sicher konsumiert werden.

Der Magento Maintenance Mode blockiert echte Nutzer. Wer ihn bei jedem Deploy aktiviert, zahlt Verfügbarkeit als Prozesssteuer. Dieser Artikel zeigt, wann er tatsächlich notwendig ist, wie er in GitLab CI korrekt integriert wird und wie eine saubere Release-Struktur ihn auf ein Minimum reduziert.

setup:upgrade ist der einzige Befehl im Magento-Deployment-Prozess, der die Produktionsdatenbank direkt verändert. Er läuft nicht im Build-Job, nicht als Test – er läuft auf dem Live-System. Wer diesen Schritt nicht absichert, baut einen Deployment-Prozess, der bei Datenbankmigrationen regelmäßig Glück braucht.

Ein composer install in CI, der manchmal andere Pakete installiert als erwartet, der bei jedem Run 200 Pakete neu herunterlädt, oder der auf Production andere Dependencies produziert als auf Staging – das sind lösbare Probleme. Dieser Artikel erklärt, wie composer install in GitLab CI reproduzierbar, schnell und korrekt ausgeführt wird.

Wer in Magento-Deployments Media, statische Assets und Build-Artefakte in denselben Topf wirft, macht Rollbacks gefährlich und Deployments langsam. Jede dieser drei Kategorien hat einen anderen Lebenszyklus, eine andere Ownership und eine andere Deployment-Strategie – das muss sich in der Pipeline-Struktur widerspiegeln.

Zehn Magento-Shops mit zehn identischen Pipeline-Dateien zu betreiben ist technische Schulden in Reinform. Jede Änderung am Deploy-Prozess muss zehnmal gemacht werden. GitLab-Templates mit include und extends lösen das Problem – ein zentraler Build-Standard, individuell erweiterbar pro Projekt.

Wer wahllos Verzeichnisse in GitLab-Artefakte packt, erhält aufgeblähte Pakete, nicht reproduzierbare Deployments und unnötige Serverrisiken. Die richtige Trennung von Build-Output, Shared-Daten und Server-State ist der Kern eines belastbaren Release-Prozesses für Magento.

Wenn die Pipeline nicht schnell genug ist, greifen Teams auf manuelle Deployments zurück. Das ist akzeptabel – aber nur, wenn dabei eine vollständige Dokumentation entsteht, ein Rollback-Pfad vorbereitet ist und der Hotfix danach sauber in den Normalprozess übertragen wird.

Der Symlink-Wechsel ist nicht das Ende eines Zero-Downtime-Deployments – er ist der Beginn einer kritischen Phase, in der Redis, RabbitMQ und OpenSearch mit dem neuen Code-Stand kompatibel sein müssen. Diese drei Dienste werden zu oft als Randdetails behandelt, obwohl sie häufig die Ursache von Post-Deploy-Fehlern sind.