Was ist CI / CD? Kontinuierliche Integration und kontinuierliche Lieferung erklärt

Continuous Integration (CI) und Continuous Delivery (CD) verkörpern eine Kultur, eine Reihe von Funktionsprinzipien und eine Sammlung von Praktiken, die es Anwendungsentwicklungsteams ermöglichen, Codeänderungen häufiger und zuverlässiger bereitzustellen. Die Implementierung wird auch als CI / CD- Pipeline bezeichnet. 

CI / CD ist eine der Best Practices für die Implementierung von Entwicklerteams. Es handelt sich auch um eine bewährte Methode für agile Methoden, da sich Softwareentwicklungsteams auf die Erfüllung der Geschäftsanforderungen, der Codequalität und der Sicherheit konzentrieren können, da die Bereitstellungsschritte automatisiert sind.

CI / CD definiert

Kontinuierliche Integration  ist eine Codierungsphilosophie und eine Reihe von Methoden, die Entwicklungsteams dazu veranlassen, kleine Änderungen zu implementieren und Code häufig in Versionskontroll-Repositorys einzuchecken. Da die meisten modernen Anwendungen die Entwicklung von Code auf verschiedenen Plattformen und Tools erfordern, benötigt das Team einen Mechanismus zur Integration und Validierung seiner Änderungen.

Das technische Ziel von CI besteht darin, eine konsistente und automatisierte Methode zum Erstellen, Verpacken und Testen von Anwendungen zu etablieren. Aufgrund der Konsistenz des Integrationsprozesses führen Teams häufiger Codeänderungen durch, was zu einer besseren Zusammenarbeit und Softwarequalität führt.

Die kontinuierliche Lieferung setzt  dort an, wo die kontinuierliche Integration endet. CD automatisiert die Bereitstellung von Anwendungen für ausgewählte Infrastrukturumgebungen. Die meisten Teams arbeiten mit mehreren anderen Umgebungen als der Produktion, z. B. Entwicklungs- und Testumgebungen, und CD stellt sicher, dass es eine automatisierte Möglichkeit gibt, Codeänderungen auf sie zu übertragen.

CI / CD-Tools helfen beim Speichern der umgebungsspezifischen Parameter, die bei jeder Lieferung verpackt werden müssen. Die CI / CD-Automatisierung führt dann alle erforderlichen Dienstaufrufe an Webserver, Datenbanken und andere Dienste aus, die möglicherweise neu gestartet werden müssen, oder befolgt andere Verfahren, wenn Anwendungen bereitgestellt werden.

Kontinuierliche Integration und kontinuierliche Bereitstellung erfordern  kontinuierliche Tests,  da das Ziel darin besteht, den Benutzern hochwertige Anwendungen und Code bereitzustellen. Kontinuierliche Tests werden häufig als eine Reihe automatisierter Regressions-, Leistungs- und anderer Tests implementiert, die in der CI / CD-Pipeline ausgeführt werden.

Eine ausgereifte CI / CD-Entwicklungspraxis bietet die Möglichkeit, eine kontinuierliche Bereitstellung zu implementieren, bei der Anwendungsänderungen über die CI / CD-Pipeline ausgeführt werden und übergebende Builds direkt in Produktionsumgebungen bereitgestellt werden. Teams, die die kontinuierliche Lieferung praktizieren, entscheiden sich für die tägliche oder sogar stündliche Bereitstellung in der Produktion, obwohl die kontinuierliche Lieferung nicht immer für jede Geschäftsanwendung optimal ist.  

Zugehöriges Video: So liefern Sie Code mit CI / CD schneller

Wie kontinuierliche Integration die Zusammenarbeit und Qualität verbessert

Kontinuierliche Integration ist eine Entwicklungsphilosophie, die von der Prozessmechanik und einer gewissen Automatisierung unterstützt wird. Beim Üben von CI schreiben Entwickler ihren Code häufig in das Versionskontroll-Repository ein, und die meisten Teams haben mindestens täglich einen Mindeststandard für das Festschreiben von Code. Das Grundprinzip dahinter ist, dass es einfacher ist, Fehler und andere Probleme mit der Softwarequalität bei kleineren Codeunterschieden zu identifizieren, als bei größeren, die über einen längeren Zeitraum entwickelt wurden. Wenn Entwickler an kürzeren Festschreibungszyklen arbeiten, ist es außerdem weniger wahrscheinlich, dass mehrere Entwickler denselben Code bearbeiten und beim Festschreiben eine Zusammenführung benötigen.

