# OPS 6. Wie können Sie Bereitstellungsrisiken eindämmen?
Verwenden Sie Ansätze, die schnelles Feedback zur Qualität liefern und eine schnelle Wiederherstellung bei Änderungen ermöglichen, die nicht zu den gewünschten Ergebnissen führen. Mit diesen Verfahren können Sie die Auswirkung von Problemen eindämmen, die durch die Bereitstellung von Änderungen entstehen.
**Topics**
+ [OPS06-BP01 Einkalkulieren nicht erfolgreicher Änderungen](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Testbereitstellungen](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Einsetzen sicherer Bereitstellungsstrategien](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automatisieren von Tests und Rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 Einkalkulieren nicht erfolgreicher Änderungen
Planen Sie Maßnahmen für die Rückkehr zu einem bekanntermaßen funktionierenden Zustand oder die Korrektur in der Produktionsumgebung ein, falls bei der Bereitstellung ein nicht erwünschtes Ergebnis auftritt. Eine Richtlinie zur Festlegung eines solchen Plans hilft allen Teams, Strategien zum Umgang mit fehlgeschlagenen Änderungen zu entwickeln. Einige Beispiele für Strategien sind Bereitstellungs- und Rollback-Schritte, Änderungsrichtlinien, Feature-Flags sowie die Isolierung und Verlagerung von Datenverkehr. Ein einzelner Release kann mehrere zusammengehörige Komponentenänderungen enthalten. Die Strategie sollte die Möglichkeit bieten, dem Ausfall einer Komponentenänderung standzuhalten oder sich danach zu regenerieren.
**Gewünschtes Ergebnis:** Sie haben einen detaillierten Wiederherstellungsplan für Ihre Änderung erstellt, falls diese nicht erfolgreich sein sollte. Darüber hinaus haben Sie die Größe Ihres Releases reduziert, um die potenziellen Auswirkungen auf andere Workload-Komponenten zu minimieren. Infolgedessen haben Sie die Auswirkungen auf Ihr Unternehmen verringert, indem Sie die potenziellen Ausfallzeiten aufgrund einer fehlgeschlagenen Änderung reduziert und die Flexibilität und Effizienz der Wiederherstellungszeiten erhöht haben.
**Typische Anti-Muster:**
+ Sie haben Code bereitgestellt und Ihre Anwendung ist instabil geworden, aber es befinden sich aktive Benutzer im System. Sie müssen entscheiden, ob Sie die Änderung rückgängig machen und Auswirkungen auf die aktiven Benutzer in Kauf nehmen möchten, oder ob Sie die Änderung erst später rückgängig machen möchten, wodurch möglicherweise trotzdem Auswirkungen auf die Benutzer entstehen könnten.
+ Nachdem Sie eine Routineänderung vorgenommen haben, kann auf Ihre neuen Umgebungen zugegriffen werden, aber eines Ihrer Subnetze ist nicht mehr erreichbar. Sie müssen entscheiden, ob Sie die gesamte Änderung rückgängig machen oder versuchen, die Nichtverfügbarkeit des Subnetzes zu beheben. Während Sie diese Entscheidung abwägen, bleibt das Subnetz nicht erreichbar.
+ Ihre Systeme sind nicht so konzipiert, dass sie mit kleineren Releases aktualisiert werden können. Daher haben Sie Schwierigkeiten, die Bulk-Änderungen während einer fehlgeschlagenen Bereitstellung rückgängig zu machen.
+ Sie verwenden nicht Infrastructure as Code (IaC) und Sie haben manuelle Aktualisierungen an Ihrer Infrastruktur vorgenommen, die zu einer unerwünschten Konfiguration geführt haben. Sie sind nicht in der Lage, die manuellen Änderungen effektiv zu verfolgen und rückgängig zu machen.
+ Da Sie die erhöhte Häufigkeit Ihrer Bereitstellungen nicht gemessen haben, hat Ihr Team keinen Anreiz, den Umfang seiner Änderungen zu reduzieren und seine Rollback-Pläne für jede Änderung zu verbessern. Dies führt zu höheren Risiken und höheren Ausfallraten.
+ Sie messen nicht die Gesamtdauer eines Ausfalls, der durch erfolglose Änderungen verursacht wird. Ihr Team ist nicht in der Lage, den Bereitstellungsprozess und die Effektivität des Wiederherstellungsplans zu priorisieren und zu verbessern.
**Vorteile der Nutzung dieser bewährten Methode:** Ein Plan zur Wiederherstellung nach erfolglosen Änderungen minimiert die mittlere Wiederherstellungszeit (MTTR) und reduziert die Auswirkungen auf Ihr Unternehmen.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Mithilfe einer konsistenten, dokumentierten Richtlinie und Praxis, die von den Release-Teams angewendet wird, kann ein Unternehmen planen, was bei nicht erfolgreichen Änderungen passieren soll. Unter bestimmten Umständen sollte die Richtlinie ein Forward-Fixing berücksichtigen. In allen Fällen sollte ein Fix-Forward- oder Rollback-Plan vor der Bereitstellung in der Live-Produktion gut dokumentiert und getestet werden, um die benötigte Zeit zum Rückgängigmachen einer Änderung zu minimieren.
### Implementierungsschritte
1. Dokumentieren Sie die Richtlinien, nach denen Teams über wirksame Pläne verfügen müssen, wie Änderungen innerhalb eines bestimmten Zeitraums rückgängig gemacht werden können.
1. In den Richtlinien sollte festgelegt sein, wann eine Fix-Forward-Situation zulässig ist.
1. Fordern Sie einen dokumentierten Rollback-Plan, auf den alle Beteiligten zugreifen können.
1. Geben Sie die Anforderungen für das Rollback an (z. B. wenn festgestellt wird, dass nicht autorisierte Änderungen vorgenommen wurden).
1. Analysieren Sie den Grad der Auswirkungen aller Änderungen für jede Komponente eines Workloads.
1. Ermöglichen Sie die Standardisierung, Vorlagenerstellung und Vorautorisierung wiederholbarer Änderungen, sofern sie einem konsistenten Workflow folgen, der Änderungsrichtlinien durchsetzt.
1. Reduzieren Sie die potenziellen Auswirkungen jeder Änderung, indem Sie den Umfang der Änderung verringern, damit die Wiederherstellung weniger Zeit in Anspruch nimmt und weniger Auswirkungen auf das Unternehmen hat.
1. Stellen Sie sicher, dass die Rollback-Verfahren den Code in einen bekannt funktionierenden Zustand zurückversetzen, um Zwischenfälle nach Möglichkeit zu vermeiden.
1. Integrieren Sie Tools und Workflows, um Ihre Richtlinien programmgesteuert durchzusetzen.
1. Machen Sie Daten zu Änderungen für andere Workload-Besitzer sichtbar, um die Diagnose bei fehlgeschlagenen Änderungen, für die kein Rollback möglich ist, zu beschleunigen.
1. Messen Sie den Erfolg dieser Methode anhand sichtbarer Änderungsdaten und identifizieren Sie iterative Verbesserungen.
1. Verwenden Sie Überwachungstools, um den Erfolg oder Misserfolg einer Bereitstellung zu überprüfen und so die Entscheidungsfindung beim Rollback zu beschleunigen.
1. Messen Sie die Dauer des Ausfalls bei einer erfolglosen Änderung, um Ihre Wiederherstellungspläne kontinuierlich zu verbessern.
**Aufwand für den Implementierungsplan:** Mittel
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS06-BP04 Automatisieren von Tests und Rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Zugehörige Dokumente:**
+ [AWS Builders' Library \$1 Gewährleistung der Rollback-Sicherheit bei Bereitstellungen ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS Whitepaper \$1 Änderungsmanagement in der Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Zugehörige Videos:**
+ [ re:Invent 2019 \$1 Amazon’s approach to high-availability deployment (re:Invent 2019 \$1 Der Amazon-Ansatz für die Hochverfügbarkeitsbereitstellung) ](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 Testbereitstellungen
Testen Sie Release-Verfahren in der Vorproduktion, indem Sie dieselbe Bereitstellungskonfiguration, dieselben Sicherheitskontrollen, Schritte und Verfahren wie in der Produktion verwenden. Stellen Sie sicher, dass alle bereitgestellten Schritte wie erwartet abgeschlossen wurden, z. B. das Überprüfen von Dateien, Konfigurationen und Services. Testen Sie alle Änderungen darüber hinaus mit Funktions-, Integrations- und Auslastungstests sowie Überwachungsverfahren, z. B. Zustandsprüfungen. Durch diese Tests können Sie Bereitstellungsprobleme frühzeitig erkennen und haben die Möglichkeit, sie vor der Produktion einzuplanen und zu beheben.
Sie können temporäre parallele Umgebungen erstellen, um jede Änderung zu testen. Automatisieren Sie die Bereitstellung der Testumgebungen mithilfe von Infrastructure as Code (IaC), um den Arbeitsaufwand zu reduzieren und Stabilität, Konsistenz und schnellere Funktionsbereitstellung zu gewährleisten.
**Gewünschtes Ergebnis:** Ihr Unternehmen führt eine testgestützte Entwicklungskultur ein, die Testbereitstellungen einschließt. Dadurch wird sichergestellt, dass sich die Teams darauf konzentrieren, Werte für das Unternehmen zu schaffen, anstatt Releases zu verwalten. Die Teams werden bei der Identifizierung von Bereitstellungsrisiken frühzeitig einbezogen, um die geeigneten Maßnahmen zur Risikominderung festzulegen.
**Typische Anti-Muster:**
+ Während Produktionseinführungen führen ungetestete Bereitstellungen häufig zu Problemen, die eine Fehlerbehebung und Eskalation erfordern.
+ Ihr Release enthält Infrastructure as Code (IaC), wodurch vorhandene Ressourcen aktualisiert werden. Sie sind sich nicht sicher, ob IaC erfolgreich ausgeführt wird oder ob es Auswirkungen auf die Ressourcen gibt.
+ Sie stellen eine neue Funktion für Ihre Anwendung bereit. Sie funktioniert nicht wie beabsichtigt und dies fällt erst auf, wenn sie von betroffenen Benutzern gemeldet wird.
+ Sie aktualisieren Ihre Zertifikate. Sie installieren versehentlich die Zertifikate für die falschen Komponenten, was unentdeckt bleibt und Auswirkungen auf Website-Benutzer hat, da keine sichere Verbindung zur Website hergestellt werden kann.
**Vorteile der Nutzung dieser bewährten Methode:** Durch umfangreiche Tests der Bereitstellungsverfahren und der durch sie eingeführten Änderungen in der Vorproduktion werden die potenziellen Auswirkungen der Bereitstellungsschritte auf die Produktion minimiert. Dies erhöht das Vertrauen bei der Produktionseinführung und minimiert den Support während des Betriebs, ohne die bereitgestellten Änderungen zu verlangsamen.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Das Testen Ihres Bereitstellungsprozesses ist genauso wichtig wie das Testen der Änderungen, die sich aus der Bereitstellung ergeben. Dies kann erreicht werden, indem Sie Ihre Bereitstellungsschritte in einer Vorproduktionsumgebung testen, die die Produktion so genau wie möglich widerspiegelt. Häufig auftretende Probleme, z. B. unvollständige oder falsche Bereitstellungsschritte oder Fehlkonfigurationen, können so vor der Bereitstellung in der Produktionsumgebung erkannt werden. Darüber hinaus können Sie Ihre Wiederherstellungsschritte testen.
**Kundenbeispiel**
Im Rahmen seiner CI/CD-Pipeline (Continuous Integration and Continuous Delivery) führt AnyCompany Retail die definierten Schritte durch, die zur Veröffentlichung von Infrastruktur- und Softwareupdates für seine Kunden in einer produktionsähnlichen Umgebung erforderlich sind. Die Pipeline besteht aus Vorabprüfungen zur Erkennung von Abweichungen (Erkennung von Änderungen an Ressourcen, die außerhalb von IaC vorgenommen wurden) bei Ressourcen vor der Bereitstellung sowie zur Validierung der Aktionen, die von IaC bei der Initiierung ausgeführt werden. Vor der erneuten Registrierung beim Load Balancer werden Bereitstellungsschritte validiert und z. B. sichergestellt, dass bestimmte Dateien und Konfigurationen vorhanden sind und Services ausgeführt werden und korrekt auf Zustandsprüfungen auf dem lokalen Host reagieren. Darüber hinaus führen alle Änderungen zu einer Reihe automatisierter Tests wie Funktions-, Sicherheits-, Regressions-, Integrations- und Auslastungstests.
### Implementierungsschritte
1. Führen Sie Prüfungen vor der Installation durch, um die Vorproduktionsumgebung in der Produktionsumgebung zu spiegeln.
1. Mit der [Abweichungserkennung](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) können Sie erkennen, wann Ressourcen außerhalb von CloudFormation geändert wurden.
1. Verwenden Sie [Änderungssätze,](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) um zu überprüfen, ob die Absicht einer Stack-Aktualisierung mit den Aktionen übereinstimmt, die von CloudFormation bei der Initiierung des Änderungssatzes ausgeführt werden.
1. Dadurch wird ein manueller Genehmigungsschritt in [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) ausgelöst, um die Bereitstellung in der Vorproduktionsumgebung zu autorisieren.
1. Verwenden Sie Bereitstellungskonfigurationen wie [AWS CodeDeploy-AppSpec-](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) Dateien zur Definition der Bereitstellungs- und Validierungsschritte.
1. Wo zutreffend, [integrieren Sie AWS CodeDeploy in andere AWS-Services](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) oder [integrieren Sie AWS CodeDeploy in Produkte und Services von Partnern](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. [Überwachen Sie Bereitstellungen](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) mithilfe von Ereignisbenachrichtigungen von Amazon CloudWatch, AWS CloudTrail und Amazon SNS.
1. Führen Sie nach der Bereitstellung automatisierte Tests durch, einschließlich Funktions-, Sicherheits-, Regressions-, Integrations- und Auslastungstests.
1. [Behandlung von](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) Problemen bei der Bereitstellung.
1. Eine erfolgreiche Validierung der zuvor genannten Schritte sollte einen manuellen Genehmigungsworkflow initiieren, um die Bereitstellung in der Produktion zu autorisieren.
**Aufwand für den Implementierungsplan:** Hoch
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS05-BP02 Testen und Validieren von Änderungen](ops_dev_integ_test_val_chg.md)
**Zugehörige Dokumente:**
+ [AWS Builders' Library \$1 Automatisierung sicherer, vollautomatischer Bereitstellungen \$1 Testbereitstellungen ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS-Whitepaper \$1 Durchführung von dauerhafter Integration/dauerhafter Bereitstellung in AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ The Story of Apollo – Amazon's Deployment Engine (Apollo – die Bereitstellungs-Engine von Amazon) ](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [Vorgehensweise für den lokalen Test und lokales Debugging von AWS CodeDeploy vor der Auslieferung Ihres Codes](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [ Integrating Network Connectivity Testing with Infrastructure Deployment (Integration von Netzwerkkonnektivitätstests in die Bereitstellung der Infrastruktur) ](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**Zugehörige Videos:**
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon (re:Invent 2020 \$1 Testen von Software und Systemen bei Amazon) ](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**Zugehörige Beispiele:**
+ [ Tutorial \$1 Bereitstellen eines Amazon ECS-Services mit einem Validierungstest ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 Einsetzen sicherer Bereitstellungsstrategien
Sichere Produktionseinführungen steuern den Fluss vorteilhafter Änderungen mit dem Ziel, die von den Kunden wahrgenommenen Auswirkungen dieser Änderungen zu minimieren. Die Sicherheitskontrollen bieten Prüfmechanismen, um die gewünschten Ergebnisse zu validieren und den Umfang der Auswirkungen von Fehlern zu begrenzen, die durch die Änderungen oder durch Fehler bei der Bereitstellung verursacht werden. Zu sicheren Rollouts können Strategien wie Feature-Flags, One-Box, Rolling (Canary-Releases), Immutable, Aufteilung des Datenverkehrs und Blau/Grün-Bereitstellungen gehören.
**Gewünschtes Ergebnis:** Ihr Unternehmen verwendet ein CI/CD-System (Continuous integration and continuous delivery, kontinuierliche Integration und kontinuierliche Bereitstellung), das Funktionen zur Automatisierung sicherer Rollouts bietet. Die Teams müssen angemessene sichere Rollout-Strategien anwenden.
**Typische Anti-Muster:**
+ Sie stellen eine nicht erfolgreiche Änderung für die gesamte Produktion gleichzeitig bereit. Infolgedessen sind alle Kunden gleichzeitig betroffen.
+ Ein Fehler, der bei einer gleichzeitigen Bereitstellung in allen Systemen auftritt, erfordert ein Notfall-Release. Die Korrektur für alle Kunden dauert mehrere Tage.
+ Die Verwaltung der Produktionseinführung erfordert die Planung und Beteiligung mehrerer Teams. Dies schränkt Ihre Fähigkeit ein, Funktionen für Ihre Kunden häufig zu aktualisieren.
+ Sie führen eine veränderbare Bereitstellung durch, indem Sie Ihre vorhandenen Systeme ändern. Nachdem Sie festgestellt haben, dass die Änderung nicht erfolgreich war, müssen Sie die Systeme erneut ändern, um die alte Version wiederherzustellen, was die Wiederherstellungsdauer verlängert.
**Vorteile der Nutzung dieser bewährten Methode:** Automatisierte Bereitstellungen sorgen für ein ausgewogenes Verhältnis zwischen der Geschwindigkeit der Bereitstellungen und der konsistenten Bereitstellung nützlicher Änderungen für die Kunden. Die Begrenzung der Auswirkungen verhindert kostspielige Bereitstellungsfehler und maximiert die Fähigkeit der Teams, effizient auf Ausfälle zu reagieren.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel
## Implementierungsleitfaden
Ausfälle bei der kontinuierlichen Bereitstellung können zu einer verringerten Serviceverfügbarkeit und schlechten Kundenerfahrungen führen. Um die Anzahl erfolgreicher Implementierungen zu maximieren, sollten Sie im gesamten Release-Prozess Sicherheitskontrollen zur Minimierung von Bereitstellungsfehlern implementieren. Das Ziel sollte dabei sein, dass keine Bereitstellungsfehler auftreten.
**Kundenbeispiel**
AnyCompany Retail möchte Bereitstellungen mit minimalen bis gar keinen Ausfallzeiten erreichen, d. h. es soll während der Bereitstellung keine spürbaren Auswirkungen für die Benutzer geben. Um dies zu erreichen, hat das Unternehmen Bereitstellungsmuster festgelegt, z. B. fortlaufende und Blau/Grün-Bereitstellung (siehe nachfolgendes Workflow-Diagramm). Alle Teams übernehmen eines oder mehrere dieser Muster in ihre CI/CD-Pipeline.
| CodeDeploy-Workflow für Amazon EC2 | CodeDeploy-Workflow für Amazon ECS | CodeDeploy-Workflow für Lambda |
| --- | --- | --- |
| ![\[Ablauf des Bereitstellungsprozesses für Amazon EC2\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/deployment-process-ec2.png) | ![\[Ablauf des Bereitstellungsprozesses für Amazon ECS\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/deployment-process-ecs.png) | ![\[Ablauf des Bereitstellungsprozesses für Lambda\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/deployment-process-lambda.png) |
### Implementierungsschritte
1. Verwenden Sie einen Genehmigungsworkflow, um die Reihenfolge der Produktionseinführungsschritte nach der Beförderung zur Produktion einzuleiten.
1. Verwenden Sie ein automatisiertes Bereitstellungssystem wie [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). AWS CodeDeploy- [Bereitstellungsoptionen](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) schließen lokale Bereitstellungen für EC2/On-Premises und Blau/Grün-Bereitstellungen für EC2/On-Premises ein, AWS Lambda und Amazon ECS (siehe vorhergehendes Workflow-Diagramm).
1. Wo zutreffend, [integrieren Sie AWS CodeDeploy in andere AWS-Services](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) oder [integrieren Sie AWS CodeDeploy in Produkte und Services von Partnern](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. Verwenden Sie Blau/Grün-Bereitstellungen für Datenbanken wie [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) und [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html).
1. [Überwachen Sie Bereitstellungen](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) mithilfe von Ereignisbenachrichtigungen von Amazon CloudWatch, AWS CloudTrail und Amazon SNS.
1. Führen Sie nach der Bereitstellung automatisierte Tests durch, einschließlich Funktions-, Sicherheits-, Regressions-, Integrations- und Auslastungstests.
1. [Behandlung von](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) Problemen bei der Bereitstellung.
**Aufwand für den Implementierungsplan:** Mittel
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS05-BP02 Testen und Validieren von Änderungen](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 Häufige, kleine, reversible Änderungen vornehmen](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Vollständige Automatisierung von Integration und Bereitstellung](ops_dev_integ_auto_integ_deploy.md)
**Zugehörige Dokumente:**
+ [AWS Builders' Library \$1 Automatisierung sicherer, vollautomatischer Bereitstellungen \$1 Produktionsbereitstellungen ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders' Library \$1 Meine CI/CD-Pipeline ist mein Release Captain \$1 Sichere, automatische Produktionseinführungen](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS-Whitepaper \$1 Durchführung von dauerhafter Integration/dauerhafter Bereitstellung in AWS \$1 Bereitstellungsmethoden](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy-Benutzerhandbuch](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Arbeiten mit Bereitstellungskonfigurationen in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Einrichten einer API Gateway-Canary-Bereitstellung als Release ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS-Bereitstellungstypen](https://docs.aws.amazon.com/)
+ [Vollständig verwaltete Blau/Grün-Bereitstellungen in Amazon Aurora und Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Blau/Grün-Bereitstellungen mit AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**Zugehörige Videos:**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon (re:Invent 2020 \$1 Vollständige Automatisierung: Automatisieren der Pipelines für kontinuierliche Bereitstellung bei Amazon)](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon’s approach to high-availability deployment (re:Invent 2019 \$1 Der Amazon-Ansatz für die Hochverfügbarkeitsbereitstellung)](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**Zugehörige Beispiele:**
+ [Testen einer Blau/Grün-Bereitstellung in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Workshop \$1 Erstellen von CI/CD-Pipelines für Lambda-Canary-Bereitstellungen mit AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Workshop \$1 Blue/Green and Canary Deployment for EKS and ECS (Workshop \$1 Blau/Grün- und Canary-Bereitstellungen für EKS und ECS)](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Workshop \$1 Building a Cross-account CI/CD Pipeline (Erstellen einer kontenübergreifenden CI/CD-Pipeline)](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)
# OPS06-BP04 Automatisieren von Tests und Rollback
Um die Geschwindigkeit, Zuverlässigkeit und Sicherheit Ihres Bereitstellungsprozesses zu erhöhen, sollten Sie eine Strategie für automatisierte Test- und Rollback-Funktionen in Vorproduktions- und Produktionsumgebungen entwickeln. Automatisieren Sie Tests bei der Bereitstellung in der Produktion, um Interaktionen zwischen Mensch und System zu simulieren und die bereitgestellten Änderungen zu überprüfen. Automatisieren Sie das Rollback, um schnell zu einem als funktionierend bekannten Zustand zurückkehren zu können. Das Rollback sollte unter vordefinierten Bedingungen automatisch eingeleitet werden, z. B. wenn das gewünschte Ergebnis einer Änderung nicht erreicht wird oder wenn der automatisierte Test fehlschlägt. Die Automatisierung dieser beiden Aktivitäten verbessert Ihre Erfolgsquote bei Bereitstellungen, minimiert die Wiederherstellungszeit und reduziert die potenziellen Auswirkungen auf das Unternehmen.
**Gewünschtes Ergebnis:** Ihre automatisierten Tests und Rollback-Strategien sind in Ihre CI/CD-Pipeline (Continuous Integration and Continuous Delivery, kontinuierliche Integration und kontinuierliche Bereitstellung) integriert. Ihre Überwachung kann Validierungen anhand Ihrer Erfolgskriterien ausführen und bei einem Fehler ein automatisches Rollback einleiten. Dadurch werden die Auswirkungen auf Endbenutzer und Kunden minimiert. Wenn beispielsweise alle Testergebnisse den Anforderungen entsprechen, übertragen Sie Ihren Code in die Produktionsumgebung, wo automatisierte Regressionstests unter Verwendung derselben Testfälle eingeleitet werden. Wenn die Ergebnisse der Regressionstests nicht den Erwartungen entsprechen, wird im Pipeline-Workflow ein automatisiertes Rollback eingeleitet.
**Typische Anti-Muster:**
+ Ihre Systeme sind nicht so konzipiert, dass sie mit kleineren Releases aktualisiert werden können. Daher haben Sie Schwierigkeiten, die Bulk-Änderungen während einer fehlgeschlagenen Bereitstellung rückgängig zu machen.
+ Ihr Bereitstellungsprozess besteht aus einer Reihe manueller Schritte. Nachdem Sie Änderungen an Ihrem Workload bereitgestellt haben, beginnen Sie mit den Tests nach der Bereitstellung. Danach bemerken Sie, dass Ihr Workload nicht mehr funktioniert und die Verbindung der Kunden getrennt wird. Sie starten das Rollback zur vorherigen Version. All diese manuellen Schritte verzögern die allgemeine Systemwiederherstellung und wirken sich nachhaltig auf Ihre Kunden aus.
+ Sie haben Zeit dafür aufgewendet, automatisierte Testfälle für Funktionen zu entwickeln, die in Ihrer Anwendung nicht häufig verwendet werden. Dadurch amortisiert sich die Investition in Ihre automatisierten Testfunktionen nur schlecht.
+ Ihre Version besteht aus Anwendungs-, Infrastruktur-, Patch- und Konfigurations-Updates, die voneinander unabhängig sind. Sie haben jedoch nur eine CI/CD-Pipeline, die alle Änderungen gleichzeitig bereitstellt. Ein Fehler in einer Komponente zwingt Sie, alle Änderungen rückgängig zu machen, wodurch Ihr Rollback komplex und ineffizient wird.
+ Ihr Team schließt die Programmierarbeiten im ersten Sprint ab und beginnt mit dem zweiten Sprint, aber Ihr Plan sieht Tests erst im dritten Sprint vor. Deshalb haben automatisierte Tests Fehler aus dem ersten Sprint aufgedeckt, die behoben werden müssen, bevor mit dem Testen der Ergebnisse von Sprint zwei begonnen werden kann. Der gesamte Release verzögert sich, wodurch der Wert Ihrer automatisierten Tests erheblich verringert wird.
+ Ihre automatisierten Regressionstestfälle für die Produktionsversion sind abgeschlossen, aber Sie überwachen den Zustand der Workloads nicht. Da Sie nicht sehen können, ob der Dienst neu gestartet wurde oder nicht, sind Sie sich nicht sicher, ob ein Rollback erforderlich ist oder bereits stattgefunden hat.
**Vorteile der Nutzung dieser bewährten Methode:** Automatisierte Tests erhöhen die Transparenz Ihres Testprozesses und Ihre Fähigkeit, mehr Funktionen in kürzerer Zeit abzudecken. Durch das Testen und Validieren von Änderungen in der Produktionsphase können Sie Probleme sofort identifizieren. Die Verbesserung der Konsistenz mit automatisierten Testtools ermöglicht eine bessere Fehlererkennung. Durch das automatische Rollback zur vorherigen Version werden die Auswirkungen für Ihre Kunden minimiert. Ein automatisiertes Rollback sorgt letztendlich für mehr Vertrauen in Ihre Bereitstellungsfunktionen, da es die Auswirkungen auf Ihr Unternehmen verringert. Insgesamt verkürzen diese Funktionen die Zeit bis zur Lieferung und stellen gleichzeitig die Qualität sicher.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel
## Implementierungsleitfaden
Automatisieren Sie die Tests von bereitgestellten Umgebungen, um schneller die gewünschten Ergebnisse zu erreichen. Automatisieren Sie den Rollback zu einem bekanntermaßen funktionierenden vorherigen Zustand, wenn die zuvor definierten Ergebnisse nicht erzielt werden. So können Sie die Wiederherstellungszeit minimieren und verringern Fehler, die durch manuelle Prozesse entstehen. Integrieren Sie Testtools in Ihren Pipeline-Workflow, um manuelle Eingaben konsistent zu testen und zu minimieren. Priorisieren Sie die Automatisierung von Testfällen, z. B. Tests, die die größten Risiken minimieren und die bei jeder Änderung häufig durchgeführt werden müssen. Automatisieren Sie außerdem das Rollback auf Grundlage bestimmter Bedingungen, die in Ihrem Testplan vordefiniert sind.
### Implementierungsschritte
1. Richten Sie einen Testlebenszyklus für Ihren Entwicklungslebenszyklus ein, in dem jede Phase des Testprozesses definiert wird. Dies reicht von der Anforderungsplanung über die Testfallentwicklung, die Toolkonfiguration, das automatisierte Testen bis hin zum Abschluss des Testfalls.
1. Erstellen Sie anhand Ihrer gesamten Teststrategie einen Workload-spezifischen Testansatz.
1. Ziehen Sie eine Strategie für kontinuierliche Tests während des gesamten Entwicklungszyklus in Erwägung.
1. Wählen Sie in Abhängigkeit von Ihren Geschäftsanforderungen und Pipeline-Investitionen automatisierte Tools für Tests und Rollbacks aus.
1. Entscheiden Sie, welche Testfälle Sie automatisieren möchten und welche manuell durchgeführt werden sollen. Dies kann auf Grundlage des geschäftlichen Nutzens der getesteten Funktion definiert werden. Informieren Sie alle Teammitglieder über diesen Plan und legen Sie fest, wer für die Durchführung manueller Tests verantwortlich ist.
1. Wenden Sie automatisierte Testfunktionen auf bestimmte Testfälle an, die für die Automatisierung sinnvoll sind, z. B. wiederholbare oder häufig ausgeführte Fälle, Fälle, die sich wiederholende Aufgaben erfordern, oder solche, die für mehrere Konfigurationen erforderlich sind.
1. Definieren Sie Skripts für die Testautomatisierung sowie die Erfolgskriterien im Automatisierungstool, sodass eine kontinuierliche Workflow-Automatisierung initiiert werden kann, wenn bei bestimmten Fällen Fehler auftreten.
1. Definieren Sie spezifische Fehlerkriterien für das automatisierte Rollback.
1. Priorisieren Sie die Testautomatisierung, um konsistente Ergebnisse mit einer gründlichen Testfallentwicklung zu erzielen, bei der Komplexität und menschliche Interaktion ein höheres Ausfallrisiko darstellen.
1. Integrieren Sie Ihre automatisierten Test- und Rollback-Tools in Ihre CI/CD-Pipeline.
1. Entwickeln Sie klare Erfolgskriterien für Ihre Änderungen.
1. Überwachen und beobachten Sie Ihre Umgebung, um diese Kriterien zu erkennen und Änderungen automatisch rückgängig zu machen, wenn bestimmte Rollback-Kriterien erfüllt werden.
1. Führen Sie verschiedene Arten automatisierter Produktionstests durch, z. B.:
1. A/B-Tests zur Anzeige von Ergebnissen im Vergleich zur aktuellen Version zwischen zwei Benutzertestgruppen.
1. Canary-Tests, mit denen Sie Ihre Änderung für eine Untergruppe von Benutzern bereitstellen können, bevor Sie sie für alle freigeben.
1. Testen mit Feature-Flags, wobei jeweils eine einzelne Funktion der neuen Version außerhalb der Anwendung ein- und ausgeschaltet werden kann, sodass alle neuen Funktionen einzeln validiert werden können.
1. Regressionstests zur Überprüfung neuer Funktionen mit bestehenden, miteinander verbundenen Komponenten.
1. Überwachen Sie die betrieblichen Aspekte der Anwendung, Transaktionen und Interaktionen mit anderen Anwendungen und Komponenten. Entwickeln Sie Berichte, um den Erfolg von Änderungen nach Workload aufzuzeigen, sodass Sie erkennen können, welche Teile der Automatisierung und des Workflows weiter optimiert werden können.
1. Entwickeln Sie Testergebnisberichte, anhand derer Sie schnell entscheiden können, ob Rollback-Verfahren eingeleitet werden sollten oder nicht.
1. Implementieren Sie eine Strategie, die ein automatisiertes Rollback auf Grundlage vordefinierter Fehlerbedingungen ermöglicht, die sich aus einer oder mehreren Ihrer Testmethoden ergeben.
1. Entwickeln Sie Ihre automatisierten Testfälle so, dass sie bei zukünftigen wiederholbaren Änderungen wiederverwendet werden können.
**Aufwand für den Implementierungsplan:** Mittel
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS06-BP01 Einkalkulieren nicht erfolgreicher Änderungen](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Testbereitstellungen](ops_mit_deploy_risks_test_val_chg.md)
**Zugehörige Dokumente:**
+ [AWS Builders' Library \$1 Gewährleistung der Rollback-Sicherheit bei Bereitstellungen ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Erneutes Bereitstellen und Zurücksetzen einer Bereitstellung mit AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 8 bewährte Methoden beim Automatisieren von Bereitstellungen mit AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**Zugehörige Beispiele:**
+ [ Serverless-Tests für UI mit Selenium, AWS Lambda, AWS Fargate und AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**Zugehörige Videos:**
+ [ re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon (re:Invent 2020 \$1 Vollständige Automatisierung: Automatisieren der Pipelines für kontinuierliche Bereitstellung bei Amazon) ](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [ re:Invent 2019 \$1 Amazon’s approach to high-availability deployment (re:Invent 2019 \$1 Der Amazon-Ansatz für die Hochverfügbarkeitsbereitstellung) ](https://www.youtube.com/watch?v=bCgD2bX1LI4)