Freitag 18:30 Uhr: dringende FTP-Korrektur, Datei vergessen, Opcode-Cache nicht geleert, Zurückverfolgen unmöglich, da niemand die vorherige Version getaggt hat. Das Team besteht aus zwei Entwicklern und einem Gründer – kein dedizierter Plattform-Ingenieur, kein großes Infrastrukturbudget. Allerdings hätte eine Pipeline mit 30 Leitungen die gleiche Korrektur in zwei Minuten durchgeführt, mit Verlauf.
Dieses Szenario wiederholt sich, sobald die manuelle Bereitstellung unter Druck zur Norm wird. CI/CD für ein kleines Team ist kein Katalog von DevOps-Tools. Es geht darum, die Aktionen zu automatisieren, die Sie bereits ausführen – und die Produktion nicht mehr mühsamen manuellen Klicks anzuvertrauen.
Der richtige Ehrgeiz besteht nicht darin, „es wie die Webgiganten zu machen“. Es geht darum, die Produktion nicht mehr vom Sofa-Laptop aus bereitzustellen – ohne ausdrückliche Erlaubnis am Freitagabend.
Fangen Sie klein an: Ein Workflow, der Lints, Tests und Bereitstellungen für das Staging durchführt, reicht oft für die erste Woche aus. Fügen Sie die manuelle Produktion nur dann hinzu, wenn sich die Bereitstellung als zuverlässig erwiesen hat – nicht umgekehrt.
Die minimal lebensfähige Pipeline
1. Auslöser – Push auf „Main“ oder Zusammenführung einer Pull-Anfrage.
2. Installieren + Lint + Test – was in der Produktion häufig zu Unterbrechungen führt (Syntax, Zahlungstests, Probelaufmigrationen).
3. Build – versioniertes Artefakt (Archiv, Docker-Image, kompilierte Assets).
4. Staging bereitstellen – automatisch; Rauchtest-Curl oder leichter Dramatiker.
5. Produkt bereitstellen – genehmigtes Handbuch oder Tag „v*“; Slack- oder E-Mail-Benachrichtigung.
| Schritt | Gemeinsames Werkzeug | Überspringen, wenn… |
|---|---|---|
| Fussel | ESLint, PHPStan | Niemals – fast keine Kosten |
| Tests | PHPUnit, Jest | Nur Einweg-Prototyp |
| Bauen | npm run build | Reines PHP ohne Assets |
| Bereitstellen | SSH + rsync, Clever Cloud, Forge | Ohne SSH geteilt |
Automatisieren Sie zunächst das, was bereits zu einem Ausfall geführt hat. Der Rest wartet.
Hosting- und Bereitstellungsmethode
VPS + SSH – idempotentes Skript, Veröffentlichungen in „/var/www/releases/“ plus „aktueller“ symbolischer Link, Rücktaste = Link-Repointing.
PaaS (Clever Cloud, Platform.sh, Render) – Git-Push-Bereitstellung; CI ruft CLI oder Webhook auf.
Geteilt – Begrenztes CI; manchmal nur FTP. Erwägen Sie die Migration zu VPS oder PaaS, wenn Sie mehr als zweimal pro Woche bereitstellen.
Der Bereitstellungsmodus konditioniert die Pipeline: Ein PaaS wie Clever Cloud akzeptiert einen Git-Push vom CI; Ein VPS fordert SSH und ein idempotentes Skript an. Durch die gemeinsame Auswahl von Hosting und Pipeline wird vermieden, dass vierzig Jobs für einen gemeinsam genutzten Dienst erstellt werden, der nur FTP akzeptiert.
Vergleichen Sie Hosts, die für die Git-Bereitstellung geeignet sind, in unserem Vergleich.
Minimales Workflow-Beispiel
Eine „.github/workflows/deploy.yml“-Datei mit dreißig Zeilen reicht oft aus: Trigger auf „main“, Installation von Abhängigkeiten, Lint, Tests, Build, SSH-Bereitstellung in der Vorproduktion. Die Produktion wird weiterhin manuell über „workflow_dispatch“ oder Tag angestoßen. Dokumentieren Sie geheime Variablen in der internen README-Datei – SSH-Host, privater Schlüssel, Bereitstellungspfad –, damit das Verfahren den Weggang eines Entwicklers übersteht.
Kleine Teamfehler
Eine 25-Minuten-Pipeline wird am Ende umgangen: Niemand wartet, der FTP kehrt zurück. Klare Geheimnisse in einer „.env“-Datei, die „durch Vergessen“ begangen wurde, bleiben die häufigste Ursache für Kompromittierungen. Automatische Produktion ohne Vorproduktion macht jede Zusammenführung zum russischen Roulette. Das Fehlen eines dokumentierten Rollbacks löst beim ersten Fehler Panik aus. Ohne Benachrichtigungen wird die fehlerhafte Bereitstellung schließlich vom Kunden entdeckt – niemals vom Team.
Drama-freies Rollback
Git-Tags für jede Produktionsversion. Über N-Versionen erhaltene Artefakte. Symbolischer PaaS-Link oder Backtrack in einem Befehl. Grundlage: reversible Migrationen oder Backups vor der Bereitstellung – siehe Backup-Strategie.
The Summit: Automatisierung, die niemals läuft
Besser drei immergrüne Bühnen als eine umgangene Kathedrale.
Entscheide dich und gehe ohne blinden Fleck voran
Beginnen Sie mit der Auflistung der letzten drei bereitstellungsbezogenen Ausfälle – dies ist Ihr vorrangiger Rückstand. Schreiben Sie dann einen Arbeitsablauf mit bis zu fünf Schritten, der diese spezifischen Risiken abdeckt. Nutzen Sie die Geheimnisse der Schmiede und der automatischen Bereitstellung in der Vorproduktion. Vor Produktionsbeginn ist ein Rauchtest erforderlich. Dokumentieren Sie den Rollback-Vorgang auf einer für das gesamte Team zugänglichen Seite. Wenn Sie das Artefakt in einen Container umwandeln, lesen Sie auch unseren Leitfaden Docker für Anfänger.
Häufig gestellte Fragen
Welches CI-Tool für zwei Entwickler?
GitHub Actions oder GitLab CI sind mehr als genug. Vermeiden Sie selbst gehostete Jenkins, solange die Verwaltung mehr kostet als der Gewinn – zwei Entwickler haben nicht die Zeit, neben dem Produkt eine CI-Schmiede zu pflegen.
Was muss vor der Bereitstellung getestet werden?
Der Linter, kritische Tests und ein sauberer Build bilden die Basis. Fügen Sie einen HTTP-Test vor der Produktion hinzu, falls vorhanden – es ist keine umfassende Abdeckung erforderlich, um loszulegen.
Automatisches Produkt aus der Zusammenführung bereitstellen?
Ohne Vorproduktion zu riskant. Vorproduktion automatisch bereitstellen; Bewahren Sie das Produktionshandbuch auf oder lösen Sie es nach der Validierung durch ein Tag aus.
Wo werden CI-Geheimnisse gespeichert?
In den verschlüsselten Geheimnissen der Schmiede, niemals im Lagerhaus. Planen Sie eine Rotation ein, wenn das Team abreist.
CI/CD für ein kleines Team bedeutet nicht „wie Google“. Es geht darum, die Produktion nicht mehr vom Couch-Laptop aus bereitzustellen – ohne ausdrückliche Genehmigung am Freitagabend.