Im Vorfeld des Kursbeginns "CI / CD auf AWS, Azure und Gitlab" haben wir eine Übersetzung nützlichen Materials für Sie vorbereitet.
Continuous Integration (CI) und Continuous Delivery (CD) sind eine Kultur, eine Reihe von Prinzipien und Praktiken, mit denen Entwickler Softwareänderungen häufiger und zuverlässiger bereitstellen können.
CI / CD ist eine der DevOps-Praktiken . Dies gilt auch für agile Vorgehensweisen : Mithilfe der Bereitstellungsautomatisierung können sich Entwickler auf die Erfüllung der Geschäftsanforderungen, der Codequalität und der Sicherheit konzentrieren.
Definition von CI / CD
Continuous Integration ist eine Entwicklungsmethode und eine Reihe von Vorgehensweisen, bei denen kleine Änderungen am Code mit häufigen Festschreibungen vorgenommen werden. Und da die meisten modernen Anwendungen mit verschiedenen Plattformen und Tools entwickelt werden, sind ein Integrationsmechanismus und das Testen der eingeführten Änderungen erforderlich.
Technisch gesehen besteht das Ziel von CI darin, eine konsistente und automatisierte Möglichkeit zum Erstellen, Verpacken und Testen von Anwendungen bereitzustellen. Mit einem optimierten kontinuierlichen Integrationsprozess machen Entwickler häufiger Commits, was wiederum zur Verbesserung der Kommunikation und der Softwarequalität beiträgt.
Die kontinuierliche Lieferung beginnt dort, wo die kontinuierliche Integration endet. Es automatisiert die Bereitstellung von Anwendungen in verschiedenen Umgebungen: Die meisten Entwickler arbeiten sowohl mit einer Produktionsumgebung als auch mit Entwicklungs- und Testumgebungen.
Mit CI / CD-Tools können Sie bestimmte Umgebungseinstellungen anpassen, die während der Bereitstellung konfiguriert werden. Darüber hinaus führt die CI / CD-Automatisierung die erforderlichen Anforderungen an Webserver, Datenbanken und andere Dienste aus, die möglicherweise neu gestartet werden müssen, oder führt beim Bereitstellen der Anwendung einige zusätzliche Aktionen aus.
Kontinuierliche Integration und kontinuierliche Lieferung erfordern kontinuierliche Testsdenn das ultimative Ziel ist die Entwicklung hochwertiger Anwendungen. Kontinuierliche Tests werden häufig als eine Reihe verschiedener automatisierter Tests (Regression, Leistung usw.) implementiert, die in der CI / CD-Pipeline ausgeführt werden.
Die ausgereifte Praxis von CI / CD ermöglicht eine kontinuierliche Bereitstellung: Wenn der Code die CI / CD-Pipeline erfolgreich durchläuft, werden die Assemblys automatisch in der Produktionsumgebung bereitgestellt. Teams, die eine kontinuierliche Lieferung praktizieren, können sich eine tägliche oder sogar stündliche Bereitstellung leisten. Hierbei ist jedoch zu beachten, dass die kontinuierliche Bereitstellung nicht für alle Geschäftsanwendungen geeignet ist .
Kontinuierliche Integration verbessert Kommunikation und Qualität
Continuous Integration ist eine Entwicklungsmethode, die auf regulierten Prozessen und Automatisierung basiert. Bei kontinuierlicher Integration schreiben Entwickler ihren Code häufig in das Quellcode-Repository. Und die meisten Teams befolgen die Regel, mindestens einmal am Tag zu verpflichten. Kleine Änderungen sind leichter zu erkennen, Fehler und sonstige Probleme als große Änderungen, an denen über einen langen Zeitraum gearbeitet wurde. Darüber hinaus verringert die Arbeit mit kurzen Festschreibungszyklen die Wahrscheinlichkeit, dass mehrere Entwickler denselben Code ändern, was zu Zusammenführungskonflikten führen kann.
Teams, die eine kontinuierliche Integration implementieren, beginnen häufig mit der Einrichtung eines Versionskontrollsystems und der Definition eines Workflows. Trotz der Tatsache, dass häufig Commits durchgeführt werden, kann die Implementierung von Funktionen und die Behebung von Fehlern lange dauern. Es gibt verschiedene Ansätze, um zu steuern, welche Funktionen und welcher Code bereit sind.
Viele Benutzer verwenden Feature-Flags - einen Mechanismus zum Ein- und Ausschalten von Funktionen zur Laufzeit. Die Funktionen, die sich noch in der Entwicklung befinden, sind in Feature-Flags eingeschlossen und werden vom Hauptzweig bis zur Produktion bereitgestellt. Sie werden jedoch deaktiviert, bis sie vollständig einsatzbereit sind. Laut einer aktuellen Studie63 Prozent der Teams, die die Flag-Funktion verwenden, berichten von einer verbesserten Testbarkeit und einer verbesserten Softwarequalität. Es gibt spezielle Tools für die Arbeit mit Feature-Flags wie CloudBees Rollout , Optimizely Rollouts und LaunchDarkly , die in CI / CD integriert sind und die Konfiguration auf Feature-Ebene ermöglichen.
Eine andere Möglichkeit, mit Funktionen zu arbeiten, ist die Verwendung von Zweigen im Versionskontrollsystem. In diesem Fall müssen Sie ein Verzweigungsmodell definieren (z. B. Gitflow) und beschreiben, wie der Code in die Entwicklungs-, Test- und Produktionszweige gelangt. Für Features mit einem langen Entwicklungszyklus werden separate Feature-Zweige erstellt. Nach Abschluss der Arbeit an einem Feature führen Entwickler Änderungen aus dem Feature-Zweig in den Hauptentwicklungszweig zusammen. Dieser Ansatz funktioniert gut, kann jedoch unpraktisch sein, wenn viele Funktionen gleichzeitig entwickelt werden.
In der Erstellungsphase wird das Packen der erforderlichen Software, Datenbank und anderer Komponenten automatisiert. Wenn Sie beispielsweise eine Java-Anwendung entwickeln, packt das CI alle statischen Dateien wie HTML, CSS und JavaScript zusammen mit den Java-Anwendungs- und Datenbankskripten.
CI verpackt nicht nur alle Softwarekomponenten und Datenbanken, sondern führt auch automatisch Komponententests und andere Testarten durch. Durch diese Tests können Entwickler Feedback erhalten, dass die von ihnen vorgenommenen Änderungen nichts beeinträchtigt haben.
Mit den meisten CI / CD-Tools können Sie einen Build manuell, nach einem Commit oder nach einem Zeitplan starten. Die Teams müssen einen Build-Zeitplan besprechen, der auf der Grundlage der Teamgröße, der erwarteten täglichen Commits und anderer Kriterien zu ihnen passt. Es ist wichtig, dass Commits und Builds schnell sind. Andernfalls können lange Builds zu einem Hindernis für Entwickler werden, die versuchen, schnell und häufig Commits durchzuführen.
Kontinuierliches Testen ist mehr als Testautomatisierung
Automatisierte Test-Frameworks helfen QS-Ingenieuren beim Entwerfen, Ausführen und Automatisieren verschiedener Arten von Tests, mit denen Entwickler den Build-Erfolg verfolgen können. Das Testen umfasst Funktionstests, die am Ende jedes Sprints entwickelt und zu Regressionstests für die gesamte Anwendung kombiniert werden. Regressionstests informieren das Team, wenn durch Änderungen an anderer Stelle in der Anwendung Fehler aufgetreten sind.
Es wird empfohlen, von Entwicklern zu verlangen, dass sie alle oder einen Teil der Regressionstests in ihrer lokalen Umgebung ausführen. Dadurch wird sichergestellt, dass Entwickler bereits überprüften Code festschreiben.
Regressionstests sind nur der Anfang. Leistungstests, API-Tests, statische Code-Analyse, Sicherheitstests - diese und andere Testarten können ebenfalls automatisiert werden. Der entscheidende Punkt ist die Möglichkeit, diese Tests über die Befehlszeile, über einen Webhook oder über einen Webdienst auszuführen und das Ausführungsergebnis zurückzugeben: War der Test erfolgreich oder nicht?
Kontinuierliche Tests umfassen nicht nur die Automatisierung, sondern auch die Integration automatisierter Tests in die CI / CD-Pipeline. Einheiten- und Funktionstests können Teil des CI sein und Probleme vor oder während des Starts der CI-Pipeline identifizieren. Tests, die eine vollständige Bereitstellung der Umgebung erfordern, wie z. B. Leistungstests und Sicherheitstests, sind häufig Teil der CD und werden ausgeführt, nachdem die Builds in den Zielumgebungen bereitgestellt wurden.
Die CD-Pipeline automatisiert die Übermittlung von Änderungen an verschiedene Umgebungen
Die kontinuierliche Bereitstellung ist die automatische Bereitstellung einer Anwendung in ihrer Zielumgebung. In der Regel arbeiten Entwickler mit einer oder mehreren Entwicklungs- und Testumgebungen, in denen eine Anwendung zum Testen und Überprüfen bereitgestellt wird. Hierzu werden CI / CD-Tools wie Jenkins , CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo und Travis CI verwendet.
Eine typische CD-Pipeline besteht aus Schritten zum Erstellen, Testen und Bereitstellen. Komplexere Pipelines umfassen die folgenden Schritte:
- Abrufen von Code aus der Quellcodeverwaltung und Ausführen eines Builds.
- Automatisierte Konfiguration der Infrastruktur durch einen Infrastruktur-als-Code-Ansatz.
- Kopieren des Codes in die Zielumgebung.
- Festlegen von Umgebungsvariablen für die Zielumgebung.
- (-, API-, ).
- , , .
- .
- .
Beispiel: In der vom Jenkins-Förderer festgelegten Datei Jenkinsfile, in der die verschiedenen Schritte wie Zusammenbau (Erstellen), Testen (Testen) und Bereitstellen (Bereitstellen) beschrieben werden. Außerdem werden Umgebungsvariablen, geheime Schlüssel, Zertifikate und andere Parameter beschrieben, die in Pipeline-Phasen verwendet werden können. Der Post-Abschnitt konfiguriert die Fehlerbehandlung und Benachrichtigungen.
In einer komplexeren CD-Pipeline können zusätzliche Schritte erforderlich sein, z. B. Datensynchronisierung, Archivierung von Informationsressourcen, Installation von Updates und Patches. CI / CD-Tools unterstützen normalerweise Plugins. Jenkins verfügt beispielsweise über mehr als 1500 Plugins für die Integration in Plattformen von Drittanbietern, um die Benutzeroberfläche, die Verwaltung, die Quellcodeverwaltung und das Erstellen zu erweitern.
Bei Verwendung eines CI / CD-Tools müssen Entwickler sicherstellen, dass alle Parameter außerhalb der Anwendung über Umgebungsvariablen konfiguriert werden. Mit CI / CD-Tools können Sie die Werte dieser Variablen festlegen, Kennwörter und Kontoschlüssel maskieren und sie während der Bereitstellung für eine bestimmte Umgebung anpassen.
Auch in den CD-Tools gibt es Dashboards und Reporting. Im Falle eines Build- oder Lieferfehlers benachrichtigen sie darüber. Durch die Integration der CD in Versionskontrolle und agile Tools ist es einfacher, Codeänderungen und User Stories zu finden, die im Build enthalten sind.
Implementieren von CI / CD-Pipelines mit Kubernetes und serverlosen Architekturen
Viele Teams, die CI / CD-Pipelines in den Clouds verwenden, verwenden Container wie Docker und Orchestrierungssysteme wie Kubernetes . Container helfen bei der Standardisierung von Verpackung, Lieferung und vereinfachen die Skalierung und Zerstörung flüchtiger Umgebungen.
Es gibt viele Optionen für die gemeinsame Nutzung von Containern, Infrastruktur als Code und CI / CD-Pipelines. Weitere Informationen hierzu finden Sie in den Artikeln Kubernetes mit Jenkins und Kubernetes mit Azure DevOps .
Serverless Computing ist eine weitere Möglichkeit, Anwendungen bereitzustellen und zu skalieren. In einer Umgebung ohne Server wird die Infrastruktur vollständig vom Cloud-Anbieter verwaltet, und die Anwendung verbraucht je nach Einstellung Ressourcen nach Bedarf. In AWS werden beispielsweise serverlose Anwendungen über AWS Lambda-Funktionen ausgeführt , deren Bereitstellung mithilfe eines Plugins in die Jenkins CI / CD-Pipeline integriert werden kann.
CI / CD ermöglicht eine häufigere Codebereitstellung
Fassen wir also zusammen. CI-Pakete, Tests erstellen und benachrichtigen Entwickler, wenn etwas schief geht. Die CD stellt automatisch Anwendungen bereit und führt zusätzliche Tests aus.
CI / CD-Pipelines wurden für Unternehmen entwickelt, die häufige Änderungen an Anwendungen mit einem zuverlässigen Bereitstellungsprozess vornehmen müssen. Neben der Standardisierung von Builds, der Entwicklung von Tests und der Automatisierung von Bereitstellungen erhalten wir einen ganzheitlichen Workflow für die Bereitstellung von Codeänderungen. Durch die Implementierung von CI / CD können sich Entwickler auf die Verbesserung ihrer Anwendungen konzentrieren und keine Zeit mit deren Bereitstellung verschwenden.
CI / CD ist eine der DevOps-Praktikenweil es darauf abzielt, die Widersprüche zwischen Entwicklern, die häufige Änderungen vornehmen möchten, und der Nutzung, die Stabilität erfordert, zu bekämpfen. Mit der Automatisierung können Entwickler häufiger Änderungen vornehmen, und die Betriebsteams erhalten wiederum mehr Stabilität, da die Konfiguration der Umgebungen standardisiert ist und während des Bereitstellungsprozesses kontinuierliche Tests durchgeführt werden. Außerdem ist die Einstellung von Umgebungsvariablen von der Anwendung getrennt, und es gibt automatisierte Rollback-Verfahren.
Die Auswirkungen der Implementierung von CI / CD-Pipelines können anhand von DevOps Key Performance Indicators (KPIs) gemessen werden.... KPIs wie Bereitstellungshäufigkeit, Änderungsvorlaufzeit und mittlere Zeit bis zur Wiederherstellung verbessern sich häufig bei CI / CD-Bereitstellungen mit kontinuierlichen Tests. CI / CD ist jedoch nur ein Prozess, der zu diesen Verbesserungen beitragen kann. Es gibt andere Bedingungen zum Erhöhen der Lieferfrequenz.
Um mit CI / CD beginnen zu können, muss das Entwicklungs- und Betriebsteam bei Technologien, Praktiken und Prioritäten zusammenarbeiten. Die Teams müssen einen Konsens über die richtigen Ansätze für ihr Geschäft und ihre Technologie erzielen, damit das Team nach der Implementierung von CI / CD die gewählten Praktiken konsequent einhält.
CICD Tools Brief: Gitlab CI, Docker, Ansible