„git push Production Main“ – und drei Minuten später zeigt die Site einen 500-Fehler an, weil eine SQL-Migration vergessen wurde. Das Team wusste, dass es „vorsichtig sein“ musste. Für einen persönlichen Blog war das Ritual nicht schlecht; Es war für ein Geschäft, das Geld verdient.
Git Push Deploy: Das Remote-Repository auf dem Server führt einen Hook aus, der den Code abruft und PHP-FPM neu lädt. CI/CD: Jeder Push durchläuft eine Pipeline, die erstellt, testet, Artefakte erstellt und dann bereitstellt – oder ablehnt. Die Frage ist nicht, welche Technologie angesagt ist; Dies ist wie viel Fehlerkosten Ihr Unternehmen ohne Netz akzeptiert.
Zwei Rituale, zwei Netzebenen
| Größe | Git Push → Server | CI/CD (Aktionen, GitLab usw.) |
|---|---|---|
| Tests vor der Produktion | Handbuch (oft übersprungen) | Automatisiert, blockierend |
| Reproduzierbarkeit | „Es funktioniert auf meinem Rechner“ | Identisches Artefakt pro Commit |
| Rollback | Git-Zurücksetzen + manuelles erneutes Bereitstellen | Pipeline markieren/freigeben + erneut bereitstellen |
| Prüfung | SSH-Protokolle | Pipeline-Historie + Genehmigungen |
| Geheimnisse | Hauptrisiko auf dem Server | Vault CI, OIDC-Cloud |
| Rüstzeit | Stunden | Tage, dann Minuten/Bereitstellung |
Die Einfachheit des Direct Push zahlt sich bei Vorfällen aus, die vor dem ersten Freitagabend niemand quantifiziert hat.
Wenn direkter Druck immer noch Wasser hält
Einzelprojekt, geringe Kritikalität. Statischer Blog, Portfolio: lokaler Build, Rsync oder Push-Hook, Backup vor der Bereitstellung.
Identische Staging-Umgebung. Zuerst Staging vorantreiben, menschliche Validierung, dann schnelle Produktion – strenge manuelle Disziplin.
Zusammengestelltes Team, seltene Bereitstellungen. Vierteljährliches Update, Wartungsfenster angekündigt.
Nicht verhandelbare Konditionen auch im „einfachen“ Zustand:
- Geschützter „Hauptzweig“.
- Tag- oder Commit-Hash für den Fall eines Rollbacks notiert
- Versionierte und kopiergeprüfte Datenbankmigrationen
Wenn CI/CD zum Mindeststandard wird
E-Commerce, SaaS, sensible Daten. Unit-Tests + Integration + Rauchtest nach der Bereitstellung.
Team > 2 Entwickler. Codeüberprüfung (PR) + grüne Pipeline vor der Zusammenführung.
Compliance. Rückverfolgbarkeit darüber, wer was wann bereitgestellt hat – ISO, SOC2, Unternehmenskunden.
Multi-Umgebungen. Entwickler → Staging → Produkt mit kontrollierten Werbeaktionen.
Minimale realistische Pipeline:
- Lint + PR-Tests
- Artefakt erstellen (Container oder Tarball)
- Stellen Sie Auto-Staging bereit
- Stellen Sie das Produkt manuell oder automatisch nach dem Tag bereit
Hosts wie Clever Cloud oder PaaS-Plattformen integrieren oft die native Git-Bereitstellung mit Build-Remote – das ist nicht einfach das Pushen auf „/var/www“.
Häufige Fehler aus beiden Lagern
Direkter Push: Bereitstellung am Freitag um 18:00 Uhr, nicht umkehrbare Migrationen, „temporäre“ 777-Berechtigungen.
CI/CD: lange, nicht optimierte Pipeline, ignorierte Flockigkeit, Geheimnisse in Klartextvariablen, Produktbereitstellung ohne Staging.
Oben: Der Post-Receive-Hook ist keine Strategie
Entscheide dich und gehe ohne blinden Fleck voran
- Schätzung der stündlichen Kosten eines Produktionsausfalls (CA, SLA, Reputation).
- Wenn > niedrig: Mindestpipeline innerhalb einer Woche (GitHub-Aktionen + SSH-Bereitstellung oder PaaS-Webhook).
- Behalten Sie Direct Push nur für Einweg-Envs mit Backup bei.
- Rollback von Dokumenten in weniger als 15 Minuten – getestet.
Vergleichen Sie Hosts mit integrierter Git-Bereitstellung in Verzeichnis. Siehe auch Docker Compose oder Kubernetes für die Architektursuite.
Häufig gestellte Fragen
Ist direkter Git-Push in der Produktion akzeptabel?
Manchmal für Solo-Showcase. Immer wenn ein Fehler kostspielig ist, ist das Fehlen automatisierter Tests ein inakzeptables Risiko.
Verlangsamt CI/CD kleine Teams nicht?
Mindestpipeline: 2–5 Minuten, oft weniger als ein manuelles Rollback nach einem Produktionsfehler.
Wo werden Bereitstellungsgeheimnisse gespeichert?
Verschlüsselte CI-Variablen, Tresor, Nur-Bereitstellungsschlüssel – niemals im Repository oder im generalisierten SSH-Root.
Können wir beides kombinieren?
Ja: Push löst CI aus, das bereitgestellt wird, wenn es grün ist. Vermeiden Sie bloßes Anstoßen ohne Tor.
Vor dem nächsten Deployment eine Frage: Wenn dieser Commit Prod unterbricht, wie viele Minuten muss ich zurückgehen – und wer weiß, wie das geht? Wenn die Antwort vage ist, ist das Ritual noch nicht auf der Risikostufe.