Ist Continuous Integration in Continuous Deployment ein Fortschritt – oder nicht?

In der Welt der DevOps mangelt es nicht an Fachjargon. Sie hören sie im Alltag wie SCRUM, SME und sogar gelegentlich bei CI/CD. Mit Letzterem haben viele große Schwierigkeiten, unter anderem weil "CD" in der DevOps-Welt sowohl "kontinuierliche Bereitstellung" als auch "kontinuierliche Bereitstellung" bedeuten kann. DevOps bietet keine Einheitslösung für Ihre Organisation. Deshalb ist es entscheidend, die Fachsprache zu verstehen. Der Einsatz von DevOps in Ihrem Unternehmen führt zu Effizienz, besserer Kommunikation und schnelleren Produktveröffentlichungen. Wenn Sie jedoch Zeit in die Implementierung von DevOps-Aspekten investieren, die für Ihre Organisation keinen Sinn ergeben, kann das Ihr Unternehmen negativ belasten. In diesem Artikel werden wir Entwicklungen im Zusammenhang mit CI/CD und CI/CD/CD untersuchen. Das mag im Moment wie ein Durcheinander von Briefen aussehen, aber bleiben Sie bei uns, während wir es für Sie aufklären.

DevOps 101: Definitionen

Wenn Sie das hier lesen, möchten Sie wahrscheinlich eine Antwort auf die Millionen-Dollar-Frage: Ist CI/CD eine Progression? Aber wir gehen zuerst zurück zum Grund und bieten einige einfache Definitionen an, die Anfängern helfen, unsere Diskussion besser zu verstehen.

Was ist eine Progression?

Für die Zwecke dieses Artikels ist ein Fortschritt das Vorwärtstempo in einer Kette von DevOps-Übungen, die notwendig sind, um das Endziel größerer Effizienz und schnellere Softwarelieferung zu erreichen. Ein Fortschritt ist für das Endergebnis entscheidender als bloße Empfehlung. Von Natur aus bedeutet das Wort, dass eine Sache im Fortschritt erledigt werden muss, damit die nächste effektiv funktionieren kann, und so weiter. Die Ordnungskomponente der Progression eignet sich für den Namen CI/CD.

Was ist kontinuierliche Integration?

Kontinuierliche Integration ist ein Begriff in der Softwareentwicklung, der das Zusammenführen von Code umfasst, bei dem manuelles Programmieren auf Automatisierung trifft. Die gemeinsame Anstrengung mehrerer Personen in einem DevOps-Team arbeitet auf das Ziel hin, Prozesse zu optimieren und gleichzeitig Konsistenz zu gewährleisten. Eine Testkomponente existiert, da der Codierungsprozess typischerweise wie mehrere Codeeinheiten aussieht, die zusammengeführt werden, während die Testautomatisierung bei jeder Fusion erfolgt. Indem mehrere Teammitglieder an verschiedenen Teilen des letztendlichen Gesamtpakets arbeiten, beschleunigt die Testautomatisierung in Echtzeit die Zeit bis zur Produktion. Nach dieser Coding-Philosophie führen DevOps-Teams kleine Änderungen Schritt für Stück um und bestätigen, dass Tests häufig durchgeführt werden, um den Code auf Probleme zu überprüfen. Da modernes Programmieren auf verschiedene Tools, Ressourcen und Plattformen verteilt ist, ist das erfolgreiche Zusammenführen des Codes an einer identifizierbaren Stelle ein zentraler Bestandteil dieser Praxis. In den meisten Fällen ist ein Versionskontrollrepository notwendig, um CI erfolgreich zu implementieren. Wenn ein Teammitglied seine Arbeit abgeschlossen hat, reicht es seinen Code in ein Repository ein, damit er mit dem nächsten Codeteil zusammengeführt werden kann. Im Mittelpunkt von CI steht Konsistenz. Mit bestehenden Praktiken zur konsistenten Produktion, Zusammenführung und Testen von Codepaketen und Anwendungen können Teams sicher sein, dass sie an kleinen Codeänderungen zusammenarbeiten können, was das gesamte Softwarepaket noch besser macht. Eine Implikation von CI ist kontinuierliches Testen. Dies geht über das bloße Starten automatisierter Tests bei jeder Zusammenführung eines Codes hinaus. Stattdessen entsteht durch die Integration des automatisierten Tests in den Stoff der CI/CD-Pipeline eine Testschleife, die oft als kontinuierliches Testen bezeichnet wird.

Was ist Continuous Delivery?

Jetzt, wo Sie die Idee hinter der kontinuierlichen Integration verstehen, wird es hier etwas unklar. In vielen DevOps-Organisationen ist kontinuierliche Integration kein Endziel, sondern ein Mittel zum Zweck. Einige IT-Führungskräfte gehen mit der Einstellung heran, dass CI der erste Schritt ist, während Continuous Delivery (CD) der natürliche zweite Schritt ist. Viola! Eine Entwicklung, oder? Aber lassen Sie uns nicht voreilen. Hier ist der Grund: Continuous Delivery ist ein Prozess, der meist nach unsicherem Testen in der CI-Phase stattfindet. Kurz gesagt ist CD der automatisierte Arm, der Codepakete, die den CI-Zyklus abgeschlossen haben, in eine automatisierte und konfigurierte Umgebung für Tests und Bereitstellung schiebt. In DevOps-Organisationen ist es nicht ungewöhnlich, dass Teams mehrere solche Umgebungen mit unterschiedlichen Ressourcen und für unterschiedliche Mittel haben. Eine umfassende CD-Umgebung kann aus mehreren Schritten mit unterschiedlichen Automatisierungsgraden und manueller Ausführung bestehen. Dazu könnten gehören:

1. Code aus der Versionskontrolle entfernen und einen neuen Build ausführen.
2. Code von einer Rechenumgebung in eine andere zu verschieben.
3. Verwaltung von Umgebungen und Konfigurationen, um Code zu unterstützen.
4. Durchführung aller erforderlichen Cloud-Infrastrukturschritte.
5. Anwendungskomponenten werden je nach Bedarf auf Datenbankdienste, APIs oder Webserver verschoben.
6. Protokolle erstellen und Benachrichtigungen bereitstellen.

Wie die oben genannten Schritte zeigen, dient Continuous Delivery als Mittel zur Automatisierung der Umgebung und Infrastruktur, die zur Unterstützung des vom CI-Loop erzeugten Code erforderlich sind. Für viele Unternehmen ist CI/CD ein Mittel, um das ultimative Ziel der kontinuierlichen Bereitstellung zu erreichen, wobei CD der notwendige Vermittler zwischen beiden ist. Anders als manche IT-Führungskräfte vielleicht annehmen, ist CI/CD jedoch kein Fortschritt. Tatsächlich ist die oft gesuchte kontinuierliche Bereitstellung nicht unbedingt für alle Organisationen geeignet, wie wir weiter erläutern werden. Es ist am besten, wenn DevOps-Organisationen alles aus CI und CD verwenden, das für ihr Unternehmensgeschäft sinnvoll ist, in jeder Reihenfolge, die für sie am besten funktioniert. Stellen Sie sich ein Unternehmen vor, das in der Programmierumgebung viele Compliance- und regulatorische Einschränkungen hat. Diese Organisation könnte CI komplett überspringen und sich ausschließlich auf die Automatisierung der Lieferung konzentrieren. Aus diesem Grund ist CI/CD keine echte Entwicklung, wie wir es oben definiert haben, da diese Funktionen nicht in der richtigen Reihenfolge oder ohne Unterstützung der anderen stattfinden können

Was ist Continuous Deployment

Damit bleibt Continuous Deployment (auch CD genannt, verwirrend, oder?). In vielen Fällen wollen Unternehmen bei der Implementierung von CI/CD eigentlich CI/CD/CD. Die Philosophie der Continuous Deployment ermöglicht es, jeden Schritt des CI/CD/CD-prozesses ohne manuelle Beteiligung zu automatisieren. Zum Beispiel ermöglicht Continuous Delivery die Automatisierung von zusammengeführtem Code aus der CI-Schleife in weitere Testumgebungen. Aber wenn man dort aufhört, ist die Bereitstellung immer noch manuell. Hier kommt Continuous Deployment ins Spiel. Mit erfolgreich implementierten Continuous Deployment-Praktiken in einer DevOps-Organisation ist die gesamte CI/CD/CD-Kette automatisiert, wobei der manuelle Schritt zwischen den finalen Tests und der Übertragung des Codes in die Deployment-Umgebungen entfällt. Während dieser Phase unterliegt jede Änderung automatisierten Tests. Wenn sie die Testphase besteht, geht sie direkt in die Produktionsphase über, sodass Unternehmen mehrere Deployments an einem Tag durchführen können. Allerdings ist dieser letzte Schritt nicht für jedes Unternehmen geeignet. Allein das Anstreben nach kontinuierlicher Bereitstellung, ohne dessen Nutzen für die Organisation zu berücksichtigen, ist eine fehlgeleitete Handlung. Eine Praxis, die bei der kontinuierlichen Bereitstellung häufig ist, und die Teams dazu ermutigt, laufende Arbeiten hinter Features zu verstecken, könnte den Entwicklungsprozess umständlicher machen und das Refactoring noch schwieriger machen. Daher sollten Geschäftsleiter verstehen, was sie aus einer CI/CD/CD-Philosophie herausholen wollen, ohne blind nach einem zufälligen Goldstandard zu suchen.

