Skip to main content
CI/CD (Continuous Integration, Delivery und Deployment) ist ein grundlegendes Konzept im modernen Softwareentwicklungsprozess. Ziel ist es, Änderungen an Software häufig, zuverlässig und automatisiert in Test- und Produktionsumgebungen zu bringen – eine zentrale Idee im DevOps-Ansatz.

​
Continuous Integration

Kontinuierliche Integration bedeutet, dass Entwickler ihren Code regelmässig (z. B. mehrmals täglich) in ein zentrales Repository einpflegen.
Der Code wird automatisch gebaut und getestet, um frühzeitig Fehler zu erkennen.
Ziel ist es, Integrationsprobleme frühzeitig zu vermeiden und die Codequalität zu sichern.

​
Vorteile

  • Kleinere Änderungen → weniger Konflikte
  • Schnellere Fehlersuche
  • Stabilere Builds

​
Continuous Delivery

Bei der kontinuierlichen Bereitstellung wird sichergestellt, dass die Software jederzeit bereit für ein Deployment ist.
Der Build-Prozess erzeugt ein bereitstellbares Artefakt (z. B. ein Docker-Image oder ein Paket), das in Test- oder Staging-Umgebungen eingesetzt werden kann.
Die Veröffentlichung in die Produktionsumgebung erfolgt manuell, aber ist jederzeit möglich.

​
Continuous Deployment

Eine Erweiterung von Continuous Delivery, bei der auch das Deployment in die Produktivumgebung automatisiert ist.
Codeänderungen gelangen automatisch in die Produktion, sofern alle Tests erfolgreich sind.

​
CI/CD-Pipeline

Eine Pipeline ist eine strukturierte Abfolge von Schritten, die automatisch durchlaufen werden, sobald Änderungen am Code vorgenommen werden. Sie besteht aus vier Hauptphasen:
  1. Build
  2. Test
  3. Delivery
  4. Deployment

​
Build-Phase

Das Ziel der Build-Phase ist es aus dem Quellcode ein ausführbares Artefakt zu erstellen (z. B. .jar, .exe, Container-Image). Zu den Aufgaben gehören unter anderem Folgende:
  • Quellcode kompilieren
  • Abhängigkeiten laden (z. B. Maven, npm, pip)
  • Docker-Container bauen (z. B. docker build)
  • Artefakte erzeugen und versionieren

​
Test-Phase

Das Ziel bei der Test-Phase ist es sicherzustellen, dass die Anwendung korrekt funktioniert und keine alten Funktionen kaputtgehen.
TestartBeschreibung
Unit TestsTest einzelner Funktionen/Methoden
IntegrationstestsTest von Schnittstellen zwischen Komponenten
RegressionstestsPrüfen, ob bestehende Funktionen weiterhin korrekt arbeiten
Benutzerakzeptanztests (UAT)Manuelle oder automatisierte Endnutzerprüfungen

​
Delivery-Phase

Das Ziel der Delivery-Phase ist es die erstellten und getesteten Artefakte in eine Staging- oder Testumgebung zu überführen.

​
Beispiele

  • Upload in ein Artefakt-Repository (z. B. Nexus, Artifactory)
  • Bereitstellung als Nightly Build
  • Push in Docker Registry (z. B. Azure Container Registry, Docker Hub)

​
Deployment-Phase

Das Ziel der Deployment-Phase ist es die Software automatisch in die Produktionsumgebung zu bringen - sobald sie den gesamten Prozess erfolgreich durchlaufen hat.