CI/CD

Was ist CI/CD?

CI/CD, oder kontinuierliche Integration/kontinuierliche Lieferung oder Bereitstellung, ist eine durch Automatisierung ermöglichte Softwareentwicklungspraxis. Häufige, zuverlässige Updates beschleunigen die Release-Zyklen durch kontinuierliche Code-Lieferung.

CI/CD erklärt

CI/CD ist ein Überbegriff, der mehrere DevOps-Phasen abdeckt. CI (kontinuierliche Integration) ist die Praxis, Codeänderungen mehrmals täglich in ein Repository zu integrieren. CD hat zwei Bedeutungen: Kontinuierliche Lieferung automatisiert die Code-Integrationen, während kontinuierliche Bereitstellung die endgültigen Builds automatisch an Endbenutzer freigibt. Die häufigen Tests von CI/CD reduzieren Codefehler und -defekte, was es für jeden DevOps-Workflow von entscheidender Bedeutung macht.

Was ist kontinuierliche Integration? (CI)

Kontinuierliche Integration (CI) ist ein automatisierter Softwareentwicklungsprozess, der die Geschwindigkeit der Entwicklung erhöht und gleichzeitig bei jeder Bereitstellung sauberen, qualitativ hochwertigen Code gewährleistet. Kontinuierliche Integration erfordert von Entwicklern, dass sie ihre Codeeinheiten häufig mehrmals täglich in ein zentrales gemeinsames Repository einchecken/committen.

CI ist eine DevOps-Best-Practice und eine Phase im DevOps-Lebenszyklus, in der Entwickler Code in ihr gemeinsames Code-Repository einchecken. Ein automatisiertes Build-Tool überprüft den Check-in oder Branch, um sicherzustellen, dass keine Fehler vorliegen und dass es bereit ist, in die Produktion zu gehen. Der Hauptvorteil hierbei ist, dass Probleme in der Regel frühzeitig erkannt werden, bevor sie sich zu größeren Problemen entwickeln können.

Das Üben von CI bedeutet, kleine Teilmengen von Änderungen in kürzerer Zeit zu integrieren, anstatt umfangreiche Updates, die länger dauern und seltener erfolgen. Die Automatisierung von Workflows für Tests, Zusammenführungen und das Einpflegen von Änderungen in ein gemeinsames Repository bedeutet, dass Teams saubereren Code schneller liefern können. Sauberer Code bedeutet schnellere Validierung, qualitativ hochwertigere Releases und eine effizientere Entwicklungs-Pipeline, die leichter skalierbar ist.

Wie funktioniert kontinuierliche Integration?

Kontinuierliche Integration ist ein einfacher und nahtloser Prozess, der in der Entwicklungsphase beginnt und in der Testumgebung endet. Kontinuierliche Integration ermöglicht es allen Entwicklern, kollaborativ zu arbeiten und ihren Code im Blick zu behalten. Jeder Entwickler "committet" seinen Code in kleinen Inkrementen in ein gemeinsames Code-Repository, auch bekannt als das Haupt-Repository. Das Code-Repository wird in einem Versionskontrollsystem wie Unity VCS, Perforce oder Git verwaltet. Jeder Commit, der in den Hauptzweig des Repositories (oder in Kindzweige, wenn Sie möchten) vorgenommen wird, kann einen automatisierten Build-Prozess auslösen, der mit einem Build-Management-System verknüpft ist, das den Code nimmt und einen Build erstellt. Sobald der Code in das Build-System integriert ist, haben die Entwickler vollen Zugriff auf ihre Code-Bauten. Von hier aus können sie sehen, ob ihr Code korrekt kompiliert wurde oder ob es einen Fehler gibt, den sie möglicherweise beheben müssen. Build-Systeme können so konfiguriert werden, dass sie verschiedene Test-Frameworks unterstützen.

Sobald der Code genehmigt ist und der Build-Zyklus erfolgreich ist, wird eine automatisierte Testumgebung ausgelöst, um die Qualität des Builds und des nachfolgenden Releases zu validieren. Da der Test- und Build-Prozess extrem schnell ist, können die Ergebnisse der Code-Commits schnell kommuniziert werden, was den Entwicklern ermöglicht, verbleibende Fehler zeitnah zu beheben. Dieser gesamte Prozess stellt sicher, dass der Codebestand gesund bleibt und alle weiterhin effizient arbeiten können.

