Was ist CI/CD? Kontinuierliche Integration und kontinuierliche Lieferung

By: Thomas Hamilton Thomas Hamilton
Hours Aktualisiert

โšก Intelligente Zusammenfassung

Continuous Integration ist eine Softwareentwicklungsmethode, bei der Teammitglieder ihre Arbeit mindestens tรคglich in ein gemeinsames Repository zusammenfรผhren und jeder Commit einen automatisierten Build und Test auslรถst, um Integrationsfehler frรผhzeitig zu erkennen.

  • ๐Ÿ”„ Definition: Die Entwickler integrieren tรคglich Code, und jeder Commit wird durch einen automatisierten Build verifiziert.
  • ๐Ÿšš CI vs CD: CI testet jede ร„nderung; Continuous Delivery sorgt dafรผr, dass Software jederzeit verรถffentlicht werden kann.
  • ๐Ÿงช Pipeline: Commit lรถst die Build-, Test- und Deployment-Phasen in einem kontinuierlichen Ablauf aus.
  • ๐Ÿงฐ Tools: Jenkins, Bamboo und TeamCity Automatisierung von Build- und Testprozessen.
  • ๐Ÿ“‰ Nutzen: Frรผhes und hรคufiges Testen bedeutet weniger Fehler und schnellere, sicherere Verรถffentlichungen.
  • ๐Ÿค– KI-Unterstรผtzung: KI-Tools erkennen fehlerhafte Tests und priorisieren Build-Fehler automatisch.
MEHR LESEN

Was ist CI/CD?

Was ist kontinuierliche Integration (CI)?

Kontinuierliche Integration Integriert ist eine Softwareentwicklungsmethode, bei der Teammitglieder ihre Arbeit mindestens einmal tรคglich zusammenfรผhren. Jede Integration wird durch einen automatisierten Build verifiziert, der Fehler erkennt. Das Konzept wurde vor รผber zwei Jahrzehnten eingefรผhrt, um die sogenannte โ€žIntegrationshรถlleโ€œ zu vermeiden, die entsteht, wenn die Integration bis zum Projektende aufgeschoben wird.

Nach jedem Code-Commit wird die Software sofort kompiliert und getestet. In groรŸen Projekten mit vielen Entwicklern erfolgen Commits mehrmals tรคglich. Mit jedem Commit wird der Code kompiliert und getestet; ist der Test erfolgreich, wird der Build auf Deployment-Potenzial geprรผft; und ist das Deployment erfolgreich, wird der Code in die Produktionsumgebung รผbertragen. Dieser kontinuierliche Zyklus aus Commit, Build, Test und Deployment gibt dieser Vorgehensweise ihren Namen.

Was ist Continuous Delivery (CD)?

Kontinuierliche Lieferung ist eine Softwareentwicklungsmethode, bei der ein Team Software in kurzen Zyklen entwickelt und sicherstellt, dass sie jederzeit zuverlรคssig verรถffentlicht werden kann. Ziel ist es, Software schnell und hรคufig zu entwickeln, zu testen und zu verรถffentlichen, um Kosten, Zeitaufwand und Risiken bei der Bereitstellung von ร„nderungen durch hรคufige Produktionsaktualisierungen zu reduzieren.

Unterschied zwischen CI und CD

Kontinuierliche Integration Bei der automatischen Prรผfung jeder ร„nderung am Quellcode handelt es sich um einen Ansatz, bei dem Continuous Delivery ร„nderungen wie neue Funktionen, Konfigurationen und Fehlerbehebungen sicher und schnell in die Produktion รผberfรผhrt.

Entwicklung ohne CI vs. Entwicklung mit CI

Entwicklung ohne CI Entwicklung mit CI
Viele Fehler Weniger Fehler
Seltene Commits RegelmรครŸige Commits
Seltene und langsame Verรถffentlichungen RegelmรครŸige Arbeitsverรถffentlichungen
Schwierige Integration Einfache und effektive Integration
Die Prรผfung erfolgt spรคt Tests finden frรผh und oft statt.
Probleme sind schwieriger zu beheben Probleme werden schneller gefunden und behoben.
Schlechte Sichtbarkeit des Projekts Bessere Projekttransparenz

ร„HNLICHE ARTIKEL

Unterschied zwischen Kompilierung und kontinuierlicher Integration