Zusammenfassen

Letztlich ist klar zu erkennen, dass weder CI/CD noch CI/CD/CD eine echte Weiterentwicklung darstellen. Da sie nicht aufeinander angewiesen sind, um die Entwicklung voranzutreiben, können die besten Praktiken von beiden ausgewählt werden, um eine Programmierphilosophie zu schaffen, die auf die Bedürfnisse jedes Programmierunternehmens zugeschnitten ist. Die gute Nachricht ist, dass alle Unternehmens, die DevOps integrieren, davon profitieren können, mehr über Funktionen und Vorteile zu lernen und gleichzeitig zu lernen, wie man CI/CD, CI/CD/CD oder jede andere Variante implementiert, um die effizientesten Ergebnisse zu erzielen.

DevOps-Leitfaden

1. Was ist DevOps? Eine umfassende Einführung
2. Eine kurze Geschichte von DevOps
3. Einführung in die DevOps-Architektur
4. Automatisierung in DevOps: Warum und wie man DevOps-Praktiken automatisiert
5. Was ist CI/CD? Kontinuierliche Integration und kontinuierliche Lieferung erklärt
6. Wie man eine CI/CD-Pipeline mit Jenkins aufbaut
7. DevOps-Metriken zur Optimierung von CI/CD-Pipelines
8. Kontinuierliche Liefermetriken
9. Ist Continuous Integration in Continuous Deployment ein Fortschritt – oder nicht?
10. Unterschiede zwischen Continuous Integration (CI), Delivery (CD) und Deployment
11. Quellcode und Versionskontrolle in DevOps
12. Was ist kontinuierliche Testung?
13. Testautomatisierungs-Frameworks: Der ultimative Leitfaden
14. Release Management in DevOps
15. Erklärt: Monitoring & Telemetrie in DevOps
16. Anwendungs-Leistungsmanagement in DevOps
17. DevOps-Orchestrierung im SDLC
18. Einführung in Datenbank-DevOps
19. Die Rolle der Microservices in DevOps
20. Die Rolle der Virtualisierung in DevOps
21. Container & DevOps: Wie Container in DevOps-Lieferpipelines passen
22. Was ist eine Containerpipeline?
23. Was ist eine DevOps-Toolchain?
24. Verwaltung von Containern und Code für DevOps
25. Die Rolle von Agile in DevOps
26. Die Rolle der Cloud in DevOps
27. Was ist FinDevOps?
28. Top-DevOps-Trends im Jahr 2022
29. DevOps-Werte & Prinzipien
30. DevOps-Kennzahlen und KPIs
31. DevOps-Ratschläge für kleine, mittlere und große Organisationen
32. DevOps-Teamstruktur
33. Top-DevOps-Bücher, die man heute lesen sollte
34. Buchrezension von The Phoenix Project: DevOps For Everyone
35. DevOps-Influencer: 11 DevOps-Experten, denen Sie auf Twitter folgen können
36. GitHub, GitLab, Bitbucket & Azure DevOps: Was ist der Unterschied?
37. Best Practices: Wie man Anwendungen für Kubernetes architekt
38. Konfigurationsmanagement in DevOps
39. DevOps-Verzweigungsstrategien erklärt
40. DevOps-Jobbezeichnungen, Rollen und Verantwortlichkeiten
41. Testen in DevOps: Konzepte, Best Practices und mehr
42. Der vollständige DevOps-Zertifizierungsleitfaden für 2022
43. Was ist das Kubernetes-Operator-Muster?

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.