CI/CD

Was bedeutet CI - Continous 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:

  1. Plan
  2. Code
  3. Build
  4. Test

Was bedeutet CD – Continous Delivery

CD bedeutet “Continous Delivery”. CD beschreibt, dass neue Versionen der Software automatisiert bereitgestellt werden können. Klassischerweise besteht der Prozess aus vier Schritten:

  1. Release
  2. Deploy
  3. Operate
  4. 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.

Jetzt den Cloudomation-Newsletter abonnieren

Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten.