CI/CD
Was bedeutet CI - Continuous Integration
CI steht für “Continuous Integration”, also “Kontinuierliche Integration”. Das bedeutet, dass eingebrachte Code-Änderungen sofort zu einem Build führen und automatisiert Tests durchgeführt werden. So bekommen Entwickler_innen schnell Feedback, ob es zu einem Fehler gekommen ist. CI soll deshalb dazu beitragen, Fehler schnell zu erkennen und darauf reagieren zu können.
CI wird meist in diese Phasen unterteilt:
- Plan
- Code
- Build
- Test
Was bedeutet CD – Continuous Delivery
CD bedeutet “Continuous Delivery”. CD beschreibt, dass neue Versionen der Software automatisiert bereitgestellt werden können. Klassischerweise besteht der Prozess aus vier Schritten:
- Release
- Deploy
- Operate
- Monitor
Was sind die Elemente einer CI/CD-Pipeline?
Die Pipeline fasst die einzelnen Schritte von CI und CD zusammen. Diese besteht aus Jobs (Was ist zu tun?) und aus Stages (Welche Jobs sollen wann ausgeführt werden?)
Die grundlegenden Elemente einer CI/CD-Pipeline werden nachfolgend beschrieben.
| Schritt | Aktion |
|---|---|
Plan | Anforderungen werden festgelegt und zur Erstellung einer Produkt-Roadmap verwendet. |
Code | Mit der Entwicklung wird gestartet. Eine Entwicklerin ändert den Code. |
Build | Ein Installationspaket für die Anwendung wird erzeugt. |
Test | Automatisierte Tests erfolgen. Es wird sichergestellt, dass alles ordnungsgemäß funktioniert. |
Release | Der Build ist bereit für die Bereitstellung in der Produktionsumgebung. |
Deploy | Es erfolgt die (automatische) Bereitstellung der Software. |
Operate | Die neue Version ist jetzt live. Jetzt wird sichergestellt, dass alles reibungslos läuft. |
Monitor | Daten werden gesammelt, um die Software zu verbessern. Danach beginnt wieder die “Plan-Phase”. |
CI/CD in der Praxis
Während die Grafik oben eine “ideale” CI/CD Pipeline zeigt, enden “echte” CI/CD Pipelines in der Praxis häufig nach dem automatisierten Testen.
Vor allem Deployment in Produktivsysteme ist meist nicht automatisiert. Auch der “Plan” Schritt ist meist nur rudimentär eingebunden, z.B. indem im Ticketing-System, in welchem die Planung stattfindet, automatisiert Kommentare mit Verweisen auf Commits erstellt werden.
Operations und Monitoring sind häufig losgelöste Prozesse, die von eigenen Teams gehandhabt werden.
Besonders optimistisch ist die Idealvorstellung, dass Feedback aus Operations und Monitoring wieder in den “Plan” Prozess einfließen – was nur sehr selten der Fall ist (wenn dann für grobe Bugs) und auch nicht automatisiert stattfindet.
Die Schritte “Build”, “Deploy in interne Testsysteme” und “Test” finden dafür häufig in mehrfachen “Unterkreisen” für verschiedene Staging-Systeme mit unterschiedlichen Test-Cases wiederholt statt – bereits vor einem “Release” Schritt, der öffentliche Verfügbarkeit impliziert.
Für viele Arten von Tests ist ein Deployment (also Installation der Software mit allen Abhängigkeiten und Komponenten in einer Test- oder Staging-Umgebung) notwendig. Diese “internen” Deployment-Prozesse sind häufig vollständig oder größtenteils automatisiert, können allerdings meist nicht direkt für Deployment in Produktion wiederverwendet werden.
Mehr zum Thema CI / CD:
