GitLab

Bevor die erste Zeile der .gitlab-ci.yml geschrieben wird, müssen Repository, Default Branch, Branch Protection und Protected Tags korrekt konfiguriert sein. Diese Einstellungen sind der organisatorische Rahmen, der verhindert, dass technisch gute Pipelines durch schlechte Governance ausgehebelt werden.

Zero-Downtime-Deployments scheitern an keiner anderen Stelle so häufig wie an Datenbank-Migrationen. Eine Spalte umbenennen, eine Tabelle löschen, einen NOT NULL-Constraint hinzufügen – das sind Operationen, die mit laufendem Code nicht kompatibel sind. Dieser Artikel erklärt das Expand/Contract-Pattern, wann es funktioniert und wann ein Wartungsfenster die ehrlichere Antwort ist.

Wer Produktionsserver direkt aus GitLab-Runnern erreichbar macht, baut Angriffsfläche auf. SSH-Bastion-Server, Jump Hosts und dedizierte Deployment-User trennen Zugriffspfade sauber und machen Deployment-Verbindungen auditierbar, widerrufbar und ohne Personal-SSH-Keys umsetzbar.

Hyvä Themes bringt Tailwind CSS v4 als CSS-first-Build in Magento. Wer diesen Build in die GitLab-Pipeline integriert, muss Node.js-Versionen, npm-Caching, Artefakt-Übergabe und die Reihenfolge gegenüber dem PHP-Build sauber koordinieren. Dieser Artikel zeigt, wie das in der Praxis funktioniert.

setup:di:compile ist einer der zeitintensivsten Schritte im Magento-Build-Prozess — und einer der am häufigsten falsch platzierten. Zu früh ausgeführt fehlt die vollständige Composer-Basis; zu spät ausgeführt verzögert es den Deploy. Dieser Artikel zeigt, wann und wie di:compile in einer GitLab-Pipeline am besten läuft.

Die drei Häkchen beim Anlegen einer GitLab-Variable sehen harmlos aus – aber welche Kombination für welche Variable gilt, bestimmt über die Sicherheit des gesamten Deployment-Prozesses. Protected, Masked und Environment Scope bedeuten drei verschiedene Dinge, die oft verwechselt werden.

Wer Deployments nicht mit Tags kennzeichnet und keine Versionsnummern pflegt, verliert den Überblick darüber, was wann auf welchem Server gelaufen ist. Release-Tags machen jedes Magento-Deployment eindeutig, rückverfolgbar und im Notfall sofort rollbackfähig.

Ein Rollback, der erst im Störfall geschrieben wird, ist keiner. Wer das Rollback-Skript nicht vor dem ersten Deployment fertig hat, testet es zum ersten Mal unter Zeitdruck und Stress — genau dann, wenn alles schnell gehen muss.

Cache beschleunigt Builds durch Wiederverwendung von Downloadergebnissen. Artefakte übertragen gebaute Resultate zwischen Jobs. Wer beide verwechselt, kämpft mit inkonsistenten Builds, unnötig langen Pipeline-Laufzeiten und schwer reproduzierbaren Deployment-Artefakten für Magento.

Der GitLab Runner ist der Motor jeder Pipeline – er führt die Jobs aus, die in .gitlab-ci.yml definiert sind. Welcher Runner-Typ für Magento-Builds und Deployments geeignet ist, hängt von Isolation, Performance, Sicherheitsanforderungen und verfügbarer Infrastruktur ab.