Regeln und Prinzipien von CI

- Halten Sie ein zentrales Code-Repository

Das vorübergehende Speichern von Code von verschiedenen Entwicklern in verschiedenen Teams in separaten Repositories oder Systemen sollte auf ein Minimum beschränkt werden.

- Häufiges Committen/Einchecken von Code in das Haupt-Repository

Je länger ein Entwickler Code ohne Build oder Test hält, desto wahrscheinlicher ist es, dass er inkonsistent mit dem ist, was im zentralen Repository gespeichert ist.

- Halten Sie separate Build- und Testserver

Teams sollten dedizierte Maschinen nur für Build-Zwecke bereitstellen. Dies beschleunigt den Build-Prozess und minimiert die Auswirkungen auf die Workflows anderer Entwickler.

- Builds und Tests müssen automatisiert werden

Jedes Stück Code, das im zentralen Quellcode-Repository eingecheckt wird, sollte automatisch mit kontinuierlichen Integrationswerkzeugen gebaut und getestet werden.

- Verwenden Sie produktionsähnliche Testumgebungen

Testumgebungen sollten die endgültige Produktionsumgebung simulieren. Dies gewährleistet die Nützlichkeit der Testumgebung und hält die Erwartungen während des Deployments konsistent.

- Qualitätssicherungsteams sollten Zugang zu Builds haben

Wenn die QA Zugang zu Builds hat, kann jede Nichterfüllung der Produktionsanforderungen frühzeitig erkannt werden, was das Risiko verringert, später Code-Bauten überarbeiten zu müssen.

Kontinuierliche Bereitstellung vs. kontinuierliche Bereitstellung

Kontinuierliche Bereitstellung und kontinuierliche Bereitstellung sind Praktiken, die verwendet werden, um neuen Code so schnell und effizient wie möglich in die Produktion zu bringen. Die kontinuierliche Bereitstellung folgt der CI – Sie können es sich als eine Checkpoint-Phase in der Entwicklungspipeline vorstellen, bevor das Endprodukt an die Kunden freigegeben wird. Sobald Codeänderungen validiert sind, werden sie automatisch im zentralen Repository bereitgestellt.

Die kontinuierliche Bereitstellung folgt der CI im DevOps-Lebenszyklus, aber die beiden Prozesse sind miteinander verbunden. CI integriert Code mit Automatisierung in den Build; CD vervollständigt diesen Prozess. DevOps-Automatisierungen bewerten die Qualität der Updates. Sobald sie als fehlerfrei befunden wurden, werden sie automatisch in der Produktion bereitgestellt.

Was ist kontinuierliche Lieferung?

Kontinuierliche Lieferung bezieht sich auf den Aufbau, das Testen und die Bereitstellung von Codeänderungen an Software. In diesem Prozess durchläuft der Code verschiedene Testumgebungen, wie automatisierte Unit-Tests, Integrationstests und Systemtests, bevor er in die Produktion geschoben wird. Die kontinuierliche Lieferung erfolgt in produktionsähnlichen Staging-Umgebungen, in denen QAs den Code überprüfen, Fehler beheben und automatisierte Tests durchführen, um sicherzustellen, dass Builds immer bereit für die Bereitstellung und Veröffentlichung sind.

Mit kontinuierlicher Lieferung ist das Ziel, die Änderungssets so klein zu halten, dass keine Updates des Haupt-Builds den "produktionsbereiten" Status des Endprodukts gefährden. Das Endprodukt kann kleinere Fehler enthalten, aber nichts Substantielles, das das Benutzererlebnis beeinträchtigen könnte.

Die Praxis der kontinuierlichen Lieferung bedeutet, dass Entwickler weniger Zeit mit internen Tests verbringen können, da die Praxis sicherstellt, dass nur stabiler Code in die Bereitstellungsphase gelangt. Es macht die Fehlererkennung zu einem einfacheren Prozess und beschleunigt die Lösungszeit.

Was ist kontinuierliche Bereitstellung?