Wรคhrend die Kompilierung lediglich den Code in Maschinensprache umwandelt, fรผhrt CI mehrere weitergehende Aktivitรคten durch:

  • DB-Integration: Hรคlt Datenbank und Code synchron und automatisiert die Erstellung der Datenbank und der Testdaten.
  • Code Inspektion: Gewรคhrleistet eine gesunde Codebasis, erkennt Probleme frรผhzeitig und wendet bewรคhrte Verfahren an.
  • Automatisierte Bereitstellung: Ermรถglicht es Ihnen, das Produkt jederzeit zu verรถffentlichen und es in einem permanent vorfรผhrfรคhigen Zustand zu halten.
  • Dokumenterstellung: Hรคlt die Dokumentation auf dem neuesten Stand und erstellt Build-Berichte und Kennzahlen.
  • Zusammenstellung: Konvertiert Hochsprachencode in Maschinensprache und stellt sicher, dass er auf jeder Zielplattform kompiliert werden kann.

Idealerweise wird der Build-Prozess von der Kommandozeile aus gestartet, anstatt von einer IDE abhรคngig zu sein, er findet kontinuierlich auf einem dedizierten CI-Server statt (nicht per Cronjob), wird bei jedem Check-in ausgelรถst und liefert sofortiges Feedback ohne Aufwand fรผr den Entwickler.

Was benรถtigen Sie zur Durchfรผhrung des CI-Prozesses?

  • Versionskontrollsystem (VCS): Eine zuverlรคssige Methode, um ร„nderungen, die im Laufe der Zeit an Ihrem Projekt vorgenommen werden, zu zentralisieren und zu speichern.
  • Virtuelle Maschine: Ein Ersatzserver oder zumindest einer virtuellen Maschine um Ihr System aufzubauen.
  • Gehostete CI-Tool-Lรถsungen: Um die Serververwaltung zu vermeiden, รผbernehmen gehostete Lรถsungen den gesamten Prozess und bieten eine einfachere Skalierbarkeit.
  • Tools: Wenn Sie sich fรผr eine selbstgehostete Variante entscheiden, installieren Sie ein CI-Tool wie beispielsweise Jenkins, TeamCity, Bamboooder GitLab.

Wie funktioniert Continuous Integration?

Ein altes Beispiel ist Nokia, das einst ein Verfahren namens โ€žNightly Buildโ€œ verwendete. Nach zahlreichen Commits vieler Entwickler im Laufe des Tages wurde die Software jede Nacht neu erstellt. Da dies nur einmal tรคglich geschah, war es mรผhsam, Fehler in einer groรŸen Codebasis zu isolieren, zu identifizieren und zu beheben.

Later Das Team fรผhrte Continuous Integration ein. Die Software wurde erstellt und getestet, sobald ein Entwickler Code einspielte, sodass Fehler sofort erkannt und vom zustรคndigen Entwickler schnell behoben werden konnten.

Merkmale von CI

  • Ermรถglicht die Pflege eines einzigen Quellcode-Repositorys.
  • Ermรถglicht das Testen einer Kopie der Produktionsumgebung, die so nah wie mรถglich an der Produktionsumgebung gehalten wird.
  • Gewรคhrleistet die stรคndige Verfรผgbarkeit einer aktuellen Version.
  • Macht den gesamten Build-, Test- und Deployment-Prozess fรผr alle Beteiligten transparent.

Warum CI verwenden?

  • Hilft Ihnen dabei, qualitativ bessere Software zu entwickeln und wiederholbare Tests durchzufรผhren.
  • Skaliert die Lieferleistung von Entwicklungsteams und ermรถglicht es Entwicklern, parallel an Funktionen zu arbeiten.
  • Erhรถht die Transparenz und die Kommunikation innerhalb des Teams.
  • Liefert sofortiges Feedback bei auftretenden Problemen und reduziert das Risiko durch eine schnellere und besser vorhersagbare Bereitstellung.
  • Vermeidet Verwirrung in letzter Minute zum Verรถffentlichungszeitpunkt.

Best Practices fรผr die Nutzung von CI-Systemen

  • Committen Sie frรผhzeitig und hรคufig, und committen Sie niemals fehlerhaften Code.
  • Beheben Sie Build-Fehler umgehend und handeln Sie anhand der Messwerte.
  • In jeder Zielumgebung wird ein Build erstellt und aus jedem Build werden Artefakte generiert.
  • Automatisieren Sie den Build-Prozess, damit er nicht von einer IDE abhรคngt.
  • Bei jeder ร„nderung muss alles neu erstellt und getestet werden, einschlieรŸlich des Datenbankschemas.
  • Halten Sie den Build-Prozess schnell und nutzen Sie die automatisierte Bereitstellung.

Nachteile von CI

  • Eine anfรคngliche Einrichtungszeit und Schulung sind erforderlich, um sich an einen CI-Server zu gewรถhnen.
  • Es mรผssen geeignete Testverfahren entwickelt werden, und eine gut aufgebaute Testsuite benรถtigt erhebliche Ressourcen.
  • Vertraute Prozesse mรผssen umgestellt werden, und zusรคtzliche Server und Umgebungen werden benรถtigt.
  • Wartezeiten kรถnnen auftreten, wenn mehrere Entwickler gleichzeitig ihren Code integrieren mรถchten.

Werkzeuge fรผr den CI-Prozess

Jenkins

Jenkins ist ein Open-Source-Tool fรผr kontinuierliche Integration, das in geschrieben ist JavaEs ermรถglicht Echtzeittests und die Berichterstellung รผber isolierte ร„nderungen in einer grรถรŸeren Codebasis und hilft Entwicklern, Fehler schnell zu finden und zu beheben, wรคhrend gleichzeitig Build-Tests automatisiert werden.

Bamboo

Bamboo ist ein Continuous-Integration-Build-Server, der automatisierte Builds, Tests und Releases an einem zentralen Ort durchfรผhrt. Er arbeitet nahtlos mit Jira zusammen und Bitbucket und unterstรผtzt viele Technologien wie Docker, Git, SVN, Mercurial und AWS.

TeamCity

TeamCity ist ein Continuous-Integration-Server mit vielen leistungsstarken Funktionen. Er hรคlt den CI-Server auch dann stabil und funktionsfรคhig, wenn keine Builds ausgefรผhrt werden, und sorgt fรผr eine bessere Codequalitรคt in jedem Projekt.

Hรคufig gestellte Fragen

Continuous Delivery sorgt dafรผr, dass jede ร„nderung freigegeben werden kann und erst nach manueller Freigabe in der Produktionsumgebung bereitgestellt wird. Continuous Deployment beseitigt diese Hรผrde und gibt jede ร„nderung, die die Pipeline durchlรคuft, automatisch frei.

Eine typische Pipeline umfasst die Phasen Quellcode, Build, Test, Release und Deployment. Code Die in die Versionskontrolle aufgenommenen Dateien werden kompiliert, automatisch getestet, dann fรผr die Produktion vorbereitet und freigegeben.

Die sogenannte Integrationshรถlle ist das mรผhsame Zusammenfรผhren der ร„nderungen vieler Entwickler, die bis zum Projektende zurรผckgehalten werden. Continuous Integration (CI) vermeidet dies durch die kontinuierliche Integration und das Testen kleiner ร„nderungen.

Committen Sie Ihre ร„nderungen frรผhzeitig und regelmรครŸig, mindestens einmal tรคglich, in kleinen Arbeitsschritten. Hรคufige Commits erleichtern das Testen, Zusammenfรผhren und gegebenenfalls das Zurรผcksetzen der ร„nderungen.

Ein Build-Artefakt ist das verpackte Ergebnis eines Build-Prozesses, beispielsweise eine JAR-Datei, ein Container-Image oder eine Binรคrdatei. Dasselbe Artefakt wird aus Grรผnden der Konsistenz sowohl in der Test- als auch in der Produktionsumgebung verwendet.

Selbstgehostete CI lรคuft auf Servern, die Sie selbst verwalten, was volle Kontrolle, aber auch einen hรถheren Wartungsaufwand bedeutet. Gehostete (Cloud-)CI wird von einem Anbieter gewartet und lรคsst sich ohne Infrastrukturverwaltung problemlos skalieren.

Die KI prognostiziert, welche Tests fรผr eine ร„nderung ausgefรผhrt werden mรผssen, priorisiert risikobehaftete Bereiche und automatisiert die Fehlerbehebung. Dies verkรผrzt die Feedbackzeiten und hรคlt die Testpipelines auch bei wachsender Codebasis schnell.

Ja. Modelle des maschinellen Lernens erkennen Tests, die unregelmรครŸig erfolgreich sind oder fehlschlagen, hรคufen zusammengehรถrige Build-Fehler und decken die wahrscheinliche Ursache auf.ping Die Teams sorgen fรผr eine zuverlรคssige Pipeline.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: