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 CI/CD kann das *D-In* 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. Bei der kontinuierlichen Bereitstellung ist ein unterbrechungsfreier Ablauf der gesamten Pipeline gewährleistet, und es sind keine ausdrücklichen Genehmigungen erforderlich. Da in dieser Strategie allgemeine CI/CD Konzepte behandelt werden, gelten die 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.
Lassen Sie uns zunächst den grundlegenden CI/CD Prozess überprüfen, bevor wir einige der Möglichkeiten besprechen, wie Sie wissentlich oder unwissentlich in jeder Phase von vollständigen CI/CD. The following diagram shows the CI/CD Phasen und Aktivitäten abweichen können.
![\[Die fünf Phasen eines CI/CD Prozesses sowie die Aktivitäten und Umgebungen der einzelnen Phasen.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## Über kontinuierliche Integration
Die kontinuierliche Integration erfolgt in einem Code-Repository, z. B. einem Git-Repository inGitHub. Sie behandeln einen einzelnen Hauptzweig als Informationsquelle für die Codebasis, und Sie 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](fully-cicd-process-differences.md#trunk-based-approach) in diesem Handbuch.
*Kontinuierlicher Integrationsprozess*
1. Der Entwickler erstellt aus dem Hauptzweig einen neuen Zweig.
1. Der Entwickler nimmt Änderungen vor und erstellt und testet lokal.
1. Wenn die Änderungen fertig sind, erstellt der Entwickler eine [Pull-Anfrage](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub Dokumentation) mit dem Hauptzweig als Ziel.
1. Der Code wird überprüft.
1. Wenn der Code genehmigt ist, wird er mit dem Hauptzweig zusammengeführt.
## Über Continuous Delivery
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 CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)oder [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)zu verwenden. Zu den gängigsten Schritten gehören:
1. Komponententests
1. Code erstellen
1. Bereitstellung von Ressourcen
1. Integrationstests
Wenn in einer beliebigen 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 gesamten CI/CD Prozess durchlaufen.
# Tests für CI/CD Pipelines
Die beiden Arten automatisierter Tests, auf die in Bereitstellungspipelines häufig Bezug genommen wird, sind *Komponententests* und *Integrationstests*. Es gibt jedoch viele Arten von Tests, die Sie auf einer Codebasis und in der Entwicklungsumgebung ausführen können. Die [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/application-pipeline/) definiert die folgenden Testtypen:
+ **Komponententest** — Diese Tests erstellen Anwendungscode und führen ihn aus, um zu überprüfen, ob er erwartungsgemäß funktioniert. Sie simulieren alle externen Abhängigkeiten, die in der Codebasis verwendet werden. Beispiele für Unit-Test-Tools sind [JUnit](https://junit.org/)[Jest](https://jestjs.io/) und [Pytest](https://pytest.org/).
+ **Integrationstest** — Diese Tests verifizieren, dass die Anwendung die technischen Anforderungen erfüllt, indem sie anhand einer bereitgestellten Testumgebung getestet werden. Beispiele für Integrationstesttools sind [Cucumber](https://cucumber.io/), [vRest NG](https://vrest.io/) und [Integ-Tests](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) (for). AWS CDK
+ **Akzeptanztest** — Diese Tests verifizieren, dass die Anwendung die Benutzeranforderungen erfüllt, indem sie anhand einer bereitgestellten Testumgebung getestet werden. [Zu den Tools für Akzeptanztests gehören beispielsweise [Cypress](https://cypress.io/) und Selenium.](https://selenium.dev/)
+ **Synthetischer Test** — Diese Tests werden kontinuierlich im Hintergrund ausgeführt, um Traffic zu generieren und zu überprüfen, ob das System fehlerfrei ist. Beispiele für synthetische Testtools sind [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) und [Dynatrace](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/) Synthetic Monitoring.
+ **Leistungstest** — Diese Tests simulieren die Produktionskapazität. Sie ermitteln, ob die Anwendung die Leistungsanforderungen erfüllt, und vergleichen die Kennzahlen mit der Leistung in der Vergangenheit. Zu den Tools für Leistungstests gehören beispielsweise [Apache JMeter](https://jmeter.apache.org/), [Locust](https://locust.io/) und [Gatling](https://gatling.io/).
+ **Resilienztest** — Diese Tests, auch *Chaostests* genannt, führen zu Fehlern in Umgebungen, um Risikobereiche zu identifizieren. Perioden, in denen die Fehler auftreten, werden dann mit Perioden ohne Fehler verglichen. Zu den Tools für Resilienz-Tests gehören beispielsweise [AWS Fault Injection Service](https://aws.amazon.com/fis/)[Gremlin](https://www.gremlin.com/).
+ **Statischer Anwendungssicherheitstest (SAST)** — Diese Tests analysieren Code auf Sicherheitsverletzungen wie [SQL-Injection](https://owasp.org/www-community/attacks/SQL_Injection) oder [Cross-Site Scripting](https://owasp.org/www-community/attacks/xss/) (XSS). Beispiele für SAST-Tools sind [Amazon CodeGuru](https://aws.amazon.com/codeguru/) und [SonarQube](https://www.sonarqube.org/)[Checkmarx](https://checkmarx.com/).
+ **Dynamischer Anwendungssicherheitstest (DAST)** *— Diese Tests werden auch als *Penetrationstests oder Penetrationstests* bezeichnet.* Sie identifizieren Sicherheitslücken wie SQL-Injection oder XSS in einer bereitgestellten Testumgebung. [Beispiele für DAST-Tools sind [Zed Attack Proxy (ZAP](https://www.zaproxy.org/)) und HCL. AppScan](https://www.hcltechsw.com/appscan) [Weitere Informationen finden Sie unter Penetrationstests.](https://aws.amazon.com/security/penetration-testing/)
Nicht alle CI/CD Full-Pipelines führen alle diese Tests durch. Eine Pipeline sollte jedoch mindestens Unit-Tests und SAST-Tests auf der Codebasis sowie Integrations- und Akzeptanztests in einer Testumgebung ausführen.
# Metriken für Pipelines CI/CD
Gemäß der [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/application-pipeline/) sollten Sie mindestens die folgenden vier Metriken für Pipelines verfolgen: CI/CD
+ **Vorlaufzeit** — Die durchschnittliche Zeit, die ein einzelnes Commit benötigt, um in die Produktion überzugehen. Wir empfehlen, je nach Anwendungsfall eine Vorlaufzeit zwischen 1 Stunde und 1 Tag anzustreben.
+ **Bereitstellungshäufigkeit** — Die Anzahl der Produktionsbereitstellungen innerhalb eines bestimmten Zeitraums. Wir empfehlen, die Bereitstellungshäufigkeit je nach Anwendungsfall zwischen mehrmals täglich und zweimal pro Woche festzulegen.
+ **Mittlere Zeit zwischen Ausfällen (MTBF)** — Die durchschnittliche Zeit zwischen dem Start einer erfolgreichen Pipeline und dem Start einer ausgefallenen Pipeline. Wir empfehlen, eine möglichst hohe MTBF anzustreben. [Weitere Informationen finden Sie unter Erhöhung der MTBF.](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html)
+ **Mittlere Zeit bis zur Wiederherstellung (MTTR)** — Die durchschnittliche Zeit zwischen dem Start einer ausgefallenen Pipeline und dem Start der nächsten erfolgreichen Pipeline. Wir empfehlen, eine MTTR anzustreben, die so niedrig wie möglich ist. [Weitere Informationen finden Sie unter MTTR reduzieren.](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
Diese Kennzahlen helfen Teams dabei, ihre Fortschritte auf dem Weg zu einer vollständigen CI/CD-Implementierung nachzuvollziehen. Die Teams sollten offene Diskussionen mit den Stakeholdern der Organisation darüber führen, was die optimalen Ziele sein sollten. Situationen und Bedürfnisse sind von Organisation zu Organisation und sogar von Team zu Team sehr unterschiedlich.
Es ist sehr wichtig, sich daran zu erinnern, dass schnelle, drastische Veränderungen in der Regel das Risiko erhöhen, dass Probleme auftreten. Setzen Sie sich Ziele, um kleine, schrittweise Verbesserungen anzustreben. Eine übliche optimale Vorlaufzeit für vollständige CI/CD Pipelines beträgt weniger als 3 Stunden. Ein Team, das mit einer Vorlaufzeit von 5,2 Tagen beginnt, sollte eine Reduzierung um einen Tag alle paar Wochen anstreben. Sobald dieses Team eine Vorlaufzeit von einem Tag oder weniger erreicht hat, kann es dort mehrere Monate bleiben und nur dann zu einer aggressiveren Vorlaufzeit übergehen, wenn das Team und die Interessengruppen der Organisation dies für notwendig halten.