Teams, die eine kontinuierliche Integration implementieren, beginnen häufig mit der Konfiguration der Versionskontrolle und den Übungsdefinitionen. Obwohl das Einchecken von Code häufig erfolgt, werden Funktionen und Korrekturen sowohl in kurzen als auch in längeren Zeiträumen implementiert. Entwicklungsteams, die eine kontinuierliche Integration praktizieren, verwenden verschiedene Techniken, um zu steuern, welche Funktionen und welcher Code für die Produktion bereit sind.

Viele Teams verwenden Feature-Flags , einen Konfigurationsmechanismus, um Features und Code zur Laufzeit ein- oder auszuschalten. Features, die sich noch in der Entwicklung befinden, werden mit Feature-Flags im Code umschlossen, mit dem Hauptzweig für die Produktion bereitgestellt und deaktiviert, bis sie verwendet werden können. Laut einer kürzlich durchgeführten Umfrage geben 63 Prozent der Teams, die Feature-Flags verwenden, bessere Tests und qualitativ hochwertigere Software an. Tools zum Markieren von Funktionen wie CloudBees Rollout, Optimizely Rollouts und LaunchDarkly lassen sich in CI / CD-Tools integrieren und ermöglichen Konfigurationen auf Funktionsebene.

Eine andere Technik zum Verwalten von Funktionen ist die  Versionskontrollverzweigung . Eine Verzweigungsstrategie wie Gitflow wird ausgewählt, um Protokolle darüber zu definieren, wie neuer Code für Entwicklung, Test und Produktion zu Standardzweigen zusammengeführt wird. Zusätzliche Feature-Zweige werden für solche erstellt, die längere Entwicklungszyklen benötigen. Wenn das Feature abgeschlossen ist, können die Entwickler die Änderungen aus den Feature-Zweigen in den primären Entwicklungszweig zusammenführen. Dieser Ansatz funktioniert gut, es kann jedoch schwierig werden, ihn zu verwalten, wenn viele Funktionen gleichzeitig entwickelt werden.

Der Erstellungsprozess selbst wird dann automatisiert, indem die gesamte Software, Datenbank und andere Komponenten gepackt werden. Wenn Sie beispielsweise eine Java-Anwendung entwickeln, packt CI alle statischen Webserver-Dateien wie HTML, CSS und JavaScript zusammen mit der Java-Anwendung und allen Datenbankskripten.

CI verpackt nicht nur alle Software- und Datenbankkomponenten, sondern die Automatisierung führt auch Komponententests und andere Tests durch. Diese Tests geben Entwicklern Feedback, dass ihre Codeänderungen keine vorhandenen Komponententests beschädigt haben.

Mit den meisten CI / CD-Tools können Entwickler Builds nach Bedarf starten, die durch Code-Commits im Versionskontroll-Repository oder nach einem definierten Zeitplan ausgelöst werden. Die Teams müssen den Build-Zeitplan besprechen, der für die Größe des Teams, die Anzahl der erwarteten täglichen Commits und andere Anwendungsüberlegungen am besten geeignet ist. Eine bewährte Methode, um sicherzustellen, dass Commits und Builds schnell sind. Andernfalls kann dies den Fortschritt von Teams behindern, die versuchen, schnell zu codieren und häufig Commits durchzuführen.

Kontinuierliches Testen geht über die Testautomatisierung hinaus

Mithilfe automatisierter Test-Frameworks können Qualitätssicherungsingenieure verschiedene Arten von Tests definieren, ausführen und automatisieren, mit denen Entwicklungsteams erkennen können, ob ein Software-Build erfolgreich ist oder nicht. Dazu gehören Funktionstests, die am Ende jedes Sprints entwickelt und zu einem Regressionstest für die gesamte Anwendung zusammengefasst werden. Diese Regressionstests informieren das Team dann darüber, ob eine Codeänderung einen oder mehrere der in allen Funktionsbereichen der Anwendung entwickelten Tests fehlgeschlagen hat, in denen eine Testabdeckung besteht.

