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.
# Was ist AWS CodePipeline?
AWS CodePipeline ist ein Continuous-Delivery-Service, mit dem Sie die zur Veröffentlichung Ihrer Software erforderlichen Schritte modellieren, visualisieren und automatisieren können. Sie können die verschiedenen Phasen eines Softwareveröffentlichungsprozesses schnell modellieren und konfigurieren. CodePipeline automatisiert die Schritte, die erforderlich sind, um Ihre Softwareänderungen kontinuierlich zu veröffentlichen. Informationen zur Preisgestaltung für finden Sie CodePipeline unter [Preisgestaltung](https://aws.amazon.com/codepipeline/pricing/).
**Topics**
+ [Kontinuierliche Bereitstellung und kontinuierliche Integration](concepts-continuous-delivery-integration.md)
+ [Was kann ich damit CodePipeline machen?](welcome-what-can-I-do.md)
+ [Ein kurzer Blick auf CodePipeline](welcome-introducing.md)
+ [Wie fange ich an mit CodePipeline?](welcome-get-started.md)
+ [CodePipeline Konzepte](concepts.md)
+ [DevOps Beispiel für eine Pipeline](concepts-devops-example.md)
+ [So funktionieren Pipeline-Ausführungen](concepts-how-it-works.md)
+ [Eingabe- und Ausgabe-Artefakte](welcome-introducing-artifacts.md)
+ [Wie funktionieren die Stufenbedingungen?](concepts-how-it-works-conditions.md)
+ [Arten von Pipelines](pipeline-types.md)
+ [Welcher Pipeline-Typ ist der richtige für mich?](pipeline-types-planning.md)
# Kontinuierliche Bereitstellung und kontinuierliche Integration
CodePipeline ist ein Service mit *kontinuierlicher Bereitstellung*, der die Entwicklung, das Testen und die Bereitstellung Ihrer Software in der Produktion automatisiert.
[Kontinuierliche Bereitstellung](https://aws.amazon.com/devops/continuous-delivery/) ist eine Methode für die Bereitstellung von Software, bei der der Veröffentlichungsprozess automatisiert ist. Jede Änderung der Software wird automatisch entwickelt, getestet und für die Produktion bereitgestellt. Vor der endgültigen Bereitstellung für die Produktion wird von einer Person, einem automatisierten Test oder einer Geschäftsregel entschieden, wann die endgültige Bereitstellung erfolgen soll. Auch wenn bei einer kontinuierlichen Bereitstellung jede erfolgreiche Software-Änderung sofort für die Produktion bereitgestellt werden kann, müssen nicht alle Änderungen sofort bereitgestellt werden.
[Kontinuierliche Integration](https://aws.amazon.com/devops/continuous-integration/) ist eine Softwareentwicklungspraxis, bei der Mitglieder eines Teams ein Versionskontrollsystem verwenden und ihre Arbeit häufig am selben Ort, z. B. in einer Hauptniederlassung, integrieren. Jede Änderung wird erstellt und überprüft, um Integrationsfehler so schnell wie möglich zu entdecken. Die kontinuierliche Integration konzentriert sich auf die automatische Erstellung und dem automatischen Testen von Code, während bei der *kontinuierlichen Bereitstellung* der gesamte Prozess für die Software-Veröffentlichung bis zur Produktionseinführung automatisiert wird.
Weitere Informationen finden Sie unter [Practicing Continuous Integration and Continuous Delivery unter AWS: Beschleunigte Softwarebereitstellung mit DevOps](https://d0.awsstatic.com/whitepapers/DevOps/practicing-continuous-integration-continuous-delivery-on-AWS.pdf).
Sie können die CodePipeline Konsole, die AWS Command Line Interface (AWS CLI), die oder eine beliebige Kombination davon verwenden AWS SDKs, um Ihre Pipelines zu erstellen und zu verwalten.
# Was kann ich damit CodePipeline machen?
Sie können CodePipeline es verwenden, um Ihre Anwendungen automatisch in der Cloud zu erstellen, zu testen und bereitzustellen. Insbesondere können Sie Folgendes:
+ **Automatisieren Sie Ihre Release-Prozesse**: Automatisiert Ihren Release-Prozess CodePipeline vollständig von Anfang bis Ende, angefangen von Ihrem Quell-Repository über Build, Test und Bereitstellung. Sie können die Verarbeitung von Änderungen in der Pipeline verhindern, indem Sie eine manuelle Genehmigungsaktion einfügen. Dies ist für alle Phasen außer der Quellphase möglich. Sie können Software-Änderungen zum gewünschten Zeitpunkt auf die gewünschte Weise auf den Systemen Ihrer Wahl und auf einer einzigen oder mehreren Instances veröffentlichen.
+ **Richten Sie einen konsistenten Release-Prozess** ein: Definieren Sie für jede Codeänderung eine konsistente Reihe von Schritten. CodePipeline führt jede Phase Ihres Releases nach Ihren Kriterien aus.
+ **Sie können die Bereitstellung beschleunigen und gleichzeitig die Qualität verbessern**: Sie können Ihren Veröffentlichungsprozess automatisieren, um Ihren Developern zu gestatten, Code inkrementell zu testen und zu veröffentlichen und die Veröffentlichung neuer Funktionen für Ihre Kunden zu beschleunigen.
+ **Sie können Ihre bevorzugten Tools verwenden**: Sie können vorhandene Quellen, Builds und Bereitstellungs-Tools in Ihre Pipeline integrieren. Eine vollständige Liste der Tools AWS-Services und Tools von Drittanbietern, die derzeit von unterstützt werden CodePipeline, finden Sie unter[Produkt- und Serviceintegrationen mit CodePipeline](integrations.md).
+ **Den Fortschritt auf einen Blick** anzeigen: Sie können den Status Ihrer Pipelines in Echtzeit überprüfen, die Details aller Warnungen überprüfen, fehlgeschlagene Phasen oder Aktionen erneut versuchen, Details zu den Quellversionen anzeigen, die bei der letzten Pipeline-Ausführung in jeder Phase verwendet wurden, und jede Pipeline manuell erneut ausführen.
+ **Details zum Pipeline-Verlauf** anzeigen: Sie können Details zu den Ausführungen einer Pipeline anzeigen, einschließlich Start- und Endzeiten, Ausführungsdauer und Ausführung. IDs
# Ein kurzer Blick auf CodePipeline
Das folgende Diagramm zeigt ein Beispiel für einen Veröffentlichungsprozess unter Verwendung von CodePipeline.
![\[Ein Beispiel für einen Release-Prozess mit CodePipeline.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/PipelineFlow.png)
In diesem Beispiel entdeckt CodePipeline automatisch die Änderungen, wenn Developer ein Commit für Änderungen für ein Quell-Repository durchführen. Diese Änderungen werden erstellt. Wenn Tests konfiguriert werden, werden diese Tests ausgeführt. Nach Abschluss der Tests wird der erstellte Code für weitere Tests auf Staging-Servern bereitgestellt. CodePipeline Führt auf dem Staging-Server weitere Tests aus, z. B. Integrations- oder Auslastungstests. Nach erfolgreichem Abschluss dieser Tests und nach Genehmigung einer manuellen Genehmigungsaktion, die der Pipeline hinzugefügt wurde, wird der getestete und genehmigte Code auf Produktionsinstanzen CodePipeline bereitgestellt.
CodePipeline kann mithilfe von, oder Anwendungen auf EC2-Instances CodeDeploy bereitstellen. AWS Elastic Beanstalk AWS OpsWorks Stacks CodePipeline kann mithilfe von Amazon ECS auch containerbasierte Anwendungen für Services bereitstellen. Entwickler können die mitgelieferten Integrationspunkte auch verwenden, CodePipeline um andere Tools oder Dienste zu integrieren, darunter Build-Services, Testanbieter oder andere Bereitstellungsziele oder -systeme.
Eine Pipeline kann so einfach oder so komplex sein, wie von Ihrem Veröffentlichungsprozess gefordert.
# Wie fange ich an mit CodePipeline?
Um loszulegen mit CodePipeline:
1. Lesen **Sie** den [CodePipeline Konzepte ](concepts.md) Abschnitt, um zu erfahren, wie das CodePipeline funktioniert.
1. **Bereiten Sie sich** auf die Verwendung vor, CodePipeline indem Sie die Schritte unter befolgen[Erste Schritte mit CodePipeline](getting-started-codepipeline.md).
1. **Experimentieren** Sie damit, CodePipeline indem Sie die Schritte in den [CodePipeline Tutorials](tutorials.md) Tutorials befolgen.
1. **Verwenden Sie** es CodePipeline für Ihre neuen oder vorhandenen Projekte, indem Sie die Schritte unter befolgen[Eine Pipeline, Phasen und Aktionen erstellen](pipelines-create.md).
# CodePipeline Konzepte
Die Modellierung und Konfiguration Ihres automatisierten Release-Prozesses ist einfacher, wenn Sie die in verwendeten Konzepte und Begriffe verstehen AWS CodePipeline. Im Folgenden finden Sie einige Konzepte, die Sie kennen sollten, wenn Sie CodePipeline verwenden.
Ein Beispiel für eine DevOps Pipeline finden Sie unter[DevOps Beispiel für eine Pipeline](concepts-devops-example.md).
Die folgenden Begriffe werden in verwendet CodePipeline:
**Topics**
+ [Pipelines](#concepts-pipelines)
+ [Pipeline-Ausführungen](#concepts-executions)
+ [Operationen in Etappen](#concepts-stage-executions)
+ [Aktionsausführungen](#concepts-action-executions)
+ [Arten der Ausführung](#concepts-execution-types)
+ [Aktionstypen](#concepts-action-types)
+ [-Artefakte](#concepts-artifacts)
+ [Quell-Revisionen](#concepts-source-revisions)
+ [Auslöser](#concepts-triggers)
+ [Variablen](#concepts-variables)
+ [Bedingungen](#concepts-conditions)
+ [Regeln](#concepts-rules)
## Pipelines
Eine *Pipeline* ist ein Workflow-Konstrukt, das den Veröffentlichungsprozess von Software-Änderungen beschreibt. Jede Pipeline besteht aus einer Reihe von *Phasen*.
### Stufen
Eine Phase ist eine logische Einheit, mit der Sie eine Umgebung isolieren und die Anzahl der Änderungen einschränken können, die in dieser Umgebung gleichzeitig ausgeführt werden. Jede Phase enthält Aktionen, die für die [Artefakte](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts) der Anwendung ausgeführt werden. Ihr Quellcode ist ein Beispiel für ein Artefakt. Bei einer Phase kann es sich um eine Build-Phase handeln, in der der Quellcode erstellt und getestet wird. Es kann sich auch um eine Bereitstellungsphase handeln, in der Code in Laufzeitumgebungen bereitgestellt wird. Jede Phase besteht aus einer Reihe serieller oder paralleler *Aktionen*.
### Übergänge
Ein *Übergang* ist der Punkt, an dem eine Pipeline-Ausführung zur nächsten Phase in der Pipeline wechselt. Sie können den Eingangspunkt einer Phase deaktivieren, um zu verhindern, dass Ausführungen in diese Phase eintreten. Anschließend können Sie den Eingangspunkt aktivieren, damit Ausführungen fortgesetzt werden können. Wenn mehrere Ausführungen an einem deaktivierten Übergangspunkt eintreffen, wird nur die neueste Ausführung zur nächsten Phase fortgesetzt, wenn der Übergangspunkt aktiviert wird. Das bedeutet, dass neuere Ausführungen bereits wartende Ausführungen ersetzen, während der Übergangspunkt deaktiviert ist. Nach der Aktivierung des Übergangspunkts wird nur die ersetzende Ausführung fortgesetzt.
![\[Eine Pipeline enthält Phasen, die Aktionen enthalten. Diese werden durch Übergänge getrennt, die deaktiviert und aktiviert werden können.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/pipeline-elements-workflow.png)
### Aktionen
Eine *Aktion* ist ein Satz von Operationen, die auf Anwendungscode angewendet werden. Sie ist für die Ausführung an einem bestimmten Punkt der Pipeline konfiguriert. Dies können Quellaktionen aufgrund von Codeänderungen, Aktionen zum Bereitstellen der Anwendung auf Instances usw. sein. Eine Bereitstellungsphase kann beispielsweise eine Bereitstellungsaktion enthalten, die Code für einen Rechenservice wie Amazon EC2 oder AWS Lambda bereitstellt.
Gültige CodePipeline Aktionstypen sind`source`,`build`,`test`, `deploy``approval`, und`invoke`. Eine Liste der Aktionsanbieter finden Sie unter [Gültige Aktionsanbieter in CodePipeline](actions-valid-providers.md).
Aktionen können seriell oder parallel ausgeführt werden. Informationen zu seriellen und parallel Aktionen in einer Phase finden Sie unter [Anforderungen an die `runOrder` Aktionsstruktur](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html#action-requirements).
## Pipeline-Ausführungen
Eine *Ausführung* ist ein Satz von Änderungen, die von einer Pipeline freigegeben werden. Jede Pipeline-Ausführung ist eindeutig und besitzt eine eigene ID. Eine Ausführung entspricht einem Satz von Änderungen, z. B. einem zusammengeführten Commit oder einer manuellen Freigabe des letzten Commits. Zwei Ausführungen können den gleichen Satz von Änderungen zu unterschiedlichen Zeitpunkten freigeben.
Während eine Pipeline mehrere Ausführungen gleichzeitig verarbeiten kann, verarbeitet eine Pipeline-Phase jeweils nur eine Ausführung zur selben Zeit. Hierzu wird die Phase gesperrt, während sie eine Ausführung verarbeitet. Zwei Pipeline-Ausführungen können nicht gleichzeitig dieselbe Phase belegen. Eine Ausführung, die darauf wartet, in die besetzte Phase überzugehen, wird als *eingehende Ausführung* bezeichnet. Eine eingehende Ausführung kann immer noch fehlschlagen, ersetzt oder manuell gestoppt werden. Weitere Hinweise zur Funktionsweise eingehender Ausführungen finden Sie unter. [So funktionieren eingehende Ausführungen](concepts-how-it-works.md#how-it-works-inbound-executions)
Pipeline-Ausführungen durchlaufen die Pipeline-Phasen der Reihe nach. Gültige Statuswerte für Pipelines sind `InProgress`, `Stopping`, `Stopped`, `Succeeded`, `Superseded` und `Failed`.
Weitere Informationen finden Sie unter [PipelineExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineExecution.html).
### Angehaltene Ausführungen
Die Pipeline-Ausführung kann manuell angehalten werden, sodass die laufende Pipeline-Ausführung nicht durch die Pipeline hindurch fortgesetzt wird. Wenn die Pipeline-Ausführung manuell angehalten wird, zeigt sie den Status `Stopping` an, bis sie vollständig gestoppt wird. Danach zeigt sie den Status `Stopped` an. Eine `Stopped`-Pipeline-Ausführung kann erneut ausgeführt werden.
Es gibt zwei Möglichkeiten, eine Pipeline-Ausführung anzuhalten:
+ **Anhalten und warten**
+ **Anhalten und beenden**
Informationen über Anwendungsfälle für das Anhalten einer Ausführung und Details zur Reihenfolge dieser Optionen finden Sie unter [Pipeline-Ausführungen beenden](concepts-how-it-works.md#concepts-how-it-works-stopping).
### Fehlgeschlagene Ausführungen
Wenn eine Ausführung fehlschlägt, wird sie angehalten und durchläuft die Pipeline nicht vollständig. Ihr Status ist `FAILED` und die Phase wird freigeschaltet. Eine neuere Ausführung kann in die entsperrte Phase eintreten und diese sperren. Sie können eine fehlgeschlagene Ausführung wiederholen, wenn diese nicht ersetzt wurde oder nicht wiederholbar ist. Sie können eine fehlgeschlagene Phase auf eine vorherige erfolgreiche Ausführung zurücksetzen.
### Ausführungsmodi
Um die neuesten Änderungen über eine Pipeline bereitzustellen, holen neuere Ausführungen weniger aktuelle Ausführungen ein, die bereits über die Pipeline ausgeführt werden, und ersetzen diese. In diesem Fall wird die ältere Ausführung durch die neuere Ausführung ersetzt. Eine Ausführung kann durch eine neuere Ausführung an einem bestimmten Punkt ersetzt werden. Dies ist der Punkt zwischen den einzelnen Phasen. SUPERSEDED ist der Standard-Ausführungsmodus.
Wenn im SUPERSEDED-Modus eine Ausführung darauf wartet, in eine gesperrte Phase einzutreten, kann eine neuere Ausführung sie catch und ersetzen. Die neuere Ausführung wartet nun auf die Entsperrung der Phase und die ersetzte Ausführung wird mit dem Status `SUPERSEDED` beendet. Wenn eine Pipeline-Ausführung ersetzt wird, wird die Ausführung gestoppt und durchläuft die Pipeline nicht vollständig. Sie können die ersetzte Ausführung nicht wiederholen, nachdem sie in dieser Phase ersetzt wurde. Andere verfügbare Ausführungsmodi sind der PARALLEL- oder QUEUED-Modus.
Weitere Hinweise zu Ausführungsmodi und gesperrten Phasen finden Sie unter[Wie werden Ausführungen im Modus ABGELÖST verarbeitet](concepts-how-it-works.md#concepts-how-it-works-executions).
## Operationen in Etappen
Wenn eine Pipeline-Ausführung eine Phase durchläuft, ist die Phase dabei, alle darin enthaltenen Aktionen abzuschließen. Hinweise zur Funktionsweise von Phasenoperationen und Informationen zu gesperrten Phasen finden Sie unter[Wie werden Ausführungen im Modus ABGELÖST verarbeitet](concepts-how-it-works.md#concepts-how-it-works-executions).
Gültige Status für Stufen sind`InProgress`,`Stopping`, `Stopped``Succeeded`, und`Failed`. Sie können eine fehlgeschlagene Phase erneut versuchen, es sei denn, die fehlgeschlagene Phase kann nicht wiederholt werden. Weitere Informationen finden Sie unter [StageExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageExecution.html). Sie können eine Phase auf eine angegebene vorherige erfolgreiche Ausführung zurücksetzen. Eine Phase kann so konfiguriert werden, dass bei einem Fehler ein automatisches Rollback ausgeführt wird, wie unter beschrieben[Konfiguration des Stage-Rollbacks](stage-rollback.md). Weitere Informationen finden Sie unter [RollbackStage](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RollbackStage.html).
## Aktionsausführungen
Eine *Aktionsausführung* ist die Durchführung einer konfigurierten Aktion, die für bestimmte[Artefakte](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts) ausgeführt wird. Dies können Eingabe-Artefakte, Ausgabe-Artefakte oder beides sein. Beispielsweise kann eine Build-Aktion Build-Befehle für ein Eingabe-Artefakt ausführen, z. B. das Anwendungsquellcode kompilieren. Die Details der Aktionsausführung umfassen die Aktionsausführungs-ID, den zugehörigen Pipeline-Ausführungsquellauslöser und die Eingabe- und Ausgabe-Artefakte der Aktion.
Gültige Status für Aktionen sind`InProgress`, `Abandoned``Succeeded`, oder`Failed`. Weitere Informationen finden Sie unter [ActionExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionExecution.html).
## Arten der Ausführung
Bei einer Pipeline- oder Phasenausführung kann es sich entweder um eine Standardausführung oder um eine Ausführung mit Rollback handeln.
Bei Standardtypen hat die Ausführung eine eindeutige ID und es handelt sich um eine vollständige Pipeline-Ausführung. Ein Pipeline-Rollback hat eine Phase, für die ein Rollback ausgeführt werden muss, und eine erfolgreiche Ausführung für die Phase als Zielausführung, zu der ein Rollback durchgeführt werden soll. Die Ausführung der Zielpipeline wird verwendet, um Quellversionen und Variablen für die Phase abzurufen, die erneut ausgeführt werden soll.
## Aktionstypen
*Aktionstypen* sind vorkonfigurierte Aktionen, die unter ausgewählt werden können. CodePipeline Der Aktionstyp wird durch seinen Besitzer, Anbieter, Version und Kategorie definiert. Der Aktionstyp stellt benutzerdefinierte Parameter bereit, die verwendet werden, um die Aktionsaufgaben in einer Pipeline abzuschließen.
Informationen zu den Produkten AWS-Services und Diensten von Drittanbietern, die Sie je nach Aktionstyp in Ihre Pipeline integrieren können, finden Sie unter[Integrationen mit CodePipeline Aktionstypen](integrations-action-type.md).
Informationen zu den Integrationsmodellen, die für Aktionstypen in unterstützt werden CodePipeline, finden Sie unter[Referenz zum Integrationsmodell](reference-integrations.md).
Informationen darüber, wie Drittanbieter Aktionstypen in einrichten und verwalten können CodePipeline, finden Sie unter[Mit Aktionstypen arbeiten](action-types.md).
## -Artefakte
Der Begriff *Artefakt* bezieht sich auf die Sammlung von Daten, wie Anwendungsquellcode, erstellte Anwendungen, Abhängigkeiten, Definitionsdateien, Vorlagen usw., die von Pipeline-Aktionen bearbeitet werden. Artefakte werden von bestimmten Aktionen erzeugt und von anderen Aktionen verbraucht. Artefakten in einer Pipeline können die Gruppe von Dateien sein, die von einer Aktion bearbeitet werden (*Eingabe-Artefakte*) oder die aktualisierte Ausgabe einer abgeschlossenen Aktion (*Ausgabe-Artefakte*).
Aktionen leiten die Ausgabe an eine andere Aktion zur weiteren Verarbeitung mithilfe des Pipeline-Artefakt-Buckets weiter. CodePipeline kopiert Artefakte in den Artefaktspeicher, wo sie von der Aktion abgerufen werden. Weitere Informationen zu Artefakten finden Sie unter [Eingabe- und Ausgabe-Artefakte](welcome-introducing-artifacts.md).
## Quell-Revisionen
Wenn Sie eine Quellcodeänderung ausführen, wird eine neue Version erstellt. Eine *Quellrevision* ist eine Quelländerungsversion, die eine Pipeline-Ausführung auslöst. Bei einer Ausführung werden Quellversionen verarbeitet. Für GitHub und CodeCommit Repositorien ist dies der Commit. Bei S3-Buckets oder -Aktionen ist dies die Objektversion.
Sie können eine Pipeline-Ausführung mit einer von Ihnen angegebenen Quellrevision starten, z. B. einem Commit. Die Ausführung verarbeitet die angegebene Revision und überschreibt die Version, die für die Ausführung verwendet worden wäre. Weitere Informationen finden Sie unter [Starten Sie eine Pipeline mit einer Quellrevisionsüberschreibung](pipelines-trigger-source-overrides.md).
## Auslöser
*Trigger* sind Ereignisse, die Ihre Pipeline starten. Einige Auslöser, z. B. das manuelle Starten einer Pipeline, sind für alle Quellaktionsanbieter in einer Pipeline verfügbar. Bestimmte Trigger hängen vom Quellanbieter für eine Pipeline ab. CloudWatch Ereignisse müssen beispielsweise mit Ereignisressourcen von Amazon konfiguriert werden CloudWatch , denen der Pipeline-ARN als Ziel in der Ereignisregel hinzugefügt wurde. Amazon CloudWatch Events ist der empfohlene Auslöser für die automatische Änderungserkennung für Pipelines mit einer CodeCommit oder S3-Quellaktion. Webhooks sind ein Triggertyp, der für Repository-Ereignisse von Drittanbietern konfiguriert ist. WebHookV2 ist beispielsweise ein Triggertyp, der es ermöglicht, Git-Tags zu verwenden, um Pipelines mit externen Quellanbietern wie GitHub .com, GitHub Enterprise Server, GitLab .com, GitLab Self-managed oder Bitbucket Cloud zu starten. In der Pipeline-Konfiguration kannst du einen Filter für Trigger wie Push- oder Pull-Requests angeben. Du kannst Code-Push-Ereignisse nach Git-Tags, Branches oder Dateipfaden filtern. Du kannst Pull-Request-Ereignisse nach Ereignissen (geöffnet, aktualisiert, geschlossen), Branches oder Dateipfaden filtern.
Weitere Informationen zu Auslösern finden Sie unter [Starten Sie eine Pipeline in CodePipeline](pipelines-about-starting.md). Ein Tutorial, das Sie durch die Verwendung von Git-Tags als Trigger für Ihre Pipeline führt, finden Sie unter[Tutorial: Verwende Git-Tags, um deine Pipeline zu starten](tutorials-github-tags.md).
**Wichtig**
Bei Pipelines, die länger als 30 Tage inaktiv sind, ist das Polling für die Pipeline deaktiviert. Weitere Informationen finden Sie [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)in der Referenz zur Pipeline-Struktur. Die Schritte zur Migration Ihrer Pipeline von der Abfrage zur ereignisbasierten Änderungserkennung finden Sie unter Methoden zur [Änderungserkennung](change-detection-methods.md).
## Variablen
Eine *Variable* ist ein Wert, der verwendet werden kann, um Aktionen in Ihrer Pipeline dynamisch zu konfigurieren. Variablen können entweder auf Pipeline-Ebene deklariert oder durch Aktionen in der Pipeline ausgegeben werden. Variablenwerte werden zum Zeitpunkt der Pipeline-Ausführung aufgelöst und können im Ausführungsverlauf eingesehen werden. Für Variablen, die auf Pipeline-Ebene deklariert wurden, können Sie entweder Standardwerte in der Pipeline-Konfiguration definieren oder sie für eine bestimmte Ausführung überschreiben. Bei Variablen, die von einer Aktion ausgegeben werden, ist der Wert verfügbar, nachdem eine Aktion erfolgreich abgeschlossen wurde. Weitere Informationen finden Sie unter [Variablen-Referenz](reference-variables.md).
## Bedingungen
Eine *Bedingung* enthält eine Reihe von Regeln, die ausgewertet werden. Wenn alle Regeln in einer Bedingung erfolgreich sind, ist die Bedingung erfüllt. Sie können Bedingungen so konfigurieren, dass, wenn die Kriterien nicht erfüllt sind, das angegebene Ergebnis, z. B. wenn die Phase nicht bestanden wird, aktiviert wird. Bedingungen werden auch als Gates bezeichnet, da Sie mit ihnen angeben können, wann eine Ausführung in eine Phase eintritt und diese durchläuft oder die Phase verlässt, nachdem sie sie durchlaufen hat. Dies ist vergleichbar mit der Möglichkeit, einer Verkehrslinie auf einer Fahrbahn zu erlauben, sich an einem geschlossenen Tor zu versammeln und dann festzulegen, wie das Tor geöffnet werden soll, damit der Verkehr in ein Gebiet fließen kann. Zu den Ergebnissen für Zustandstypen gehören das Scheitern der Phase oder das Zurücksetzen der Phase. Mithilfe von Bedingungen können Sie angeben, wann diese Aktionen in einer Pipeline-Phase stattfinden. Sie können Bedingungen zur Laufzeit überschreiben.
Es gibt drei Arten von Bedingungen. Die Teilnahmebedingungen beantworten die Frage „Wenn die Regeln für die Bedingung erfüllt sind, treten Sie in die Phase ein.“ Die Phase ist gesperrt, wenn die Ausführung in die Phase eintritt, und dann werden die Regeln ausgeführt. Bei Bedingungen bei Ausfall wird die Regel aktiviert, wenn eine Phase fehlgeschlagen ist, was zur Folge hat, dass eine fehlgeschlagene Phase zurückgesetzt wird. Bei Bedingungen bei Erfolg wird die Regel aktiviert, wenn eine Phase erfolgreich ist, z. B. wenn ein erfolgreicher Lauf auf Alarme überprüft wird, bevor der Vorgang fortgesetzt wird. Beispielsweise würde die Bedingung On Success zu einem Rollback einer erfolgreichen Phase führen, wenn die CloudWatchAlarm Regel feststellt, dass es in der Bereitstellungsumgebung Alarme gibt. Weitere Informationen finden Sie unter [Wie funktionieren die Stufenbedingungen?](concepts-how-it-works-conditions.md).
## Regeln
Bedingungen verwenden eine oder mehrere vorkonfigurierte *Regeln*, die Prüfungen ausführen und durchführen, die dann das konfigurierte Ergebnis verwenden, wenn die Bedingung nicht erfüllt ist. Wenn beispielsweise alle Regeln für eine Regel mit Eingabebedingungen erfüllt werden, die den Alarmstatus und die Zeitfenster für die Bereitstellung überprüft, wird eine erfolgreiche Phase ausgelöst, nachdem alle Prüfungen bestanden wurden. Weitere Informationen finden Sie unter [Wie funktionieren die Stufenbedingungen?](concepts-how-it-works-conditions.md).
# DevOps Beispiel für eine Pipeline
Als Beispiel für eine DevOps Pipeline könnte eine zweistufige Pipeline eine Quellstufe namens **Source** und eine zweite Stufe namens **Prod** haben. In diesem Beispiel aktualisiert die Pipeline die Anwendung mit den neuesten Änderungen und stellt kontinuierlich das neueste Ergebnis bereit. Bevor die neueste Anwendung bereitgestellt wird, erstellt und testet die Pipeline die Webanwendung. In diesem Beispiel hat eine Gruppe von Entwicklern eine Infrastrukturvorlage und den Quellcode für eine Webanwendung in einem GitHub Repository namens eingerichtet. MyRepository
![\[Eine Pipeline mit Beispielphasen und -aktionen.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/pipeline-elements-workflow-application.png)
Ein Entwickler verschiebt beispielsweise eine Fehlerbehebung per Push zur Indexseite der Webanwendung. Folgendes tritt auf:
1. Der Quellcode der Anwendung wird in einem Repository verwaltet, das als GitHub Quellaktion in der Pipeline konfiguriert ist. Wenn Entwickler Commits per Push in das Repository übertragen, wird die übertragene Änderung CodePipeline erkannt und die Pipeline-Ausführung beginnt in der **Quellphase**.
1. Die GitHub Quellaktion wird erfolgreich abgeschlossen (das heißt, die neuesten Änderungen wurden heruntergeladen und in dem für diese Ausführung spezifischen Artefakt-Bucket gespeichert). Die von der GitHub Quellaktion erzeugten *Ausgabeartefakte*, bei denen es sich um die Anwendungsdateien aus dem Repository handelt, werden dann als *Eingabeartefakte* verwendet, an denen die Aktionen in der nächsten Phase arbeiten.
1. Die Pipeline-Ausführung wechselt von der **Quellphase** zur **Produktionsphase**. Die erste Aktion in der **Produktionsphase** führt ein Build-Projekt aus, das in der Pipeline erstellt CodeBuild und als Build-Aktion konfiguriert wurde. Die Build-Aufgabe ruft ein Build-Umgebungs-Image ab und erstellt die Webanwendung in einem virtuellen Container.
1. Die nächste Aktion in der **Produktionsphase** ist ein Komponententest-Projekt, das in der CodeBuild Pipeline als Testaktion erstellt und konfiguriert wurde.
1. Der komponentengetestete Code wird als Nächstes von einer Bereitstellungsaktion in der **Produktionsphase** bearbeitet, die die Anwendung zu einer Produktionsumgebung bereitstellt. Nachdem die Bereitstellungsaktion erfolgreich abgeschlossen wurde, ist die letzte Aktion in der Phase ein Integrationstestprojekt, das in der Pipeline erstellt CodeBuild und als Testaktion konfiguriert wurde. Die Testaktion ruft Shell-Skripte auf, die ein Testtool in der Webanwendung installieren und ausführen, z. B. einen Linkprüfer. Nach erfolgreichem Abschluss besteht die Ausgabe in einer erstellten Webanwendung und einer Reihe von Testergebnissen.
Entwickler können der Pipeline Aktionen hinzufügen, die die Anwendung bereitstellen oder weiter testen, nachdem sie bei jeder Änderung erstellt und getestet wurde.
Weitere Informationen finden Sie unter [So funktionieren Pipeline-Ausführungen](concepts-how-it-works.md).
# So funktionieren Pipeline-Ausführungen
Dieser Abschnitt bietet einen Überblick über die Art und Weise, wie eine Reihe von Änderungen CodePipeline verarbeitet werden. CodePipelineverfolgt jede Pipeline-Ausführung, die beginnt, wenn eine Pipeline manuell gestartet oder eine Änderung am Quellcode vorgenommen wird. CodePipeline verwendet die folgenden Ausführungsmodi, um die Art und Weise zu handhaben, wie jede Ausführung durch die Pipeline voranschreitet. Weitere Informationen finden Sie unter [Legen Sie den Pipeline-Ausführungsmodus fest oder ändern Sie ihn](execution-modes.md).
+ Modus ABGELÖST: Eine neuere Ausführung kann eine ältere überholen. Dies ist die Standardeinstellung.
+ QUEUED-Modus: Ausführungen werden nacheinander in der Reihenfolge verarbeitet, in der sie sich in der Warteschlange befinden. Dies erfordert den Pipeline-Typ V2.
+ PARALLEL-Modus: Im PARALLEL-Modus werden Ausführungen gleichzeitig und unabhängig voneinander ausgeführt. Ausführungen warten nicht darauf, dass andere Läufe abgeschlossen sind, bevor sie gestartet oder beendet werden. Dies erfordert den Pipeline-Typ V2.
**Wichtig**
Für Pipelines im PARALLEL-Modus ist ein Stufen-Rollback nicht verfügbar. Ebenso können Fehlerbedingungen mit einem Rollback-Ergebnistyp nicht zu einer Pipeline im PARALLEL-Modus hinzugefügt werden.
## So werden Pipeline-Ausführungen gestartet
Sie können eine Ausführung starten, wenn Sie Ihren Quellcode ändern, oder Sie können die Pipeline manuell starten. Sie können eine Ausführung auch über eine von Ihnen geplante Amazon CloudWatch Events-Regel auslösen. Wenn beispielsweise eine Quellcodeänderung per Push zu einem Repository übertragen wird, das als Quellaktion der Pipeline konfiguriert ist, erkennt die Pipeline die Änderung und startet eine Ausführung.
**Anmerkung**
Wenn eine Pipeline mehrere Quellaktionen enthält, werden alle erneut ausgeführt, auch wenn nur für eine Quellaktion eine Änderung entdeckt wird.
## Wie Quellversionen in Pipeline-Ausführungen verarbeitet werden
Für jede Pipeline-Ausführung, die mit Änderungen am Quellcode (Quellrevisionen) beginnt, werden die Quellrevisionen wie folgt bestimmt.
+ Bei Pipelines mit einer CodeCommit Quelle wird der HEAD in dem Moment geklont, CodePipeline in dem der Commit übertragen wird. Beispielsweise wird ein Commit per Push übertragen, wodurch die Pipeline für Ausführung 1 gestartet wird. In dem Moment, in dem ein zweiter Commit übertragen wird, wird die Pipeline für Ausführung 2 gestartet.
**Anmerkung**
Bei Pipelines im PARALLEL-Modus mit einer CodeCommit Quelle klont die Quellaktion unabhängig vom Commit, das die Pipeline-Ausführung ausgelöst hat, den HEAD immer zum Zeitpunkt des Starts. Weitere Informationen finden Sie unter [CodeCommit oder S3-Quellversionen im PARALLEL-Modus stimmen möglicherweise nicht mit dem Ereignis überein EventBridge](troubleshooting.md#troubleshooting-revisions-parallel).
+ Für Pipelines mit einer S3-Quelle wird das EventBridge Ereignis für das S3-Bucket-Update verwendet. Das Ereignis wird beispielsweise generiert, wenn eine Datei im Quell-Bucket aktualisiert wird, wodurch die Pipeline für Ausführung 1 gestartet wird. In dem Moment, in dem das Ereignis für ein zweites Bucket-Update ausgelöst wird, wird damit die Pipeline für Ausführung 2 gestartet.
**Anmerkung**
Bei Pipelines im PARALLEL-Modus mit einer S3-Quelle beginnt die Quellaktion unabhängig vom Image-Tag, das die Ausführung ausgelöst hat, immer mit dem neuesten Image-Tag. Weitere Informationen finden Sie unter [CodeCommit oder S3-Quellversionen im PARALLEL-Modus stimmen möglicherweise nicht mit dem Ereignis überein EventBridge](troubleshooting.md#troubleshooting-revisions-parallel).
+ Bei Pipelines mit einer Verbindungsquelle, z. B. zu Bitbucket, wird der HEAD in dem Moment geklont, CodePipeline in dem der Commit übertragen wird. Bei einer Pipeline im PARALLEL-Modus wird beispielsweise ein Commit per Push übertragen, wodurch die Pipeline für Ausführung 1 gestartet wird, und die zweite Pipeline-Ausführung verwendet den zweiten Commit.
## Wie funktionieren Quellenüberschreibungen mit dem EventBridge Eingangstransformator
Sie können Overrides verwenden, um eine Pipeline mit einer bestimmten Quell-Revision-ID zu starten, die Sie für die Pipeline-Ausführung angeben. Wenn Sie beispielsweise eine Pipeline starten möchten, die eine bestimmte Commit-ID aus Ihrer CodeCommit Quelle verarbeitet, können Sie die Commit-ID als Override hinzufügen, wenn Sie Ihre Pipeline starten.
Es gibt vier Arten von Quellrevisionen für`revisionType`:
+ `COMMIT_ID`
+ `IMAGE_DIGEST`
+ `S3_OBJECT_VERSION_ID`
+ `S3_OBJECT_KEY`
**Anmerkung**
Bei den Quellrevisionen `COMMIT_ID` und den `IMAGE_DIGEST` Typen gilt die Quellrevisions-ID für alle Inhalte im Repository in allen Zweigen.
**Anmerkung**
Für die `S3_OBJECT_KEY` Typen `S3_OBJECT_VERSION_ID` und Typen der Quellversionen können beide Typen unabhängig voneinander verwendet werden, oder sie können zusammen verwendet werden, um die Quelle mit einer bestimmten ObjectKey Versions-ID zu überschreiben. Für `S3_OBJECT_KEY` `AllowOverrideForS3ObjectKey` muss der Konfigurationsparameter auf gesetzt werden. `true` Weitere Informationen zu den Konfigurationsparametern der S3-Quelle finden Sie unter[Konfigurationsparameter](action-reference-S3.md#action-reference-S3-config).
Sie können Quellenüberschreibungen mithilfe des Eingangstransformators in EventBridge angeben. Verwenden Sie den Eingangstransformator, um die Daten wie folgt zu übergeben:
+ Sie können den Eingangstransformator verwenden, um die Daten als JSON-Parameter zu übergeben.
+ Sie können den Eingangstransformator verwenden, um Pipeline-Variablen zu übergeben.
Beispiele für die Übergabe der Daten als JSON-Parameter finden Sie unter[Amazon ECR-Quellaktionen und Ressourcen EventBridge](create-cwe-ecr-source.md), [Verbindung zu Amazon S3 S3-Quellaktionen herstellen, die EventBridge und verwenden AWS CloudTrail](create-cloudtrail-S3-source.md) für S3 und [CodeCommit Quellaktionen und EventBridge](triggering.md) für CodeCommit.
## Pipeline-Ausführungen beenden
Um die Konsole zum Beenden einer Pipeline-Ausführung zu verwenden, können Sie **Stop execution (Ausführung beenden)** auf der Seite mit der Pipeline-Visualisierung, auf der Seite mit dem Ausführungsverlauf oder auf der Seite mit dem detaillierten Verlauf auswählen. Um die CLI zum Beenden einer Pipeline-Ausführung zu verwenden, verwenden Sie den Befehl `stop-pipeline-execution`. Weitere Informationen finden Sie unter [Stoppen Sie eine Pipeline-Ausführung in CodePipeline](pipelines-stop.md).
Es gibt zwei Möglichkeiten, eine Pipeline-Ausführung anzuhalten:
+ **Anhalten und warten:** Alle laufenden Aktionsausführungen dürfen abgeschlossen werden, und nachfolgende Aktionen werden nicht gestartet. Die Pipeline-Ausführung wird nicht in den nachfolgenden Phasen fortgesetzt. Sie können diese Option nicht für eine Ausführung verwenden, die sich bereits in einem `Stopping`-Status befindet.
+ **Anhalten und beenden:** Alle laufenden Aktionsausführungen werden angehalten und nicht abgeschlossen, und nachfolgende Aktionen werden nicht begonnen. Die Pipeline-Ausführung wird nicht in den nachfolgenden Phasen fortgesetzt. Sie können diese Option bei einer Ausführung verwenden, die sich bereits in einem `Stopping`-Status befindet.
**Anmerkung**
Diese Option kann zu fehlgeschlagenen oder nicht aufeinander folgenden Aufgaben führen.
Jede Option führt zu einer anderen Abfolge von Pipeline- und Aktionsausführungsphasen:
**Option 1: Anhalten und warten**
Wenn Sie sich für das Anhalten und Warten entscheiden, wird die ausgewählte Ausführung fortgesetzt, bis die laufenden Aktionen abgeschlossen sind. Beispielsweise wurde die folgende Pipeline-Ausführung angehalten, während die Build-Aktion lief.
1. In der Pipeline-Ansicht wird das Banner für Erfolgsmeldungen angezeigt, und die Build-Aktion wird fortgesetzt, bis sie abgeschlossen ist. Der Status der Pipeline-Ausführung ist **Stopping (Wird angehalten)**.
In der Verlaufsansicht ist der Status für laufende Aktionen, wie z. B. die Build-Aktion, **In progress (In Bearbeitung)**, bis die Build-Aktion abgeschlossen ist. Während die Aktionen in Bearbeitung sind, ist der Status der Pipeline-Ausführung **Stopping (Wird angehalten)**.
1. Die Ausführung wird angehalten, wenn der Anhaltevorgang abgeschlossen ist. Wenn die Build-Aktion erfolgreich abgeschlossen ist, hat sie den Status **Succeeded (Erfolgreich abgeschlossen)**, und die Pipeline-Ausführung zeigt den Status **Stopped (Angehalten)**. Nachfolgende Aktionen werden nicht gestartet. Die Schaltfläche **Retry (Wiederholen)** ist aktiviert.
In der Verlaufsansicht wird der Ausführungsstatus **Stopped (Beendet)** angezeigt, nachdem die laufende Aktion abgeschlossen ist.
![\[Das Bild zeigt die Verlaufsansicht, in der der Ausführungsstatus „Gestoppt“ lautet, nachdem die laufende Aktion abgeschlossen wurde\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/stop-exec-wait-hist-1.png)
**Option 2: Anhalten und beenden**
Wenn Sie sich zum Anhalten und Beenden entscheiden, wartet die ausgewählte Ausführung nicht auf den Abschluss der laufenden Aktionen. Die Aktionen werden beendet. Beispielsweise wurde die folgende Pipeline-Ausführung angehalten und beendet, während die Build-Aktion lief.
1. In der Pipeline-Ansicht wird die Erfolgsbanner-Meldung angezeigt, die Build-Aktion zeigt den Status **In progress (In Bearbeitung)** und die Pipeline-Ausführung den Status **Stopping (Wird angehalten)**.
1. Nachdem die Pipeline-Ausführung beendet wurde, zeigt die Build-Aktion den Status **Abandoned (Beendet)** und die Pipeline-Ausführung den Status **Stopped (Angehalten)** an. Nachfolgende Aktionen werden nicht gestartet. Die Schaltfläche **Retry (Wiederholen)** ist aktiviert.
1. In der Verlaufsansicht ist der Ausführungsstatus **Stopped (Beendet)**.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/stop-exec-abandon-hist-1.png)
**Nutzungsszenarien zum Beenden einer Pipeline-Ausführung**
Wir empfehlen Ihnen, die Option „Anhalten und warten“ zu verwenden, um eine Pipeline-Ausführung zu beenden. Diese Option ist sicherer, da sie mögliche Fehlschläge oder out-of-sequence Aufgaben in Ihrer Pipeline vermeidet. Wenn eine Aktion abgebrochen wird CodePipeline, setzt der Aktionsanbieter alle Aufgaben im Zusammenhang mit der Aktion fort. Im Fall einer CloudFormation Aktion wird die Bereitstellungsaktion in der Pipeline abgebrochen, aber das Stack-Update wird möglicherweise fortgesetzt und führt zu einem fehlgeschlagenen Update.
Ein Beispiel für aufgegebene Aktionen, die zu out-of-sequence Aufgaben führen können: Wenn Sie eine große Datei (1 GB) über eine S3-Bereitstellungsaktion bereitstellen und die Aktion beenden und abbrechen möchten, während die Bereitstellung bereits läuft, wird die Aktion in Amazon S3 abgebrochen CodePipeline, aber in Amazon S3 fortgesetzt. Amazon S3 erhält keine Anweisung, den Upload abzubrechen. Wenn Sie anschließend eine neue Pipeline-Ausführung mit einer sehr kleinen Datei starten, sind jetzt zwei Bereitstellungen im Gange. Da die Dateigröße der neuen Ausführung gering ist, wird die neue Bereitstellung abgeschlossen, während die alte Bereitstellung noch hochgeladen wird. Wenn die alte Bereitstellung abgeschlossen ist, wird die neue Datei durch die alte Datei überschrieben.
Sie können die Option zum Anhalten und Beenden verwenden, wenn Sie eine benutzerdefinierte Aktion haben. Sie können beispielsweise eine benutzerdefinierte Aktion abbrechen, deren Arbeit nicht abgeschlossen werden muss, bevor Sie eine neue Ausführung zur Behebung eines Fehlers starten.
## Wie werden Ausführungen im Modus ABGELÖST verarbeitet
Der Standardmodus für die Verarbeitung von Ausführungen ist der Modus ABGELÖST. Eine Ausführung besteht aus einer Reihe von Änderungen, die von der Ausführung aufgenommen und verarbeitet werden. Pipelines können mehrere Ausführungen gleichzeitig verarbeiten. Jede Ausführung wird in der Pipeline getrennt ausgeführt. Die Pipeline verarbeitet die einzelnen Ausführung der Reihe nach und ersetzt möglicherweise frühere Ausführungen durch spätere Ausführungen. Die folgenden Regeln werden verwendet, um Ausführungen in einer Pipeline für den SUPERSEDED-Modus zu verarbeiten.
**Regel 1: Phasen werden gesperrt, wenn eine Ausführung verarbeitet wird**
Da jede Phase jeweils nur eine Ausführung verarbeiten kann, ist eine Phase während der Verarbeitung einer Ausführung gesperrt. Wenn die Ausführung eine Phase abgeschlossen hat, wechselt sie zur nächsten Phase in der Pipeline.
![\[Das Bild zeigt die Phasen, die während der Ausführung gesperrt wurden\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/Promotion.png)
**Regel 2: Nachfolgende Ausführungen warten, bis die jeweilige Phase freigegeben wird**
Wenn eine Phase gesperrt ist, warten nachfolgende Ausführungen vor der gesperrten Phase. Alle für eine Phase konfigurierten Aktionen müssen erfolgreich abgeschlossen sein, bevor die Phase als abgeschlossen gilt. Eine fehlgeschlagene Ausführung löst die Sperre der Phase auf. Wenn eine Ausführung beendet wird, wird die Ausführung in einer Phase nicht fortgesetzt und die Phase wird freigegeben.
**Anmerkung**
Bevor Sie eine Ausführung beenden, empfehlen wir Ihnen, den Übergang vor der Phase zu deaktivieren. Auf diese Weise wird die Phase aufgrund der angehaltenen Ausführung entsperrt und akzeptiert keine nachfolgende Pipeline-Ausführung.
![\[Das Bild zeigt, wie die Ausführung im Wartemodus zwischen den Phasen wartet, wenn Phase 2 gesperrt ist\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/Waiting.png)
**Regel 3: Wartende Ausführungen werden durch neuere Ausführungen ersetzt**
Ausführungen werden nur zwischen den Phasen ersetzt. Wenn eine Phase gesperrt ist, wartet eine nachfolgende Ausführung am Eingangspunkt der Phase, bis die Phase abgeschlossen ist. Eine neuere Ausführung holt eine wartende Ausführung ein und fährt zur nächsten Phase fort, sobald die Phase freigegeben wird. Die ersetzte Ausführung wird nicht fortgesetzt. In diesem Beispiel wurde Ausführung 2 durch Ausführung 3 ersetzt, während sie auf die Freigabe der gesperrten Phase wartet. Ausführung 3 tritt in die nächste Phase ein.
![\[Das Bild zeigt, wie die Ausführung im Wartezustand durch Ausführung 3 ersetzt wird\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/Batching.png)
Weitere Hinweise zu Überlegungen beim Anzeigen und Wechseln zwischen Ausführungsmodi finden Sie unter. [Legen Sie den Pipeline-Ausführungsmodus fest oder ändern Sie ihn](execution-modes.md) Weitere Informationen zu Kontingenten mit Ausführungsmodi finden Sie unter[Kontingente in AWS CodePipeline](limits.md).
## Wie werden Ausführungen im QUEUED-Modus verarbeitet
Bei Pipelines im QUEUED-Modus werden Phasen gesperrt, wenn eine Ausführung verarbeitet wird. Wartende Ausführungen überholen jedoch nicht Ausführungen, die bereits gestartet wurden.
Wartende Ausführungen sammeln sich an den Eintrittspunkten zu gesperrten Phasen in der Reihenfolge, in der sie die Phase erreichen, und bilden so eine Warteschlange wartender Ausführungen. Im QUEUED-Modus können Sie mehrere Warteschlangen in derselben Pipeline haben. Wenn eine Ausführung in der Warteschlange in eine Phase eintritt, ist die Phase gesperrt und es können keine weiteren Ausführungen mehr gestartet werden. Dieses Verhalten entspricht dem Modus SUPERSEDED. Wenn die Ausführung die Phase abgeschlossen hat, wird die Stufe entsperrt und ist bereit für die nächste Ausführung.
Das folgende Diagramm zeigt, wie Phasen in einer Pipeline im QUEUED-Modus die Ausführung verarbeiten. Während in der Quellphase beispielsweise Ausführung 5 verarbeitet wird, bilden die Ausführungen für 6 und 7 die Warteschlange \$11 und warten am Startpunkt der Phase. Die nächste Ausführung in der Warteschlange wird verarbeitet, nachdem die Phase entsperrt wurde.
![\[Ein Diagramm, das Ausführungen in einer Pipeline zeigt, die für den QUEUED-Modus eingestellt ist.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/Queued-Execution-Mode.png)
Weitere Informationen zu Überlegungen beim Anzeigen und Wechseln zwischen Ausführungsmodi finden Sie unter. [Legen Sie den Pipeline-Ausführungsmodus fest oder ändern Sie ihn](execution-modes.md) Weitere Informationen zu Kontingenten mit Ausführungsmodi finden Sie unter[Kontingente in AWS CodePipeline](limits.md).
## Wie werden Ausführungen im PARALLELEN Modus verarbeitet
Bei Pipelines im PARALLEL-Modus sind die Ausführungen unabhängig voneinander und warten nicht, bis andere Ausführungen abgeschlossen sind, bevor sie gestartet werden. Es gibt keine Warteschlangen. Verwenden Sie die Ausführungshistorie-Ansicht, um parallel Ausführungen in der Pipeline anzuzeigen.
Verwenden Sie den PARALLEL-Modus in Entwicklungsumgebungen, in denen jede Funktion über einen eigenen Funktionszweig verfügt und auf Zielen bereitgestellt wird, die nicht von anderen Benutzern gemeinsam genutzt werden.
Weitere Informationen zu Überlegungen beim Anzeigen und Wechseln zwischen Ausführungsmodi finden Sie unter[Legen Sie den Pipeline-Ausführungsmodus fest oder ändern Sie ihn](execution-modes.md). Weitere Informationen zu Kontingenten mit Ausführungsmodi finden Sie unter[Kontingente in AWS CodePipeline](limits.md).
## Pipelinefluss verwalten
Der Ablauf von Pipeline-Ausführungen kann wie folgt gesteuert werden:
+ Ein *Übergang* steuert den Fluss von Ausführungen in die Phase. Übergänge können aktiviert oder deaktiviert werden. Wenn ein Übergang deaktiviert ist, können Pipeline-Ausführungen nicht in die Phase übergehen. Die Pipeline-Ausführung, die darauf wartet, in eine Phase einzutreten, in der der Übergang deaktiviert ist, wird als eingehende Ausführung bezeichnet. Nachdem Sie den Übergang aktiviert haben, geht eine eingehende Ausführung in die Phase über und sperrt sie.
Ähnlich wie bei Ausführungen, die auf die Freigabe einer gesperrten Phase warten, kann bei Deaktivierung eines Übergangs die Ausführung, die darauf wartet, in die Phase einzutreten, durch eine neue Ausführung ersetzt werden. Wenn ein deaktivierter Übergang erneut aktiviert wird, tritt die neueste Ausführung in die Phase ein. Dies gilt auch für Ausführungen, die ältere Ausführungen ersetzt haben, während der Übergang deaktiviert war.
+ Eine *Genehmigungsaktion*, die verhindert, dass eine Pipeline zur nächsten Aktion übergeht, bis die entsprechende Genehmigung erteilt wurde (z. B. durch manuelle Genehmigung durch eine autorisierte Identität). Sie können eine Genehmigungsaktion beispielsweise verwenden, wenn Sie den Zeitpunkt steuern möchten, an dem eine Pipeline zur abschließenden Phase **Production (Produktion)** wechselt.
**Anmerkung**
Eine Phase mit einer Genehmigungsaktion ist gesperrt, bis die Genehmigungsaktion genehmigt oder abgelehnt wurde oder eine Zeitüberschreitung eintritt. Eine abgelaufene Genehmigungsaktion wird auf die gleiche Weise wie eine fehlgeschlagene Aktion verarbeitet.
+ Ein *Fehler* bedeutet, dass eine Aktion in einer Phase nicht erfolgreich abgeschlossen wurde. Die Revision wird nicht zur nächsten Aktion in der Phase oder zur nächsten Phase in der Pipeline weitergeleitet. Folgendes kann auftreten:
+ Sie führen die Phase manuell erneut aus, die die fehlgeschlagenen Aktionen enthält. Hierdurch wird die Ausführung fortgesetzt (fehlgeschlagene Aktionen werden wiederholt und, wenn erfolgreich, in der Phase/Pipeline fortgesetzt).
+ Eine andere Ausführung tritt in die fehlgeschlagene Phase ein und ersetzt die fehlgeschlagene Ausführung. In diesem Fall kann die fehlgeschlagene Ausführung nicht wiederholt werden.
### Empfohlene Pipeline-Struktur
Wenn Sie den Fluss einer Codeänderung durch die Pipeline festlegen, sollten Sie verwandte Aktionen innerhalb einer Phase gruppieren, sodass die Aktionen dieselbe Ausführung verarbeiten, wenn die Phase gesperrt wird. Sie können für jede Anwendungsumgebung AWS-Region, Availability Zone usw. eine Phase erstellen. Eine Pipeline mit zu vielen Phasen (die also zu detailliert definiert ist) kann zu viele gleichzeitige Änderungen ermöglichen. Eine Pipeline mit vielen Aktionen in einer großen Phase (die also zu grob definiert ist) kann zu viel Zeit benötigen, um eine Änderung freizugeben.
Beispiel: Eine Testaktion nach einer Bereitstellungsaktion in derselben Phase testet garantiert die Änderung, die bereitgestellt wurde. In diesem Beispiel wird eine Änderung in einer Testumgebung bereitgestellt und dann getestet. Dann wird die letzte Änderung aus der Testumgebung in eine Produktionsumgebung bereitgestellt. Im empfohlenen Beispiel handelt es sich bei Testumgebung und Produktionsumgebung um getrennte Phasen.
![\[Das Bild zeigt zwei Arten der Gruppierung von Aktionen in Stufen, wobei sich die empfohlene Option auf der linken Seite befindet\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/structure-example-recommended-notrecommended.png)
### So funktionieren eingehende Ausführungen
Eine eingehende Ausführung ist eine Ausführung, die darauf wartet, dass eine Phase, ein Übergang oder eine Aktion verfügbar wird, die nicht verfügbar ist, bevor sie fortgeführt wird. Die nächste Phase, der Übergang oder die nächste Aktion ist möglicherweise aus folgenden Gründen nicht verfügbar:
+ Eine weitere Exekution ist bereits in die nächste Phase eingetreten und wurde gesperrt.
+ Der Übergang zur nächsten Phase ist deaktiviert.
Sie können einen Übergang deaktivieren, um eine eingehende Ausführung abzuhalten, wenn Sie kontrollieren möchten, ob eine aktuelle Ausführung Zeit hat, in nachfolgenden Phasen abgeschlossen zu werden, oder wenn Sie alle Aktionen an einem bestimmten Punkt beenden möchten. Um festzustellen, ob es sich um eine eingehende Ausführung handelt, können Sie sich die Pipeline in der Konsole oder die Ausgabe des Befehls ansehen. **get-pipeline-state**
Bei eingehenden Ausführungen sind die folgenden Überlegungen zu beachten:
+ Sobald die Aktions-, Übergangs- oder Sperrphase verfügbar ist, geht die laufende eingehende Ausführung in die Phase über und durchläuft die Pipeline.
+ Solange die eingehende Ausführung wartet, kann sie manuell gestoppt werden. Eine eingehende Ausführung kann den Status `InProgress``Stopped`, oder `Failed` haben.
+ Wenn eine eingehende Ausführung gestoppt wurde oder fehlgeschlagen ist, kann sie nicht erneut versucht werden, da es keine fehlgeschlagenen Aktionen gibt, die wiederholt werden könnten. Wenn eine eingehende Ausführung gestoppt wurde und der Übergang aktiviert ist, wird die gestoppte eingehende Ausführung nicht in der Phase fortgesetzt.
Sie können eine eingehende Ausführung anzeigen oder beenden.
# Eingabe- und Ausgabe-Artefakte
CodePipeline lässt sich in Entwicklungstools integrieren, um nach Codeänderungen zu suchen und anschließend in allen Phasen des Continuous Delivery-Prozesses für die Erstellung und Bereitstellung zu sorgen. Artefakte sind Dateien, die durch Aktionen in der Pipeline bearbeitet werden, z. B. Dateien oder Ordner mit Anwendungscode, Indexseitendateien, Skripts usw. Das Amazon S3 S3-Artefakt für die Quellaktion ist beispielsweise ein Dateiname (oder Dateipfad), in dem die Quellcodedateien der Anwendung für die Pipeline-Quellaktion bereitgestellt werden. Die Dateien werden als ZIP-Datei bereitgestellt, z. B. das folgende Beispiel für einen Artefaktnamen:. `SampleApp_Windows.zip` Das Ausgabeartefakt für die Quellaktion, die Quellcodedateien der Anwendung, sind das Ausgabeartefakt dieser Aktion und das Eingabeartefakt für die nächste Aktion, z. B. eine Build-Aktion. Ein weiteres Beispiel: Eine Build-Aktion könnte Build-Befehle ausführen, die den Anwendungsquellcode für ein Eingabeartefakt kompilieren, bei dem es sich um die Quellcodedateien der Anwendung handelt. Einzelheiten zu Artefaktparametern, z. B. für die Aktion, finden Sie auf der Referenzseite zur Aktionskonfiguration [AWS CodeBuild Aktionsreferenz zum Erstellen und Testen](action-reference-CodeBuild.md) für eine bestimmte Aktion. CodeBuild
Aktionen verwenden Eingabe- und Ausgabeartefakte, die in dem Amazon S3-Artefakt-Bucket gespeichert sind, den Sie bei der Erstellung der Pipeline ausgewählt haben. CodePipeline komprimiert und überträgt die Dateien für Eingabe- oder Ausgabeartefakte entsprechend dem Aktionstyp in der Phase.
**Anmerkung**
Der Artefakt-Bucket ist nicht derselbe Bucket wie der Bucket, der als Speicherort der Quelldatei für eine Pipeline verwendet wird, in der S3 als Quellaktion ausgewählt wurde.
Beispiel:
1. CodePipeline löst die Ausführung Ihrer Pipeline aus, wenn ein Commit in das Quell-Repository erfolgt, und stellt das Ausgabeartefakt (alle zu erstellenden Dateien) aus dem **Source-Schritt** bereit.
1. Das Ausgabe-Artefakt (alle Dateien, die erstellt werden sollen) aus dem vorherigen Schritt wird als Eingabe-Artefakt in die Phase **Erstellen** aufgenommen. Ein Ausgabe-Artefakt (die Build-Anwendung) aus der Phase **Build** kann eine aktualisierte Anwendung oder ein in einem Container erstelltes aktualisiertes Docker-Image sein.
1. Das Ausgabeartefakt aus dem vorherigen Schritt (die erstellte Anwendung) wird als Eingabeartefakt in die **Bereitstellungsphase** aufgenommen, z. B. für Staging- oder Produktionsumgebungen in der. AWS Cloud Sie können Anwendungen für die Bereitstellungsflotte bereitstellen, oder Sie können Container-basierte Anwendungen für in ECS-Clustern ausgeführte Aufgaben bereitstellen.
Wenn Sie eine Aktion erstellen oder bearbeiten, legen Sie das Eingabe- und Ausgabe-Artefakt oder die Eingabe- und Ausgabe-Artefakte für die Aktion fest. Beispiel: Für eine zweistufige Pipeline mit den Stufen „**Source**“ und „**Deploy**“ wählen Sie in **„Aktion bearbeiten“** den Artefaktnamen der Quellaktion für das Eingabeartefakt für die Bereitstellungsaktion aus.
+ Wenn Sie die Konsole verwenden, um Ihre erste Pipeline zu erstellen, CodePipeline erstellt in derselben einen Amazon S3 S3-Bucket AWS-Konto und AWS-Region speichert Artikel für alle Pipelines. Jedes Mal, wenn Sie die Konsole verwenden, um eine weitere Pipeline in dieser Region zu erstellen, CodePipeline wird im Bucket ein Ordner für diese Pipeline erstellt. Dieser Ordner wird zum Speichern von Artefakten für Ihre Pipeline verwendet, während der automatisierte Veröffentlichungsprozess ausgeführt wird. Dieser Bucket trägt den Namen codepipeline- *region* -. Dabei *region* handelt es sich um die AWS Region*12345EXAMPLE*, in der Sie die Pipeline erstellt haben. Er *12345EXAMPLE* ist eine 12-stellige Zufallszahl, die sicherstellt, dass der Bucket-Name eindeutig ist.
**Anmerkung**
Wenn Sie in der Region, in der Sie die Pipeline erstellen, bereits einen Bucket haben, der mit codepipeline- *region* — beginnt, CodePipeline wird dieser als Standard-Bucket verwendet. *Außerdem folgt er der lexikografischen Reihenfolge. Beispielsweise wird codepipeline- *region-abcexample vor codepipeline- region-defexample ausgewählt*.*
CodePipeline kürzt Artefaktnamen, was dazu führen kann, dass einige Bucket-Namen ähnlich aussehen. Auch wenn der Artefaktname gekürzt zu sein scheint, wird er dem CodePipeline Artefakt-Bucket auf eine Weise zugeordnet, die von Artefakten mit gekürzten Namen nicht beeinträchtigt wird. Die Pipeline kann normal ausgeführt werden. Dies ist kein Problem mit dem Ordner oder den Artefakten. Für Pipelinenamen besteht eine Längenbegrenzung auf 100 Zeichen. Auch wenn der Name des Artefaktordners gekürzt angezeigt wird, ist er für Ihre Pipeline eindeutig.
Wenn Sie eine Pipeline erstellen oder bearbeiten, müssen Sie einen Artefakt-Bucket in der Pipeline haben AWS-Konto und Sie müssen über einen Artefakt-Bucket pro Region verfügen AWS-Region, in der Sie eine Aktion ausführen möchten. Wenn Sie die Konsole verwenden, um eine Pipeline oder regionsübergreifende Aktionen zu erstellen, werden von CodePipeline in den Regionen, in denen Sie Aktionen haben, Standard-Artefakt-Buckets erstellt.
Wenn Sie die verwenden, AWS CLI um eine Pipeline zu erstellen, können Sie die Artefakte für diese Pipeline in einem beliebigen Amazon S3 S3-Bucket speichern, sofern sich dieser Bucket im selben AWS-Konto und AWS-Region wie die Pipeline befindet. Sie können dies tun, wenn Sie befürchten, die für Ihr Konto zulässigen Amazon S3 S3-Buckets zu überschreiten. Wenn Sie die verwenden, AWS CLI um eine Pipeline zu erstellen oder zu bearbeiten, und Sie eine regionsübergreifende Aktion hinzufügen (eine Aktion mit einem AWS Anbieter in einer anderen Region als Ihrer Pipeline), müssen Sie für jede weitere Region, in der Sie eine Aktion ausführen möchten, einen Artefakt-Bucket bereitstellen.
+ Jede Aktion hat einen Typ. Je nach Typ kann die Aktion über eine oder beide der folgenden Arten von Artefakten verfügen:
+ Ein Eingabeartefakt, bei dem es sich um das Artefakt handelt, das die Aktion während ihrer Ausführung nutzt oder bearbeitet.
+ Ein Ausgabeartefakt, bei dem es sich um das Ergebnis der Aktion handelt.
Jedes Ausgabeartefakt in einer Pipeline muss einen eindeutigen Namen haben. Jedes Eingabeartefakt einer Aktion muss dem Ausgabeartefakt einer früheren Aktion in der Pipeline entsprechen. Dabei kann es sich um eine Aktion handeln, die unmittelbar vor der betreffenden Aktion in derselben Phase oder in einer früheren Phase ausgeführt wurde.
Ein Artefakt kann von mehr als einer Aktion bearbeitet werden.
# Wie funktionieren die Stufenbedingungen?
Für jede Bedingung, die eine Regel spezifiziert, wird die Regel ausgeführt. Schlägt die Bedingung fehl, ist das Ergebnis gültig. Die Phase führt das angegebene Ergebnis nur aus, wenn die Bedingung fehlschlägt. Optional geben Sie im Rahmen der Regel auch an, welche Ressourcen in bestimmten Fällen verwendet werden CodePipeline sollen. Die `CloudWatchAlarm` Regel verwendet beispielsweise eine CloudWatch Alarm-Ressource, um den Zustand zu überprüfen.
Eine Bedingung kann mehreren Regeln entsprechen, und jede Regel kann einen von drei Anbietern angeben.
Der allgemeine Ablauf zum Erstellen von Bedingungen sieht wie folgt aus.
1. Wählen Sie den Bedingungstyp aus den verfügbaren Zustandstypen unter CodePipeline. Verwenden Sie beispielsweise den Bedingungstyp Bei Erfolg, um eine Phase so einzurichten, dass nach Abschluss der Phase eine Reihe von Regeln verwendet werden kann, um Prüfungen durchzuführen, bevor Sie fortfahren.
1. Wählen Sie die Regel aus. Die `CloudWatchAlarm` Regel sucht beispielsweise nach Alarmen und verwendet EB, um nach einem vorkonfigurierten Alarmschwellenwert zu suchen. Wenn die Prüfung erfolgreich ist und der Alarm unter dem Schwellenwert liegt, kann die Phase fortgesetzt werden.
1. Konfigurieren Sie das Ergebnis, z. B. ein Rollback, das verwendet wird, wenn die Regel fehlschlägt.
Bedingungen werden für bestimmte Ausdruckstypen verwendet, und für jede dieser Bedingungen stehen spezifische Ergebnisoptionen wie folgt zur Verfügung:
+ **Teilnahme** — Die Bedingungen für die Durchführung von Prüfungen, die, wenn sie erfüllt sind, den Eintritt in eine Phase ermöglichen. Regeln stehen für die folgenden Ergebnisoptionen zur Verfügung: **Fehlgeschlagen** oder **Überspringen**
+ **Bei einem Fehler** — Die Bedingungen für die Durchführung von Prüfungen für die Phase, in der sie fehlschlägt. Regeln werden mit der folgenden Ergebnisoption aktiviert: **Rollback**
+ **Bei Erfolg** — Die Bedingungen für die Durchführung von Prüfungen für die erfolgreiche Phase. **Regeln stehen mit den folgenden Ergebnisoptionen zur Verfügung: **Rollback oder Fehlgeschlagen****
Das folgende Diagramm zeigt einen Beispielablauf für den Bedingungstyp Entry in CodePipeline. Bedingungen beantworten die Frage: Was soll passieren, wenn die Bedingung nicht erfüllt ist, was bedeutet, dass eine Regel fehlschlägt? Im folgenden Ablauf wird eine Eingabebedingung mit einer LambdaInvoke Regel und einer `CloudWatchAlarm` Regel konfiguriert. Wenn die Regel fehlschlägt, wird das konfigurierte Ergebnis, z. B. Fehlgeschlagen, aktiviert.
![\[Ein Beispiel für den Bedingungstyp Eintrag mit zwei konfigurierten Regeln, einer LambdaInvoke Regel und einer CloudWatchAlarm Regel.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/conditions-overview-entry.png)
Das folgende Diagramm zeigt einen Beispielablauf für den Bedingungstyp On Failure in CodePipeline. Bedingungen beantworten die Frage: Was soll passieren, wenn die Bedingung erfüllt ist, d. h. alle Regeln bestehen ihre Prüfungen? Im folgenden Ablauf wird die Bedingung Bei Ausfall mit einer LambdaInvoke Regel und einer `CloudWatchAlarm` Regel konfiguriert. Wenn die Regel erfolgreich ist, wird das konfigurierte Ergebnis, z. B. Fehlgeschlagen, aktiviert.
![\[Ein Beispiel für den Bedingungstyp On Failure mit zwei konfigurierten Regeln, einer Lambda-Regel und einer CloudWatchAlarm Regel.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/conditions-overview-onfailure.png)
Das folgende Diagramm zeigt einen Beispielablauf für den Bedingungstyp On Success in CodePipeline. Bedingungen beantworten die Frage: Was soll passieren, wenn die Bedingung erfüllt ist, d. h. alle Regeln bestehen ihre Prüfungen? Im folgenden Ablauf wird die Bedingung On Success mit einer `LambdaInvoke` Regel und einer `CloudWatchAlarm` Regel konfiguriert. Wenn die Regel erfolgreich ist, wird das konfigurierte Ergebnis, z. B. Fehlgeschlagen, aktiviert.
![\[Ein Beispiel für den Bedingungstyp On Success mit zwei konfigurierten Regeln, einer Lambda-Regel und einer CloudWatchAlarm Regel.\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/images/conditions-overview-onsuccess.png)
## Regeln für Stufenbedingungen
Wenn Sie Phasenbedingungen konfigurieren, wählen Sie aus vordefinierten Regeln aus und geben die Ergebnisse für die Regel an. Ein Bedingungsstatus lautet Fehlgeschlagen, wenn eine der Regeln in der Bedingung fehlgeschlagen ist, und Erfolgreich, wenn alle Regeln erfolgreich sind. Wie die Kriterien für die Bedingungen „Bei Fehler“ und „Bei Erfolg“ erfüllt werden, hängt vom Typ der Regel ab.
Im Folgenden finden Sie verwaltete Regeln, die Sie den Stufenbedingungen hinzufügen können.
+ Bedingungen können die **Befehlsregel** verwenden, um Befehle anzugeben, die die Regelkriterien für Bedingungen erfüllen. Weitere Informationen zu dieser Regel finden Sie unter[Befehle](rule-reference-Commands.md).
+ Bedingungen können die **AWS DeploymentWindow**Regel verwenden, um genehmigte Bereitstellungszeiten für die Zulassung einer Bereitstellung anzugeben. Die Kriterien für die Regel werden anhand eines bereitgestellten Cron-Ausdrucks für ein Bereitstellungsfenster gemessen. Die Regel ist erfolgreich, wenn Datum und Uhrzeit im Bereitstellungsfenster den Kriterien im Cron-Ausdruck für die Regel entsprechen. Weitere Informationen zu dieser Regel finden Sie unter. [DeploymentWindow](rule-reference-DeploymentWindow.md)
+ Bedingungen können die **AWS Lambda-Regel** verwenden, um nach Fehlerzuständen zu suchen, die von konfigurierten Lambda-Funktionen zurückgegeben wurden. Die Regel ist erfüllt, wenn die Prüfung das Ergebnis der Lambda-Funktion erhält. Ein Fehler der Lambda-Funktion erfüllt die Kriterien für die Bedingungen bei Ausfall. Weitere Informationen zu dieser Regel finden Sie unter[LambdaInvoke](rule-reference-LambdaInvoke.md).
+ Bedingungen können die **AWS CloudWatchAlarm**Regel verwenden, um nach Alarmen zu suchen, die anhand von CloudWatch Ereignissen konfiguriert wurden. Die Regel ist erfüllt, wenn die Prüfung den Alarmstatus OK, ALARM oder INSUFF\$1DATA zurückgibt. Für die Bedingungen Bei Erfolg erfüllen OK und INSUFFICIENT\$1DATA die Kriterien. ALARM erfüllt die Kriterien für die Bedingungen Bei Ausfall. Weitere Informationen zu dieser Regel finden Sie unter[CloudWatchAlarm](rule-reference-CloudWatchAlarm.md).
+ Bedingungen können die **VariableCheck**Regel verwenden, um eine Bedingung zu erstellen, bei der die Ausgabevariable mit einem angegebenen Ausdruck verglichen wird. Die Regel besteht die Prüfung, wenn der Variablenwert die Regelkriterien erfüllt, z. B. wenn der Wert gleich oder größer als eine angegebene Ausgabevariable ist. Weitere Informationen zu dieser Regel finden Sie unter[VariableCheck](rule-reference-VariableCheck.md).
# Arten von Pipelines
CodePipeline bietet die folgenden Pipeline-Typen, die sich in Eigenschaften und Preis unterscheiden, sodass Sie Ihre Pipeline-Funktionen und Kosten an die Anforderungen Ihrer Anwendungen anpassen können.
+ Pipelines vom Typ V1 haben eine JSON-Struktur, die Standardparameter auf Pipeline-, Stufen- und Aktionsebene enthält.
+ Pipelines vom Typ V2 haben dieselbe Struktur wie Pipelines vom Typ V1 und verfügen über zusätzliche Parameter für die Releasesicherheit und die Triggerkonfiguration.
Informationen zur Preisgestaltung für finden Sie CodePipeline unter [Preisgestaltung](https://aws.amazon.com/codepipeline/pricing/).
Auf der [CodePipeline Referenz zur Pipeline-Struktur](reference-pipeline-structure.md) Seite finden Sie Einzelheiten zu den Parametern in den einzelnen Pipeline-Typen. Informationen darüber, welcher Pipeline-Typ Sie wählen sollten, finden Sie unter[Welcher Pipeline-Typ ist der richtige für mich?](pipeline-types-planning.md).
# Welcher Pipeline-Typ ist der richtige für mich?
Der Pipeline-Typ wird durch die Eigenschaften und Funktionen bestimmt, die von jeder Pipeline-Version unterstützt werden.
Im Folgenden finden Sie eine Zusammenfassung der Anwendungsfälle und Merkmale, die für jeden Pipeline-Typ verfügbar sind.
****
| | Typ V1 | Typ V2 | Merkmale | | |
| --- | --- | --- | --- | --- | --- |
| Anwendungsfälle | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/pipeline-types-planning.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codepipeline/latest/userguide/pipeline-types-planning.html) |
| [Variablen auf Aktionsebene](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-variables.html) | Unterstützt | Unterstützt |
| [PARALLELER Ausführungsmodus](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#concepts-how-it-works-executions-parallel) | Nicht unterstützt | Unterstützt |
| [Variablen auf Pipeline-Ebene](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-pipeline-variables.html) | Nicht unterstützt | Unterstützt |
| [Ausführungsmodus QUEUED](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#concepts-how-it-works-executions-queued) | Nicht unterstützt | Unterstützt |
| [Rollback für Pipeline-Phasen](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-rollback.html) | Nicht unterstützt | Unterstützt |
| [Überschreibungen der Quellversion](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-trigger-source-overrides.html) | Nicht unterstützt | Unterstützt |
| [Bedingungen auf der Bühne](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-conditions.html) | Nicht unterstützt | Unterstützt |
| [Triggert und filtert Git-Tags, Pull-Requests, Branches oder Dateipfade](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-filter.html) | Nicht unterstützt | Unterstützt |
| [Die Aktion „Befehle“](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-Commands.html) | Nicht unterstützt | Unterstützt |
| [Eingabebedingungen mit Skip-Ergebnis erstellen](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-conditions.html#stage-conditions-entry-skip) | Nicht unterstützt | Unterstützt |
| [Konfigurieren Sie eine Phase für die automatische Wiederholung bei einem Fehler](https://docs.aws.amazon.com/codepipeline/latest/userguide/stage-retry.html#stage-retry-auto) | Nicht unterstützt | Unterstützt |
Informationen zur Preisgestaltung für finden Sie CodePipeline unter [Preisgestaltung](https://aws.amazon.com/codepipeline/pricing/).
Sie können ein Python-Skript erstellen und ausführen, um die potenziellen Kosten der Umstellung einer Pipeline vom Typ V1 auf eine Pipeline vom Typ V2 zu analysieren.
**Anmerkung**
Das folgende Beispielskript dient nur zu Demonstrations- und Evaluierungszwecken. Es ist kein Angebotstool und garantiert nicht die Kosten für Ihre tatsächliche Nutzung einer Pipeline vom Typ V2, und es beinhaltet auch keine Steuern, die möglicherweise anfallen könnten. Informationen zur Preisgestaltung für finden Sie CodePipeline unter [Preisgestaltung](https://aws.amazon.com/codepipeline/pricing/).
**Um ein Skript zu erstellen und auszuführen, mit dem Sie die Kosten für die Umstellung einer Pipeline vom Typ V1 auf eine Pipeline vom Typ V2 abschätzen können**
1. Laden Sie Python herunter und installieren Sie es.
1. Öffnen Sie ein Terminal-Fenster. Führen Sie den folgenden Befehl aus, um ein neues Python-Skript namens **PipelineCostAnalyzer.py** zu erstellen.
```
vi PipelineCostAnalyzer.py
```
1. Kopieren Sie den folgenden Code und fügen Sie ihn in das **PipelineCostAnalyzer.py-Skript** ein.
```
import boto3
import sys
import math
from datetime import datetime, timedelta, timezone
if len(sys.argv) < 3:
raise Exception("Please provide region name and pipeline name as arguments. Example usage: python PipelineCostAnalyzer.py us-east-1 MyPipeline")
session = boto3.Session(profile_name='default', region_name=sys.argv[1])
pipeline = sys.argv[2]
codepipeline = session.client('codepipeline')
def analyze_cost_in_v2(pipeline_name):
if codepipeline.get_pipeline(name=pipeline)['pipeline']['pipelineType'] == 'V2':
raise Exception("Provided pipeline is already of type V2.")
total_action_executions = 0
total_blling_action_executions = 0
total_action_execution_minutes = 0
cost = 0.0
hasNextToken = True
nextToken = ""
while hasNextToken:
if nextToken=="":
response = codepipeline.list_action_executions(pipelineName=pipeline_name)
else:
response = codepipeline.list_action_executions(pipelineName=pipeline_name, nextToken=nextToken)
if 'nextToken' in response:
nextToken = response['nextToken']
else:
hasNextToken= False
for action_execution in response['actionExecutionDetails']:
start_time = action_execution['startTime']
end_time = action_execution['lastUpdateTime']
if (start_time < (datetime.now(timezone.utc) - timedelta(days=30))):
hasNextToken= False
continue
total_action_executions += 1
if (action_execution['status'] in ['Succeeded', 'Failed', 'Stopped']):
action_owner = action_execution['input']['actionTypeId']['owner']
action_category = action_execution['input']['actionTypeId']['category']
if (action_owner == 'Custom' or (action_owner == 'AWS' and action_category == 'Approval')):
continue
total_blling_action_executions += 1
action_execution_minutes = (end_time - start_time).total_seconds()/60
action_execution_cost = math.ceil(action_execution_minutes) * 0.002
total_action_execution_minutes += action_execution_minutes
cost = round(cost + action_execution_cost, 2)
print ("{:<40}".format('Activity in last 30 days:'))
print ("| {:<40} | {:<10}".format('___________________________________', '__________________'))
print ("| {:<40} | {:<10}".format('Total action executions:', total_action_executions))
print ("| {:<40} | {:<10}".format('Total billing action executions:', total_blling_action_executions))
print ("| {:<40} | {:<10}".format('Total billing action execution minutes:', round(total_action_execution_minutes, 2)))
print ("| {:<40} | {:<10}".format('Cost of moving to V2 in $:', cost - 1))
analyze_cost_in_v2(pipeline)
```
1. Wechseln Sie im Terminal oder in der Befehlszeile zu den Verzeichnissen, in denen Sie das Analyzer-Skript erstellt haben.
Führen Sie in diesem Verzeichnis den folgenden Befehl aus, wobei *Region* der Ort ist, an AWS-Region dem Sie die V1-Pipelines erstellt haben, die Sie analysieren möchten. Sie können optional auch eine bestimmte Pipeline auswerten, indem Sie ihren Namen angeben:
```
python3 PipelineCostAnalyzer.py region --pipelineName
```
Führen Sie beispielsweise den folgenden Befehl aus, um das Python-Skript mit dem Namen **PipelineCostAnalyzer.py** auszuführen. In diesem Beispiel ist `us-west-2` die Region.
```
python3 PipelineCostAnalyzer.py us-west-2
```
**Anmerkung**
Dieses Skript analysiert alle V1-Pipelines in den angegebenen Pipelines, AWS-Region sofern Sie keinen bestimmten Pipeline-Namen angeben.
1. In der folgenden Beispielausgabe des Skripts sehen wir die Liste der Aktionsausführungen, die Liste der Aktionsausführungen, die für die Abrechnung in Frage kamen, die Gesamtlaufzeit dieser Aktionsausführungen und die geschätzten Kosten dieser Aktionen, die in einer V2-Pipeline ausgeführt wurden.
```
Activity in last 30 days:
| ___________________________________ | __________________
| Total action executions: | 9
| Total billing action executions: | 9
| Total billing action execution minutes: | 5.59
| Cost of moving to V2 in $: | -0.76
```
In diesem Beispiel steht der negative Wert in der letzten Zeile für den geschätzten Betrag, der durch die Umstellung auf Pipelines vom Typ V2 eingespart werden könnte.
**Anmerkung**
Bei der Skriptausgabe und den zugehörigen Beispielen, die Kosten und andere Informationen zeigen, handelt es sich lediglich um Schätzungen. Sie dienen nur zu Demonstrations- und Bewertungszwecken und garantieren keine tatsächlichen Einsparungen. Informationen zur Preisgestaltung für CodePipeline finden Sie unter [Preise](https://aws.amazon.com/codepipeline/pricing/).