# Continuous Integration und Continuous Delivery implementieren
In diesem Abschnitt wird erläutert, wie Sie mit der Implementierung eines CI/CD-Modells in Ihrer Organisation beginnen können. Thema dieses Whitepapers ist es dagegen nicht, wie eine Organisation mit einem ausgereiften DevOps- und Cloud-Transformationsmodell eine CI/CD-Pipeline entwickelt und verwendet. Um Sie auf Ihrem DevOps-Weg zu unterstützen, verfügt AWS über eine Reihe [zertifizierter DevOps-Partner](https://aws.amazon.com/devops/partner-solutions/), die Ressourcen und Tools bereitstellen können. Weitere Informationen zur Vorbereitung einer Umstellung auf die AWS Cloud finden Sie im Whitepaper [Aufbau eines Cloud-Betriebsmodells](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf).
# Der Weg zu Continuous Integration/Continuous Delivery (CI/CD)
Sie können sich CI/CD als Pipeline vorstellen (siehe folgende Abbildung): Neuer Code wird an einem Ende eingereicht, in verschiedenen Phasen (Quelle, Entwicklung, Staging und Produktion) getestet und dann als produktionsbereiter Code veröffentlicht. Wenn Ihre Organisation noch nicht mit CI/CD vertraut ist, kann sie sich dieser Pipeline iterativ nähern. Das bedeutet, dass Sie klein anfangen und in jeder Phase iterieren sollten, damit Sie Ihren Code so verstehen und entwickeln können, dass er das Wachstum Ihrer Organisation unterstützt.
![\[CI/CD-Pipeline\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
* CI/CD-Pipeline *
Jede Phase der CI/CD-Pipeline stellt im Bereitstellungsprozess eine logische Einheit dar. Darüber hinaus fungiert jede Stufe als Tor, das einen bestimmten Aspekt des Codes untersucht. Wenn der Code die Pipeline durchläuft, sollte seine Qualität in den späteren Phasen höher sein, da ja immer mehr Aspekte überprüft werden. Werden in einer frühen Phase Probleme erkannt, durchläuft der Code die Pipeline nicht weiter. Die Ergebnisse der Tests werden sofort an das Team gesendet und alle weiteren Builds und Releases werden gestoppt, wenn die Software eine Phase nicht erfolgreich besteht.
Diese Phasen sind lediglich Vorschläge. Sie können die Phasen natürlich an Ihre Geschäftsanforderungen anpassen. Einige Phasen können für mehrere Arten von Tests, Sicherheit und Leistung wiederholt werden. Abhängig von der Komplexität Ihres Projekts und der Struktur Ihrer Teams können einige Phasen auf verschiedenen Ebenen mehrmals wiederholt werden. So kann das Endprodukt eines Teams beispielsweise zu einer Abhängigkeit im Projekt des nächsten Teams werden. Dies bedeutet, dass das Endprodukt des ersten Teams anschließend als Artefakt im Projekt des nächsten Teams verwendet wird.
Das Vorhandensein einer CI/CD-Pipeline hat große Auswirkungen auf die Reifung der Fähigkeiten Ihrer Organisation. Die Organisation sollte mit kleinen Schritten beginnen und nicht gleich versuchen, eine vollständig ausgereifte Pipeline mit mehreren Umgebungen, vielen Testphasen und Automatisierung in allen Phasen aufzubauen. Denken Sie daran, dass selbst Organisationen mit hochausgereiften CI/CD-Umgebungen ihre Pipelines kontinuierlich verbessern müssen.
Der Aufbau einer CI/CD-fähigen Organisation ist eine Reise mit vielen Zielen entlang des Weges. Im nächsten Abschnitt wird ein möglicher Weg beschrieben, den Ihre Organisation einschlagen könnte, angefangen bei der Continuous Integration bis hin zu den verschiedenen Stufen der Continuous Delivery.
# Continuous Integration
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
* Continuous Integration – Quelle und Entwicklung *
Die erste Phase der CI/CD-Reise besteht darin, hinsichtlich der Continuous Integration zu reifen. Sie sollten sicherstellen, dass alle Entwickler ihren Code regelmäßig in ein zentrales Repository (das z. B. in CodeCommit oder GitHub gehostet wird) übergeben und alle Änderungen in einem Release-Zweig für die Anwendung zusammenführen. Kein Entwickler sollte über isolierten Code verfügen. Wenn ein Funktionszweig für einen bestimmten Zeitraum benötigt wird, sollte er durch möglichst häufige Zusammenführungen aus dem Upstream auf dem neuesten Stand gehalten werden. Häufige Commits und Zusammenführungen mit abgeschlossenen Arbeitsschritten werden dem Team empfohlen, um eine Routine zu entwickeln, und werden durch den Prozess gefördert. Ein Entwickler, der Code früh und häufig zusammenführt, muss später wahrscheinlich weniger Integrationsprobleme beheben.
Sie sollten Entwickler außerdem dazu anhalten, so früh wie möglich Einheitentests für ihre Anwendungen zu erstellen und diese Tests durchzuführen, bevor sie den Code in das zentrale Repository übertragen. Fehler, die in den Anfangsphasen der Softwareentwicklung erkannt werden, sind mit weniger Zeit- und Kostenaufwand zu beheben.
Wenn der Code in einen Zweig in einem Quellcode-Repository übertragen wird, sendet eine Workflow-Engine, die diesen Zweig überwacht, einen Befehl an ein Entwickler-Tool, um den Code zu erstellen und die Einheitentests in einer kontrollierten Umgebung durchzuführen. Der Entwicklungsprozess sollte entsprechend dimensioniert sein, um alle Aktivitäten zu verarbeiten, einschließlich Übertragungen und Tests, die während der Commit-Phase stattfinden können, um ein schnelles Feedback zu erhalten. In dieser Phase können auch andere Qualitätsprüfungen wie die Abdeckung von Einheitentests, Stilprüfung und statische Analyse durchgeführt werden. Schließlich erstellt das Entwickler-Tool einen oder mehrere binäre Builds und andere Artefakte wie Bilder, Stylesheets und Dokumente für die Anwendung.
# Continuous Delivery: Eine Staging-Umgebung erstellen
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
* Continuous Delivery – Staging *
Continuous Delivery (CD) ist die nächste Phase und umfasst die Bereitstellung des Anwendungscodes in einer Staging-Umgebung, bei der es sich um ein Replikat des Produktionsstacks handelt, und das Ausführen weiterer Funktionstests. Die Staging-Umgebung kann eine statische Umgebung sein, die zum Testen vorgefertigt wurde. Sie können aber auch eine dynamische Umgebung mit festgeschriebener Infrastruktur und Konfigurationscode zum Testen und Bereitstellen des Anwendungscodes bereitstellen und konfigurieren.
# Continuous Delivery: Eine Produktionsumgebung erstellen
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
* Continuous Delivery – Produktion *
In der Bereitstellungspipeline folgt nach der Staging-Umgebung die Produktionsumgebung, die ebenfalls mithilfe von Infrastructure as Code (IaC) entwickelt wird.
# Continuous Deployment
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
* Continuous Deployment *
Die letzte Phase der CI/CD-Bereitstellungspipeline ist das Continuous Deployment, was die vollständige Automatisierung des gesamten Software-Release-Prozesses einschließlich der Bereitstellung in der Produktionsumgebung umfassen kann. In einer vollständig ausgereiften CI/CD-Umgebung ist der Pfad zur Produktionsumgebung vollständig automatisiert, sodass Code mit hoher Sicherheit bereitgestellt werden kann.
# Reife und Weiterentwicklung
Wenn Ihre Organisation reift, entwickelt sie das CI/CD-Modell weiter, um weitere der folgenden Verbesserungen einzubeziehen:
+ Zusätzliche Staging-Umgebungen für spezifische Leistungs-, Compliance-, Sicherheits- und Benutzeroberflächen (UI)-Tests
+ Einheitentests der Infrastruktur und des Konfigurationscodes zusammen mit dem Anwendungscode
+ Integration mit anderen Systemen und Prozessen wie Codeüberprüfung, Problemverfolgung und Ereignisbenachrichtigung
+ Integration mit Datenbankschemamigration (falls zutreffend)
+ Zusätzliche Schritte für die Prüfung und Geschäftsgenehmigung
Selbst die ausgereiftesten Organisationen, die komplexe CI/CD-Pipelines mit mehreren Umgebungen verwenden, versuchen ihre Prozesse kontinuierlich zu verbessern. DevOps ist kein Ziel, sondern eine Reise. Es wird kontinuierlich Feedback zur Pipeline eingeholt. Verbesserungen von Geschwindigkeit, Skalierung, Sicherheit und Zuverlässigkeit werden durch die Zusammenarbeit der verschiedenen Entwicklungsteams erzielt.
# Teams
AWS empfiehlt, drei Entwicklerteams für die Implementierung einer CI/CD-Umgebung zusammenzustellen: ein Anwendungsteam, ein Infrastrukturteam und ein Toolsteam (siehe folgende Abbildung). Diese Struktur basiert auf einer Reihe von bewährten Methoden, die in schnell wachsenden Startups, großen Unternehmen und bei Amazon selbst entwickelt und angewendet wurden. Für die Teamgröße hat sich die Zwei-Pizza-Regel bewährt: Teams sollten nicht mehr Mitglieder haben, als von zwei großen Pizzen satt werden, also etwa 10–12 Personen. Der Grund dafür ist, dass sinnvolle Gespräche an Grenzen stoßen, wenn die Gruppengröße zunimmt und sich mehr und mehr Nebengespräche entwickeln.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
* Anwendungs-, Infrastruktur- und Toolsteams *
## Anwendungsteam
Das Anwendungsteam erstellt die Anwendung. Anwendungsentwickler sind für Backlog, Storys und Einheitentests zuständig und entwickeln Funktionen basierend auf einem bestimmten Anwendungsziel. Das organisatorische Ziel dieses Teams ist es, dass diese Entwickler möglichst wenig Zeit für nicht zum Kern gehörende Anwendungsaufgaben aufwenden müssen.
Das Anwendungsteam sollte nicht nur über funktionale Programmierkenntnisse in der Anwendungssprache, sondern auch über Plattformkenntnisse und ein Verständnis der Systemkonfiguration verfügen. Dadurch können sie sich ausschließlich auf die Entwicklung von Funktionen und das Verstärken der Anwendung konzentrieren.
## Infrastrukturteam
Das Infrastrukturteam schreibt den Code, der die für die Ausführung der Anwendung erforderliche Infrastruktur erstellt und konfiguriert. Dieses Team verwendet möglicherweise native AWS-Tools wie AWS CloudFormation oder generische Tools wie Chef, Puppet oder Ansible. Das Infrastrukturteam legt fest, welche Ressourcen benötigt werden, und arbeitet eng mit dem Anwendungsteam zusammen. Bei kleineren Anwendungen kann es ausreichen, wenn das Infrastrukturteam aus nur einer oder zwei Personen besteht.
Das Team sollte über Kenntnisse in Methoden zur Bereitstellung von Infrastrukturen wie AWS CloudFormation oder HashiCorp Terraform verfügen. Das Team sollte auch Kenntnisse in der Konfigurationsautomatisierung mit Tools wie Chef, Ansible, Puppet oder Salt entwickeln.
## Toolsteam
Das Toolsteam entwickelt und verwaltet die CI/CD-Pipeline. Seine Mitglieder sind für die Infrastruktur und die Tools verantwortlich, aus denen die Pipeline besteht. Sie sind nicht Teil des Zwei-Pizza-Teams. Sie erstellen jedoch ein Tool, das von den Anwendungs- und Infrastrukturteams in der Organisation verwendet wird. Beim Toolsteam ist die kontinuierliche Reifung besonders wichtig, damit es den reifenden Anwendungs- und Infrastrukturteams immer einen Schritt voraus ist.
Das Toolsteam muss in der Lage sein, alle Teile der CI/CD-Pipeline zu entwickeln und zu integrieren. Dazu gehören das Erstellen von Repositorys für die Quellcodeverwaltung, Workflow-Engines, Build-Umgebungen, Testframeworks und Artefakt-Repositorys. Dieses Team kann zum Beispiel Software wie AWS CodeStar, AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild und AWS CodeArtifact zusammen mit Jenkins, GitHub, Artifactory, TeamCity und ähnliche Tools implementieren. Einige Organisationen nennen dies möglicherweise ein DevOps-Team, AWS rät jedoch davon ab und schlägt stattdessen vor, DevOps als die Summe der Personen, Prozesse und Tools bei der Softwarebereitstellung zu betrachten.
# Testphasen bei Continuous Integration und Continuous Delivery
Die drei CI/CD-Teams sollten in den verschiedenen Phasen der CI/CD-Pipeline Tests in den Lebenszyklus der Softwareentwicklung integrieren. Allgemein sollte so früh wie möglich getestet werden. Die folgende Testpyramide ist ein Konzept von Mike Cohn, das er in seinem Buch *Succeeding with Agile* vorstellt. Sie zeigt die verschiedenen Softwaretests in Bezug auf ihre Kosten und Geschwindigkeit, mit der sie ausgeführt werden.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
* CI/CD-Testpyramide *
Einheitentests bilden die Basis der Pyramide. Sie sind am schnellsten auszuführen und am kostengünstigsten. Daher sollten Einheitentests den Großteil Ihrer Teststrategie ausmachen. Als Faustregel sind etwa 70 Prozent ein guter Wert. Einheitentests sollten den gesamten Code nahezu vollständig abdecken, da in dieser Phase erkannte Fehler schnell und kostengünstig behoben werden können.
Service-, Komponenten- und Integrationstests stehen in der Pyramide über den Einheitentests. Diese Tests erfordern detaillierte Umgebungen und sind daher in Bezug auf die Infrastrukturanforderungen teurer und werden langsamer ausgeführt. Leistungs- und Compliancetests sind die nächste Stufe. Sie erfordern Umgebungen in Produktionsqualität und sind noch teurer. UI- und Benutzerakzeptanztests stehen an der Spitze der Pyramide und erfordern ebenfalls Umgebungen in Produktionsqualität.
Alle diese Tests sind Teil einer vollständigen Strategie, um die hohe Qualität der Software sicherzustellen. Aus Gründen der Entwicklungsgeschwindigkeit liegt der Schwerpunkt jedoch auf der Anzahl der Tests und der Abdeckung in der unteren Hälfte der Pyramide.
In den folgenden Abschnitten werden die CI/CD-Phasen erörtert.
## Die Quelle einrichten
Zu Beginn des Projekts ist es wichtig, eine Quelle einzurichten, in der Sie Ihren Rohcode sowie Konfigurations- und Schemaänderungen speichern können. Wählen Sie in der Quellphase ein Quellcode-Repository aus, z. B. eines, das in GitHub oder AWS CodeCommit gehostet wird.
## Builds einrichten und ausführen
Die Build-Automatisierung ist für den CI-Prozess unerlässlich. Beim Einrichten der Build-Automatisierung besteht die erste Aufgabe darin, das richtige Entwicklungstool auszuwählen. Es gibt viele Entwicklungstools, zum Beispiel:
+ Ant, Maven und Gradle für Java
+ Make für C/C\$1\$1
+ Grunt für JavaScript
+ Rake für Ruby
Welches Entwicklungstool für Sie am besten geeignet ist, hängt von der Programmiersprache Ihres Projekts und den Kenntnissen Ihres Teams ab. Nachdem Sie das Entwicklungstool ausgewählt haben, müssen alle Abhängigkeiten zusammen mit den Entwicklungsschritten in den Build-Skripten klar definiert werden. Es hat sich auch bewährt, die endgültigen Build-Artefakte mit Versionsnummern zu versehen, da dies die Bereitstellung und die Nachverfolgung von Problemen erleichtert.
## Erstellung
In der Entwicklungsphase nehmen die Entwicklungstool alle Änderungen am Quellcode-Repository als Eingabe an, entwickeln die Software und führen die folgenden Arten von Tests aus:
**Einheitentest –** Testet einen bestimmten Codeabschnitt, um sicherzustellen, dass der Code sich wie erwartet verhält. Einheitentests werden während der Entwicklungsphase von Softwareentwicklern durchgeführt. In dieser Phase können eine statische Codeanalyse, Datenflussanalyse, Codeabdeckung und andere Softwareüberprüfungsprozesse angewendet werden.
**Statische Codeanalyse –** Dieser Test wird durchgeführt, ohne die Anwendung nach den Build- und Einheitentests tatsächlich auszuführen. Diese Analyse ist hilfreich, um Codierungsfehler und Sicherheitslücken zu finden und die Einhaltung der Codierungsrichtlinien sicherzustellen.
## Staging
In der Staging-Phase werden vollständige Umgebungen geschaffen, die die spätere Produktionsumgebung widerspiegeln. Die folgenden Tests werden durchgeführt:
**Integrationstest –** Überprüft die Schnittstellen zwischen Komponenten anhand des Softwareentwurfs. Integrationstests sind ein iterativer Prozess und erleichtern die Entwicklung von robusten Schnittstellen und Systemintegrität.
**Komponententest –** Testet die Nachrichtenweitergabe zwischen verschiedenen Komponenten und deren Ergebnisse. Ein Hauptziel dieses Tests könnte die Idempotenz bei Komponententests sein. Tests können extrem große Datenmengen oder ungewöhnliche Situationen und abnormale Eingaben umfassen.
**Systemtest –** Testet das System vollständig und überprüft, ob die Software die Geschäftsanforderungen erfüllt. Dies kann das Testen der Benutzeroberfläche (UI), der API, der Backend-Logik und des Endzustands umfassen.
**Leistungstest –** Ermittelt die Reaktionsfähigkeit und Stabilität eines Systems, wenn es unter einer bestimmten Workload arbeitet. Leistungstests werden auch verwendet, um andere Qualitätsmerkmale des Systems wie Skalierbarkeit, Zuverlässigkeit und Ressourcenauslastung zu untersuchen, zu messen, zu validieren oder zu verifizieren. Leistungstests können zum Beispiel Belastungstests, Stresstests und Spike-Tests sein. Leistungstests werden für das Benchmarking anhand vordefinierter Kriterien verwendet.
**Compliance-Test –** Überprüft, ob die Codeänderung den Anforderungen einer nicht funktionalen Spezifikation und/oder bestimmten Vorschriften entspricht. Damit wird ermittelt, ob Sie die gültigen Standards implementieren und erfüllen.
**Benutzerakzeptanztest –** Validiert den End-to-End-Geschäftsablauf. Dieser Test wird von einem Endbenutzer in einer Staging-Umgebung durchgeführt und prüft, ob das System die Anforderungen der Anforderungsspezifikation erfüllt. In der Regel wenden Kunden in dieser Phase Alpha- und Beta-Testmethoden an.
## Produktion
Schließlich, nachdem die vorherigen Tests bestanden wurden, wird die Staging-Phase in einer Produktionsumgebung wiederholt. In dieser Phase kann ein abschließender *Canary-Test* durchgeführt werden, indem der neue Code nur auf einer kleinen Teilmenge von Servern oder sogar nur auf einem Server oder in einer AWS-Region bereitgestellt wird, bevor Code in der gesamten Produktionsumgebung bereitgestellt wird. Einzelheiten zur sicheren Bereitstellung in der Produktion werden im Abschnitt [Bereitstellungsmethoden](deployment-methods.md) behandelt.
Im nächsten Abschnitt wird die Entwicklung der Pipeline erörtert, um diese Phasen und Tests zu integrieren.
## Pipeline entwickeln
In diesem Abschnitt wird die Entwicklung der Pipeline erörtert. Erstellen Sie zunächst eine Pipeline, die nur die für die CI benötigten Komponenten enthält, und wechseln Sie später zu einer Pipeline für die Continuous Delivery mit mehr Komponenten und Phasen. In diesem Abschnitt wird auch erläutert, wie Sie AWS Lambda-Funktionen und manuelle Genehmigungen für große Projekte verwenden sowie für mehrere Teams, Zweige und AWS-Regionen planen können.
# Start mit einer minimal funktionsfähigen Pipeline für die Continuous Integration
Der Weg Ihrer Organisation zur Continuous Delivery beginnt mit einer Pipeline, die minimal funktionsfähig ist (Minimal Viable Pipeline, (MVP). Wie unter [Continuous Integration und Continuous Delivery implementieren](implementing-continuous-integration-and-continuous-delivery.md) erläutert, können Teams mit einem sehr einfachen Prozess beginnen, z. B. mit der Implementierung einer Pipeline, die eine Überprüfung des Codestils oder einen einzelnen Einheitentest ohne Bereitstellung durchführt.
Eine wichtige Komponente dabei ist ein Orchestrierungstool für die Continuous Delivery. Zur Unterstützung beim Aufbau dieser Pipeline hat Amazon [AWS CodeStar](https://aws.amazon.com/codestar) entwickelt.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
* AWS CodeStar-Einrichtungsseite *
AWS CodeStar verwendet AWS CodePipeline, AWS CodeBuild, AWS CodeCommit und AWS CodeDeploy mit einem integrierten Einrichtungsprozess, Tools, Vorlagen und einem Dashboard. AWS CodeStar enthält die Tools, die Sie für eine schnelle Entwicklung, Erstellung und Bereitstellung von Anwendungen in AWS benötigen. Auf diese Weise können Sie den Code schneller freigeben. Kunden, die bereits mit der AWS-Managementkonsole vertraut sind und ein höheres Maß an Kontrolle wünschen, können Entwicklertools ihrer Wahl manuell konfigurieren und individuelle AWS-Services nach Bedarf bereitstellen.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
* AWS CodeStar-Dashboard *
AWS CodePipeline ist ein CI/CD-Service, der über AWS CodeStar oder über die AWS-Managementkonsole für schnelle und zuverlässige Anwendungs- und Infrastrukturaktualisierungen verwendet werden kann. Basierend auf den von Ihnen definierten Release-Prozessmodellen erstellt und testet AWS CodePipeline Ihren Code bei jeder Codeänderung und stellt ihn bereit. So können Sie Funktionen und Updates schnell und verlässlich liefern. Sie können auf einfache Weise eine End-to-End-Lösung erstellen. Nutzen Sie unsere fertigen Plug-Ins für häufig genutzte Drittanbieterservices wie GitHub oder integrieren Sie auf jeder Stufe Ihrer entsprechenden Prozesse Ihre eigenen, angepassten Plug-Ins. Mit AWS CodePipeline zahlen Sie nur für das, was Sie tatsächlich nutzen. Es fallen keine Vorausleistungen an und Sie gehen keine langfristigen Verpflichtungen ein.
Die Schritte von AWS CodeStar und AWS CodePipeline entsprechen direkt den [Quell-, Entwicklungs-, Staging- und Produktionsphasen der CI/CD](testing-stages-in-continuous-integration-and-continuous-delivery.md). Während eine Continuous Delivery wünschenswert ist, können Sie mit einer einfachen zweistufigen Pipeline beginnen, die das Quell-Repository überprüft und eine Build-Aktion ausführt:
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
* AWS CodePipeline – Quell- und Entwicklungsphasen *
Für AWS CodePipeline kann die Quellphase Eingaben von GitHub, AWS CodeCommit und Amazon Simple Storage Service (Amazon S3) akzeptieren. Die Automatisierung des Erstellungsprozesses ist ein wichtiger erster Schritt zur Implementierung der Continuous Delivery und hin zum Continuous Deployment. Wenn bei der Produktion von Build-Artefakten kein manuelles Eingreifen mehr erforderlich ist, wird Ihr Team entlastet, es passieren weniger Fehler, die durch manuelles Verpacken entstehen, und Sie können häufiger verbrauchbare Artefakte verpacken.
AWS CodePipeline arbeitet nahtlos mit AWS CodeBuild zusammen, einem vollständig verwalteten Build-Service. So ist es einfacher, einen Erstellungsschritt innerhalb Ihrer Pipeline einzurichten, der Ihren Code verpackt und Einheitentests durchführt. Mit AWS CodeBuild müssen Sie keine eigenen Buildserver bereitstellen, verwalten oder skalieren. AWS CodeBuild skaliert kontinuierlich und verarbeitet mehrere Builds gleichzeitig, sodass Ihre Builds nicht in einer Warteschlange warten müssen. AWS CodePipeline lässt sich auch in Buildserver wie Jenkins, Solano CI und TeamCity integrieren.
In der folgenden Entwicklungsphase werden beispielsweise drei Aktionen (Einheitentests, Codestilprüfungen und Erfassung von Codemetriken) parallel ausgeführt. Mit AWS CodeBuild können diese Schritte als neue Projekte ohne weiteren Aufwand beim Erstellen oder Installieren von Buildservern für die Verarbeitung der Last hinzugefügt werden.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
* AWS CodePipeline – Build-Funktionalität *
Die in der Abbildung *AWS CodePipeline – Quell- und Entwicklungsphasen* gezeigten Quell- und Entwicklungsphasen sowie ergänzende Prozesse und Automatisierung unterstützen Ihr Team beim Übergang zur Continuous Integration. Bei diesem Reifegrad müssen Entwickler regelmäßig auf die Erstellungs- und Testergebnisse achten. Sie müssen wachsen und eine stabile Grundlage für Einheitentests aufrechterhalten. Dies stärkt wiederum das Vertrauen des gesamten Teams in die CI/CD-Pipeline und fördert deren Einführung.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
* AWS CodePipeline-Phasen *
# Pipeline für Continuous Delivery
Nachdem die Pipeline für die Continuous Integration implementiert wurde und ergänzende Prozesse eingerichtet wurden, können Ihre Teams mit dem Übergang zur Pipeline für die Continuous Delivery beginnen. Bei diesem Übergang müssen Teams sowohl die Erstellung als auch die Bereitstellung von Anwendungen automatisieren.
Eine Continuous-Delivery-Pipeline ist durch das Vorhandensein von Staging- und Produktionsschritten gekennzeichnet, bei denen der Produktionsschritt nach einer manuellen Genehmigung durchgeführt wird.
Auf die gleiche Weise, wie die Continuous-Integration-Pipeline entwickelt wurde, können Ihre Teams schrittweise mit dem Aufbau einer Continuous-Delivery-Pipeline beginnen, indem sie ihre Bereitstellungsskripte schreiben.
Abhängig von den Anforderungen einer Anwendung können einige der Bereitstellungsschritte durch vorhandene AWS-Services abstrahiert werden. AWS CodePipeline kann beispielsweise direkt mit den folgenden Services integriert werden: AWS CodeDeploy, einem Service, der Code-Bereitstellungen für Amazon-EC2-Instances und On-Premises-Instances automatisiert, AWS OpsWorks, einem Konfigurationsverwaltungsdienst, der Ihnen hilft, Anwendungen mit Chef zu betreiben, und AWS Elastic Beanstalk, einem Service für die Bereitstellung und Skalierung von Webanwendungen und -services.
AWS bietet eine ausführliche [Dokumentation](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment) zur Implementierung und Integration von AWS CodeDeploy in Ihre Infrastruktur und Pipeline.
Nachdem Ihr Team die Bereitstellung der Anwendung erfolgreich automatisiert hat, können die Bereitstellungsphasen mit verschiedenen Tests erweitert werden. Sie können beispielsweise weitere sofort einsatzbereite Integrationen mit Diensten wie Ghost Inspector oder Runscope hinzufügen, wie in der folgenden Abbildung dargestellt.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
* AWS CodePipeline – Codetests in Bereitstellungsphasen *
# Lambda-Aktionen hinzufügen
AWS CodeStar und AWS CodePipeline unterstützen die [Integration mit AWS Lambda](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html). Diese Integration ermöglicht die Implementierung einer Vielzahl von Aufgaben, z. B. das Erstellen benutzerdefinierter Ressourcen in Ihrer Umgebung, die Integration in Systeme von Drittanbietern (wie Slack) und die Durchführung von Überprüfungen Ihrer neu bereitgestellten Umgebung.
Lambda-Funktionen können in CI/CD-Pipelines für die folgenden Aufgaben verwendet werden:
+ Ausführen von Änderungen an Ihrer Umgebung durch das Anwenden oder Aktualisieren einer AWS CloudFormation-Vorlage
+ Bedarfsabhängiges Erstellen von Ressourcen in einer Phase einer Pipeline mithilfe von AWS CloudFormation und Löschen der Ressourcen in einer anderen Phase
+ Bereitstellen von Anwendungsversionen ohne Ausfallzeiten in AWS Elastic Beanstalk mit einer Lambda-Funktion, die Werte des [Canonical-Name-Datensatzes](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME) austauscht
+ Bereitstellung in Amazon Elastic Container Service (ECS)-Docker-Instances
+ Sichern von Ressourcen mithilfe eines AMI-Snapshots vor dem Entwickeln oder Bereitstellen
+ Integrieren von Drittanbieterprodukten in Ihre Pipeline, wie beispielsweise das Versenden von Nachrichten an einen Internet Relay Chat (IRC)-Client
# Manuelle Genehmigungen
Fügen Sie einer Stufe in einer Pipeline eine Genehmigungsaktion hinzu, wenn Sie möchten, dass die Pipeline-Verarbeitung an einem bestimmten Punkt angehalten wird, damit jemand mit den erforderlichen AWS Identity and Access Management (IAM)-Berechtigungen die Aktion erlauben oder ablehnen kann.
Wenn die Aktion genehmigt wurde, wird die Pipeline-Verarbeitung fortgesetzt. Wenn die Aktion abgelehnt wird – oder wenn niemand die Aktion innerhalb von sieben Tagen nach Erreichen der Aktion genehmigt oder ablehnt und die Pipeline stoppt – entspricht das Ergebnis einer fehlschlagenden Aktion und die Pipeline-Verarbeitung wird nicht fortgesetzt.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
* AWS CodeDeploy – Manuelle Genehmigungen*
# Änderungen des Infrastrukturcodes in einer CI/CD-Pipeline bereitstellen
Mit AWS CodePipeline können Sie in jeder Phase Ihrer Pipeline AWS CloudFormation als Bereitstellungsaktion auswählen. Sie können dann die spezifische Aktion auswählen, die AWS CloudFormation ausführen soll, z. B. Stacks erstellen oder löschen oder [Änderungssätze](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952) erstellen und ausführen. Ein [Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929) ist ein AWS CloudFormation-Konzept und stellt eine Gruppe verwandter AWS-Ressourcen dar. Es gibt zwar viele Möglichkeiten, Infrastructure as Code bereitzustellen, AWS empfiehlt jedoch AWS CloudFormation als skalierbare, vollständige Lösung, die den umfassendsten Satz von AWS-Ressourcen als Code beschreiben kann. AWS empfiehlt außerdem, AWS CloudFormation in einem AWS CodePipeline-Projekt zur [Nachverfolgung von Infrastrukturänderungen und -tests](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html) zu verwenden.
# CI/CD für Serverless-Anwendungen
Sie können auch AWS CodeStar, AWS CodePipeline, AWS CodeBuild und AWS CloudFormation verwenden, um CI/CD-Pipelines für Serverless-Anwendungen zu entwickeln. Serverless-Anwendungen integrieren verwaltete Services wie [Amazon Cognito](https://aws.amazon.com/cognito), Amazon S3 und Amazon DynamoDB mit ereignisgesteuerten Diensten und AWS Lambda zur Bereitstellung von Anwendungen auf eine Weise, die keine Verwaltung von Servern erfordert. Wenn Sie Serverless-Anwendungen entwickeln, können Sie eine Kombination von AWS CodePipeline, AWS CodeBuild und AWS CloudFormation verwenden, um das Erstellen, Testen und Bereitstellen von Serverless-Anwendungen zu automatisieren, die in Vorlagen ausgedrückt werden, die mit dem AWS Serverless Application Model erstellt wurden. Weitere Informationen finden Sie in der AWS Lambda-Dokumentation zum [Automatisieren der Bereitstellung von Lambda-basierten Anwendungen](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html).
Mit AWS Serverless Application Model Pipelines (AWS SAM Pipelines) können Sie auch sichere CI/CD-Pipelines erstellen, die den bewährten Methoden Ihrer Organisation entsprechen. AWS SAM Pipelines ist eine neue Funktion von AWS SAM CLI, mit der Sie innerhalb von Minuten auf die Vorteile von CI/CD zugreifen können, z. B. Beschleunigung der Bereitstellungshäufigkeit, Verkürzung der Vorlaufzeit für Änderungen und Reduzierung von Bereitstellungsfehlern. AWS SAM Pipelines werden mit einer Reihe von Standard-Pipeline-Vorlagen für AWS CodeBuild/CodePipeline geliefert, die den Best Practices der AWS-Bereitstellung folgen. Weitere Informationen und eine Möglichkeit, sich das Tutorial anzusehen, finden Sie im Blog [Introducing AWS SAM Pipelines](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/).
# Pipelines für mehrere Teams, Zweige und AWS-Regionen
Bei einem großen Projekt ist es nicht ungewöhnlich, dass mehrere Projektteams an verschiedenen Komponenten arbeiten. Wenn mehrere Teams ein einziges Code-Repository verwenden, kann es so ausgelegt werden, dass jedes Team seinen eigenen Zweig hat. Es sollte auch einen Integrations- oder Release-Zweig für die endgültige Zusammenführung des Projekts geben. Wenn eine serviceorientierte oder Microservice-Architektur verwendet wird, könnte jedes Team sein eigenes Code-Repository haben.
Wird im ersten Szenario eine einzelne Pipeline verwendet, ist es möglich, dass ein Team den Fortschritt der anderen Teams aufhält, weil es die Pipeline blockiert. AWS empfiehlt, dass Sie spezifische Pipelines für Teamzweige und eine weitere Release-Pipeline für die endgültige Produktlieferung erstellen.
# Pipeline-Integration mit AWS CodeBuild
AWS CodeBuild soll es Ihrer Organisation ermöglichen, einen hochverfügbaren Erstellungsprozess mit nahezu unbegrenzter Skalierung aufzubauen. AWS CodeBuild bietet Schnellstartumgebungen für eine Reihe gängiger Sprachen sowie die Möglichkeit, jeden von Ihnen angegebenen Docker-Container auszuführen.
Dank der Vorteile einer engen Integration mit AWS CodeCommit, AWS CodePipeline und AWS CodeDeploy sowie Git- und CodePipeline Lambda-Aktionen ist das CodeBuild-Tool sehr flexibel.
Software kann durch die Einbeziehung einer `buildspec.yml`-Datei erstellt werden, die jeden der Entwicklungsschritte identifiziert, einschließlich Aktionen vor und nach dem Erstellen oder bestimmter Aktionen, die durch das CodeBuild-Tool ausgeführt werden.
Sie können den detaillierten Verlauf jedes Builds mithilfe des CodeBuild-Dashboards anzeigen. Ereignisse werden als Amazon CloudWatch Logs-Protokolldateien gespeichert.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
* CloudWatch Logs-Protokolldateien in AWS CodeBuild *
# Pipeline-Integration mit Jenkins
Sie können das Jenkins-Entwicklungstool verwenden, um [Delivery-Pipelines zu erstellen](https://www.jenkins.io/doc/book/pipeline/getting-started/). Diese Pipelines verwenden Standardaufträge, die Schritte zur Implementierung der Continuous-Delivery-Phasen definieren. Dieser Ansatz ist jedoch möglicherweise nicht optimal für größere Projekte, da der aktuelle Status der Pipeline zwischen den Neustarts von Jenkins nicht fortbesteht, die Implementierung der manuellen Genehmigung nicht einfach ist und die Nachverfolgung des Status einer komplexen Pipeline kompliziert sein kann.
Stattdessen empfiehlt AWS, dass Sie die Continuous Delivery mit Jenkins mithilfe des [AWS Code Pipeline-Plug-Ins](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin) implementieren. Dieses Plug-In ermöglicht die Beschreibung komplexer Workflows mit einer domänenspezifischen, Groovy-ähnlichen Sprache und kann zur Orchestrierung komplexer Pipelines verwendet werden. Die Funktionalität des AWS Code Pipeline-Plug-Ins kann durch die Verwendung von Satelliten-Plug-Ins erweitert werden, z. B. mit dem [Pipeline Stage View-Plug-In](https://plugins.jenkins.io/aws-codepipeline/), das den aktuellen Fortschritt der in einer Pipeline definierten Phasen visualisiert, oder dem [Pipeline Multibranch-Plug-In](https://plugins.jenkins.io/workflow-multibranch/), das Builds aus verschiedenen Zweigen gruppiert.
AWS empfiehlt, dass Sie Ihre Pipeline-Konfiguration in *Jenkinsfile* speichern und in ein Quellcode-Repository einchecken lassen. Dies ermöglicht das Nachverfolgen von Änderungen am Pipeline-Code und wird bei der Arbeit mit dem Pipeline Multibranch-Plug-In noch wichtiger. AWS empfiehlt außerdem, dass Sie Ihre Pipeline in Phasen aufteilen. Dadurch werden die Pipeline-Schritte logisch gruppiert und das Pipeline Stage View-Plug-In ermöglicht, den aktuellen Zustand der Pipeline zu visualisieren.
Die folgende Abbildung zeigt ein Beispiel für eine Jenkins-Pipeline mit vier definierten Phasen, die vom Pipeline Stage View-Plug-In visualisiert werden.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*Definierte Phasen der Jenkins-Pipeline, visualisiert durch das Pipeline Stage View-Plug-In*