METHODE

CI/CD

Continuous Integration / Continuous Delivery

Jede Codeänderung wird automatisch gebaut, getestet und für das Release vorbereitet. Manche Teams gehen einen Schritt weiter und shippen auf jeden grünen Build.

Zuletzt geprüft: 2026-05-24 vonKevin Riedl wiki ↗

Continuous Integration heißt, der Team-Code wird bei jeder Änderung gemerged und gebaut, statt bei einer Big-Bang-Integration am Ende. Continuous Delivery heißt, jeder erfolgreiche Build ist einen Knopfdruck von Production entfernt. Continuous Deployment entfernt den Knopf: jeder grüne Build geht automatisch live.

Die meisten Teams machen CI gut, CD sporadisch und Continuous Deployment fast nie. Der Engpass ist selten das Tooling. Es ist das Vertrauen in die Testsuite und die Bereitschaft, einen kaputten Build binnen einer Stunde zu reparieren. Ohne beides shippen automatische Deploys nur Bugs schneller.

Wavect liefert jedes Projekt mit CI von Tag eins. CD-Konfiguration hängt davon ab, ob Projekt Testabdeckung und operative Disziplin hat, um sicher zu sein. Wir sagen dir, welche Variante zutrifft."

// FAQ

Häufige Fragen

Häufige Fragen

CI ab Tag eins, immer. CD ab dem Moment, an dem Releases nicht mehr per Hand vorbereitet werden sollen (meist ab Team-Größe 3). Continuous Deployment erst, wenn Testabdeckung, Monitoring und Rollback verlässlich sind; vorher liefert es Bugs nur schneller in Production.
GitHub Actions, wenn Du auf GitHub bist. GitLab CI, wenn Du auf GitLab bist. Self-hosted Jenkins nur, wenn Du eine starke Compliance-Begründung hast. Plattform-Wahl ist sekundär; was zählt, ist Pipeline-Design und Test-Disziplin.
Unter 10 Minuten für die meisten Branches, sonst hört das Team auf, auf Grün zu warten. Über 20 Minuten ist die Pipeline ein Bottleneck. Parallelisieren, Test-Selection per Code-Pfad, Build-Caches. Slow Pipelines sind ein Symptom, kein Schicksal.