Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

CI/CD verstehen

Continuous Integration and Continuous Delivery (CI/CD) ist der Prozess der Automatisierung des Lebenszyklus von Softwareversionen. In einigen Fällen kann das D in CI/CD auch Bereitstellung bedeuten. Der Unterschied zwischen Continuous Delivery und Continuous Deployment tritt auf, wenn Sie eine Änderung an der Produktionsumgebung veröffentlichen. Bei Continuous Delivery ist eine manuelle Genehmigung erforderlich, bevor Änderungen an der Produktion vorgenommen werden. Die kontinuierliche Bereitstellung ermöglicht einen unterbrechungsfreien Ablauf der gesamten Pipeline, und es sind keine ausdrücklichen Genehmigungen erforderlich. Da in dieser Strategie allgemeine CI/CD-Konzepte behandelt werden, gelten die bereitgestellten Empfehlungen und Informationen sowohl für die kontinuierliche Bereitstellung als auch für die kontinuierliche Bereitstellung.

CI/CD automates much or all of the manual processes traditionally required to get new code from a commit into production. A CI/CD pipeline encompasses the source, build, test, staging, and production stages. In each stage, the CI/CD pipelines provisions any infrastructure that is needed to deploy or test the code. By using a CI/CDIn der Pipeline können Entwicklungsteams Änderungen am Code vornehmen, die dann automatisch getestet und zur Bereitstellung weitergeleitet werden.

Sehen wir uns die grundlegenden CI/CD process before discussing some of the ways that you can, knowingly or unknowingly, deviate from being fully CI/CD. The following diagram shows the CI/CD Phasen und Aktivitäten in jeder Phase an.

Über kontinuierliche Integration

Die kontinuierliche Integration erfolgt in einem Code-Repository, z. B. einem Git-Repository in GitHub. Sie behandeln einen einzelnen Hauptzweig als Informationsquelle für die Codebasis und erstellen kurzlebige Zweige für die Feature-Entwicklung. Sie integrieren einen Feature-Branch in den Hauptzweig, wenn Sie bereit sind, das Feature in höheren Umgebungen bereitzustellen. Feature-Branches werden niemals direkt in höheren Umgebungen bereitgestellt. Weitere Informationen finden Sie unter Trunk-basierter Ansatz in diesem Handbuch.

Kontinuierlicher Integrationsprozess

Über kontinuierliche Lieferung

Continuous Delivery findet in isolierten Umgebungen statt, z. B. in Entwicklungs- und Produktionsumgebungen. Die Aktionen, die in den einzelnen Umgebungen ausgeführt werden, können variieren. Oft wird eine der ersten Phasen verwendet, um Aktualisierungen an der Pipeline selbst vorzunehmen, bevor der Vorgang fortgesetzt wird. Das Endergebnis der Bereitstellung ist, dass jede Umgebung mit den neuesten Änderungen aktualisiert wird. Die Anzahl der Entwicklungsumgebungen zum Erstellen und Testen variiert ebenfalls, wir empfehlen jedoch, mindestens zwei zu verwenden. In der Pipeline wird jede Umgebung in der Reihenfolge ihrer Bedeutung aktualisiert, bis die wichtigste Umgebung, die Produktionsumgebung, abgeschlossen wird.

Kontinuierlicher Lieferprozess

Der Continuous-Delivery-Teil der Pipeline wird initiiert, indem der Code aus dem Hauptzweig des Quell-Repositorys abgerufen und an die Build-Phase übergeben wird. Das Dokument Infrastructure as Code (IaC) für das Repository beschreibt die Aufgaben, die in den einzelnen Phasen ausgeführt werden. Die Verwendung eines IaC-Dokuments ist zwar nicht verpflichtend, es wird jedoch dringend empfohlen, einen IaC-Dienst oder ein IaC-Tool wie AWS CloudFormationoder AWS Cloud Development Kit (AWS CDK)zu verwenden. Zu den gängigsten Schritten gehören:

Wenn in einer Phase der Pipeline Fehler auftreten oder Tests fehlschlagen, wird die aktuelle Phase auf ihren vorherigen Status zurückgesetzt und die Pipeline wird beendet. Nachfolgende Änderungen müssen im Code-Repository beginnen und den vollständigen CI/CD-Prozess durchlaufen.