Eine bewährte Methode besteht darin, Entwickler zu aktivieren und zu verpflichten, alle oder einen Teil der Regressionstests in ihren lokalen Umgebungen auszuführen. Dieser Schritt stellt sicher, dass Entwickler Code erst dann zur Versionskontrolle übergeben, nachdem Regressionstests die Codeänderungen weitergegeben haben.

Regressionstests sind nur der Anfang. Leistungstests, API-Tests, statische Code-Analysen, Sicherheitstests und andere Testformulare können ebenfalls automatisiert werden. Der Schlüssel besteht darin, diese Tests entweder über die Befehlszeile, den Webhook oder den Webdienst auslösen zu können und mit Erfolgs- oder Fehlerstatuscodes zu antworten.

Sobald das Testen automatisiert ist, bedeutet kontinuierliches Testen, dass die Automatisierung in die CI / CD-Pipeline integriert ist. Einige Einheiten- und Funktionalitätstests können in CI integriert werden, um Probleme vor oder während des Integrationsprozesses zu kennzeichnen. Tests, die eine vollständige Bereitstellungsumgebung erfordern, wie z. B. Leistungs- und Sicherheitstests, werden häufig in CD integriert und ausgeführt, nachdem Builds an Zielumgebungen geliefert wurden.

Die CD-Pipeline automatisiert Änderungen an mehreren Umgebungen

Continuous Delivery ist die Automatisierung, mit der Anwendungen in Bereitstellungsumgebungen übertragen werden. Die meisten Entwicklungsteams verfügen normalerweise über eine oder mehrere Entwicklungs- und Testumgebungen, in denen Anwendungsänderungen zum Testen und Überprüfen bereitgestellt werden. Ein CI / CD-Tool wie Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo oder Travis CI wird verwendet, um die Schritte zu automatisieren und Berichte bereitzustellen.

Eine typische CD-Pipeline verfügt über Phasen zum Erstellen, Testen und Bereitstellen. Anspruchsvollere Pipelines umfassen viele dieser Schritte:

  • Code aus der Versionskontrolle ziehen und einen Build ausführen.
  • Ausführen aller erforderlichen Infrastrukturschritte, die als Code automatisiert sind, um die Cloud-Infrastruktur hoch- oder herunterzufahren.
  • Verschieben von Code in die Zielcomputerumgebung.
  • Verwalten der Umgebungsvariablen und Konfigurieren dieser für die Zielumgebung.
  • Übertragen von Anwendungskomponenten auf die entsprechenden Dienste, z. B. Webserver, API-Dienste und Datenbankdienste.
  • Ausführen aller Schritte, die zum Neustarten von Diensten oder zum Aufrufen von Dienstendpunkten erforderlich sind, die für neue Code-Pushs erforderlich sind.
  • Ausführen kontinuierlicher Tests und Rollback-Umgebungen, wenn Tests fehlschlagen.
  • Bereitstellung von Protokolldaten und Warnungen zum Status der Lieferung.

Als Beispiel definieren Jenkins-Benutzer ihre Pipelines in einer Jenkins-Datei, die verschiedene Phasen wie Erstellen, Testen und Bereitstellen beschreibt. Umgebungsvariablen, Optionen, geheime Schlüssel, Zertifizierungen und andere Parameter werden in der Datei deklariert und dann schrittweise referenziert. Der Beitragsabschnitt behandelt Fehlerbedingungen und Benachrichtigungen.  

Anspruchsvollere CDs können andere Schritte enthalten, z. B. das Durchführen von Datensynchronisierungen, das Archivieren von Informationsressourcen oder das Durchführen von Patches für Anwendungen und Bibliotheken. CI / CD-Tools unterstützen normalerweise einen Marktplatz für Plug-Ins. Jenkins listet beispielsweise mehr als 1.500 Plug-Ins auf, die die Integration in Plattformen von Drittanbietern, die Benutzeroberfläche, die Verwaltung, die Quellcodeverwaltung und die Buildverwaltung unterstützen.

Sobald ein CI / CD-Tool ausgewählt ist, müssen Entwicklungsteams sicherstellen, dass alle Umgebungsvariablen außerhalb der Anwendung konfiguriert sind. Mit CI / CD-Tools können Sie diese Variablen festlegen, Variablen wie Kennwörter und Kontoschlüssel maskieren und zum Zeitpunkt der Bereitstellung für die Zielumgebung konfigurieren.