Die kontinuierliche Bereitstellung zielt darauf ab, Codeänderungen kontinuierlich aus dem zentralen Repository in die Produktion bereitzustellen, sobald der Build stabil ist. Das Betriebsteam stellt den kompilierten Code bereit und installiert die Software in verschiedenen Umgebungen (Entwicklung/Test, Staging und Produktion). Jede Änderung durchläuft eine automatisierte Pipeline, die eine funktionierende Version der Anwendung in die Produktion schiebt. Die Bereitstellung kann verschiedene Formen annehmen. Ein dunkles Release ist eine Bereitstellung, die für Benutzer verborgen ist, während Feature-Toggles oder Schalter verwendet werden können, um spezifische Teilmengen eines Änderungssets einer Benutzergruppe zum Testen und Feedback bereitzustellen.

Die kontinuierliche Bereitstellung hat zahlreiche Vorteile für Entwickler und Kunden. Entwickler, die kontinuierliche Bereitstellungslösungen verwenden, müssen sich nicht mehr um manuelle Build-Bereitstellungen kümmern und können sich auf anspruchsvollere Aufgaben konzentrieren. Automatisierung verkürzt die Feedbackschleifen, was bedeutet, dass Produkte schneller basierend auf Kundenfeedback aktualisiert werden können. Bei der kontinuierlichen Bereitstellung wird der Code in einer simulierten Umgebung ausgeführt und gewartet, die Qualität gewährleistet und eine Echtzeitüberwachung des Produkts ermöglicht. Das Hauptziel der kontinuierlichen Bereitstellung besteht darin, neue Versionen des Codes konsistent zu veröffentlichen und diese Änderungen automatisch an die Endbenutzer bereitzustellen.

Wie hängen CI/CD und DevOps zusammen?

Alle Softwareentwicklungen beginnen mit der Vorproduktion (der Planungsphase), gefolgt von der Produktion (Codierung und Erstellung von Assets). DevOps ist eine Kultur und ein Prozess, der darauf abzielt, diese Prozesse effizienter zu gestalten. CI/CD ist eine Phase innerhalb des DevOps-Lebenszyklus, die die Implementierung kleiner, aber stetiger Codeaktualisierungen im Laufe der Zeit vorschreibt, um eine kontinuierliche, iterative Verbesserung des Endprodukts sicherzustellen.

Regelmäßige, häufige Softwareveröffentlichungen können durch die Verwendung spezifischer Werkzeuge und Produkte erreicht werden, die die Integration, Lieferung und Bereitstellung von Codeänderungen ermöglichen – dies wird als CI/CD-Pipeline bezeichnet.

Eine CI/CD-Pipeline ist eine spezifische Reihe von Phasen, die an Werkzeuge und Automatisierung gebunden sind und es ermöglichen, dass der DevOps-Lebenszyklus stattfindet. Während CI/CD ein integraler Bestandteil einer DevOps-Kultur ist, umfasst DevOps viel mehr im gesamten Softwareentwicklungslebenszyklus – von Zusammenarbeit über Teamstruktur bis hin zu Beobachtbarkeit, Versionskontrolle und mehr.

Die Implementierung von DevOps variiert stark zwischen den Organisationen, aber im Kern kann DevOps nicht ohne CI/CD erreicht werden. Eine CI/CD-Pipeline ist intrinsisch mit einer DevOps-Kultur und ihrem Prozess kleiner, häufiger Veröffentlichungen verbunden.

Vorteile von CI/CD

- Schnelle Iteration

Die Einführung von CI/CD-Praktiken als Teil Ihres DevOps-Lebenszyklus beschleunigt die Entwicklung, indem die manuelle Arbeit zur Validierung und Bereitstellung von Änderungen am Code automatisiert wird.

- Sauberer Code

Die Überprüfung zahlreicher kleiner Änderungen im Laufe des Tages verringert erheblich das Risiko, dass fehlerhafte Änderungen in Ihren Quellcode eingeführt werden.

- Schnellere Fehlerbehebungen

Das häufigere Zusammenführen kleinerer Änderungssets mit CI/CD erleichtert es, Codefehler zu identifizieren und zu beheben, bevor sie zu einem größeren Problem werden.

- Kürzere Feedbackschleifen