CD-Tools bieten auch Dashboard- und Berichtsfunktionen. Wenn Builds oder Lieferungen fehlschlagen, werden Entwickler mit Informationen zu den Fehlern benachrichtigt. Sie lassen sich in die Versionskontrolle und in agile Tools integrieren, sodass Sie nachschlagen können, welche Codeänderungen und User Stories einen Build ausmachen.

Implementierung von CI / CD-Pipelines mit Kubernetes und serverlosen Architekturen 

Viele Teams, die CI / CD-Pipelines in Cloud-Umgebungen betreiben, verwenden auch Container wie Docker und Orchestrierungssysteme wie Kubernetes. Container ermöglichen Verpackungs- und Versandanwendungen auf standardmäßige, tragbare Weise. Container erleichtern das Skalieren oder Herunterfahren von Umgebungen mit variabler Arbeitslast.

Es gibt viele Ansätze, Container, Infrastruktur als Code und CI / CD-Pipelines zusammen zu verwenden. Sie können die Optionen erkunden, indem Sie Tutorials wie Kubernetes mit Jenkins oder Kubernetes mit Azure DevOps durcharbeiten.

Serverlose Computerarchitekturen bieten eine weitere Möglichkeit zum Bereitstellen und Skalieren von Anwendungen. In einer Umgebung ohne Server wird die Infrastruktur vollständig vom Cloud-Dienstanbieter verwaltet, und die Anwendung verbraucht je nach Konfiguration Ressourcen nach Bedarf. In AWS können beispielsweise serverlose Anwendungen, die als Lambda-Funktionen ausgeführt werden, und Bereitstellungen mit einem Plug-In in eine Jenkins CI / CD-Pipeline integriert werden. 

CI / CD ermöglicht häufigere Codebereitstellungen

Zusammenfassend lässt sich sagen, dass CI-Pakete und Testsoftware Entwickler erstellen und benachrichtigen, wenn ihre Änderungen bei Komponententests fehlgeschlagen sind. CD ist die Automatisierung, die Änderungen an der Infrastruktur bereitstellt und zusätzliche Tests ausführt. 

CI / CD-Pipelines wurden für Unternehmen entwickelt, die Anwendungen häufig verbessern möchten und einen zuverlässigen Bereitstellungsprozess benötigen. Der zusätzliche Aufwand zur Standardisierung von Builds, zur Entwicklung von Tests und zur Automatisierung von Bereitstellungen ist der Herstellungsprozess für die Bereitstellung von Codeänderungen. Einmal eingerichtet, können sich die Teams auf den Prozess der Verbesserung von Anwendungen konzentrieren und weniger auf die Systemdetails für die Bereitstellung in Computerumgebungen.

CI / CD ist eine bewährte Methode für Entwickler, da sie die Fehlausrichtung zwischen Entwicklern, die häufig Änderungen vornehmen möchten, und Vorgängen, die stabile Anwendungen erfordern, behebt. Mit der Automatisierung können Entwickler Änderungen häufiger vornehmen. Betriebsteams sehen eine größere Stabilität, da Umgebungen Standardkonfigurationen haben, der Bereitstellungsprozess kontinuierlich getestet wird, Umgebungsvariablen von der Anwendung getrennt werden und Rollback-Verfahren automatisiert werden.

Die Auswirkungen der Implementierung von CI / CD-Pipelines können als Devops Key Performance Indicator (KPI) gemessen werden. KPIs wie Bereitstellungshäufigkeit, Änderungsvorlaufzeit und mittlere Zeit bis zur Wiederherstellung (MTTR) nach einem Vorfall werden häufig verbessert, wenn CI / CD mit kontinuierlichen Tests implementiert wird. CI / CD ist jedoch nur ein Prozess, der diese Verbesserungen vorantreiben kann, und es gibt andere Voraussetzungen für die Verbesserung der Bereitstellungshäufigkeiten.

Für den Einstieg in CI / CD müssen Entwicklungsteams und Betriebsteams an Technologien, Praktiken und Prioritäten zusammenarbeiten. Die Teams müssen einen Konsens über die richtigen Ansätze für ihr Geschäft und ihre Technologien entwickeln, damit das Team, sobald CI / CD installiert ist, konsequent die folgenden Praktiken befolgt.