CI/CD hilft, Feedbackschleifen zu verkürzen – ein zentrales DevOps-Prinzip – da kleinere, iterative Änderungen einfacher zu integrieren, zu testen und bereitzustellen sind.

- Bessere Zusammenarbeit

CI/CD bringt Klarheit in die Arbeit, indem Prozesse und Zeitpläne für Code-Commits und Build-Starts definiert werden. Mit klareren Zielen können Teams agiler arbeiten.

- Zufriedenere Kunden

Da Builds mit CI/CD immer bereit für die Veröffentlichung sind, erleben Kunden weniger Serviceunterbrechungen, und ihr Feedback kann viel schneller integriert werden.

Ist agil dasselbe wie CI/CD?

Ein agiler Workflow und CI/CD sind miteinander verbunden, jedoch nicht dasselbe! Sie beschreiben völlig unterschiedliche Aspekte der Softwareentwicklungspipeline. Agile Entwicklung bezieht sich auf die Prozesse oder Methoden zur Verwaltung von Workflows, Meeting-Rhythmen und Teamorganisation in der Softwareentwicklung. Eine agile Methodik akzeptiert Veränderungen, während sie die Lieferung beschleunigt, indem sie auf die Bedürfnisse der Kunden hört und reagiert und sie in jede Phase des Entwicklungsprozesses einbezieht.

CI/CD verlässt sich auf Automatisierung, um die menschlichen Elemente zu entfernen, die Engpässe bei der Veröffentlichung und Verbesserung der Software schaffen. In sowohl CI als auch CD wird das Testen automatisiert und häufig durchgeführt, um die Kosten und die Zeit zur Behebung von Mängeln zu minimieren.

Wie oft sollten Sie mit kontinuierlicher Bereitstellung in die Produktion deployen?

Mit CI/CD sollten Releases immer häufig sein, um zukünftige Probleme zu vermeiden und sicherzustellen, dass Ihre Software immer in einem freigabefähigen Zustand ist - typischerweise mehrmals täglich deployen. Eine gängige Annahme bei CI/CD-Teams sollte die Implementierung von "konstanten" Releases sein, jedoch ist dies nicht immer der Fall. Ihr Release-Zyklus kann je nach Produkt, Builds und anderen Faktoren, die Sie möglicherweise berücksichtigen möchten, stark variieren, wie zum Beispiel:

1. Ist es ein kritischer oder kleiner Fix?

2. Verfolgen Sie die Regressionen von Build zu Build?

3. Gibt es ein QA-Team?

4. Hat der Code-Basis Unit-Tests?

5. Gibt es Code-Duplikate?

Dies sind nur einige Beispiele für Aspekte, die bei der Überlegung einer Release-Strategie und Pipeline zu berücksichtigen sind, aber es variiert drastisch von Team zu Team. Verschiedene Produkte erfordern unterschiedliche Ansätze.

Ist kontinuierliche Bereitstellung es wert?

Es gibt keine universelle Antwort auf diese Frage. Bevor ein Unternehmen in kontinuierliche Bereitstellung investiert, muss es zunächst bewerten, was die größten Risiken seines Produkts sind, und dann die Kompromisse bestimmen, wie Sie Software bereitstellen möchten.

Der Erfolg Ihres Produkts hängt davon ab, schnell iterieren zu können, Feedback von Ihren Kunden zu erhalten und weiterhin Änderungen vorzunehmen. Kontinuierliche Bereitstellung wird sehr wirkungsvoll und profitabel sein, wenn Sie die Verkürzung der Feedback-Schleifen priorisieren und ein hochreaktives Unternehmen aufbauen.

Wenn Ihr Unternehmen jedoch nicht viele Kunden hat, werden die Vorteile der Implementierung von Bereitstellungsinkrementen weniger Wert und mehr Kosten hinzufügen. Die Staging-Umgebung, die Sie wählen, um zu deployen, hängt letztendlich von den Bedürfnissen Ihres Unternehmens, dem Workflow und dem Budget ab.

Kontinuierliche Lieferung fördert die Konfiguration, da sie kontinuierlich Änderungen am ursprünglichen Code in der Konfiguration vornimmt. Dies stellt sicher, dass die Konfiguration mit Codefehlern, die im Laufe der Zeit auftreten können, Schritt hält.