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.
So funktionieren Pipeline-Ausführungen
Dieser Abschnitt bietet einen Überblick über die Art und Weise, wie eine Reihe von Änderungen CodePipeline verarbeitet wird. 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 zu steuern, wie jede Ausführung in der Pipeline abläuft. Weitere Informationen finden Sie unter Den Pipeline-Ausführungsmodus festlegen oder ändern.
-
Modus ERSETZT: Eine neuere Ausführung kann eine ältere überholen. Dies ist die Standardeinstellung.
-
WARTESCHLANGENMODUS: Die Ausführungen werden nacheinander in der Reihenfolge verarbeitet, in der sie in die Warteschlange gestellt wurden. Dies erfordert den Pipeline-Typ V2.
-
PARALLELMODUS: Im PARALLEL-MODUS werden Ausführungen gleichzeitig und unabhängig voneinander ausgeführt. Ausführungen warten nicht, bis andere Läufe abgeschlossen sind, bevor sie gestartet oder beendet werden. Dies erfordert den Pipeline-Typ V2.
Wichtig
Für Pipelines im PARALLELMODUS ist ein Stufen-Rollback nicht verfügbar. Ebenso können einer Pipeline im PARALLEL-Modus keine Fehlerbedingungen mit einem Rollback-Ergebnistyp hinzugefügt werden.
So werden Pipeline-Ausführungen gestartet
Sie können eine Ausführung starten, wenn Sie Ihren Quellcode ändern oder die Pipeline manuell starten. Sie können eine Ausführung auch über eine Amazon CloudWatch Events-Regel auslösen, die Sie planen. 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 Quellrevisionen bei Pipeline-Ausführungen verarbeitet werden
Für jede Pipeline-Ausführung, die mit Quellcodeänderungen (Quellrevisionen) beginnt, werden Quellrevisionen wie folgt bestimmt.
-
Bei Pipelines mit einer CodeCommit Quelle wird der HEAD in dem Moment geklont, CodePipeline in dem der Commit übertragen wird. Zum Beispiel wird ein Commit übertragen, wodurch die Pipeline für Ausführung 1 gestartet wird. In dem Moment, in dem ein zweiter Commit übertragen wird, wird dadurch die Pipeline für Ausführung 2 gestartet.
Anmerkung
Bei Pipelines im PARALLEL-Modus mit einer CodeCommit Quelle klont die Quellaktion den HEAD immer zu dem Zeitpunkt, zu dem er gestartet wird, unabhängig vom Commit, der die Pipeline-Ausführung ausgelöst hat. Weitere Informationen finden Sie unter CodeCommit oder Revisionen der S3-Quelle im PARALLELMODUS stimmen möglicherweise nicht mit dem Ereignis überein EventBridge.
-
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 dadurch 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 Revisionen der S3-Quelle im PARALLELMODUS stimmen möglicherweise nicht mit dem Ereignis überein EventBridge.
-
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.
So funktionieren Quellüberschreibungen mit dem EventBridge Eingangstransformator
Sie können Overrides verwenden, um eine Pipeline mit einer bestimmten Quell-Revisions-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 der Quellrevision fürrevisionType:
-
COMMIT_ID -
IMAGE_DIGEST -
S3_OBJECT_VERSION_ID -
S3_OBJECT_KEY
Anmerkung
Für die IMAGE_DIGEST Typen der Quellversionen COMMIT_ID und gilt die Quellrevisions-ID für den gesamten Inhalt des Repositorys in allen Zweigen.
Anmerkung
Bei den Quellrevisionen S3_OBJECT_VERSION_ID und S3_OBJECT_KEY kann jeder der Typen unabhängig voneinander verwendet werden, oder sie können zusammen verwendet werden, um die Quelle mit einer bestimmten ObjectKey VersionID zu überschreiben. Für S3_OBJECT_KEY AllowOverrideForS3ObjectKey muss der Konfigurationsparameter auf gesetzt werden. true Weitere Informationen zu S3-Quellkonfigurationsparametern finden Sie unterKonfigurationsparameter.
Sie können Quellü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 Verbindung zu Amazon S3-Quellaktionen herstellen, die EventBridge und verwenden AWS CloudTrail für S3 und CodeCommit Quellaktionen und EventBridge 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.
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.
-
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).
-
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.
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.
-
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).
-
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.
-
In der Verlaufsansicht ist der Ausführungsstatus Stopped (Beendet).
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 fehlgeschlagene oder nicht aufeinanderfolgende Aufgaben in Ihrer Pipeline vermeidet. Wenn eine Aktion abgebrochen wird CodePipeline, setzt der Aktionsanbieter alle Aufgaben im Zusammenhang mit der Aktion fort. Im Falle einer CloudFormation Aktion wird die Bereitstellungsaktion in der Pipeline abgebrochen, aber das Stack-Update kann fortgesetzt werden und zu einem fehlgeschlagenen Update führen.
Ein Beispiel für abgebrochene Aktionen, die dazu führen können, dass die Reihenfolge der Aufgaben nicht eingehalten wird: Wenn Sie eine große Datei (1 GB) über eine S3-Bereitstellungsaktion bereitstellen und Sie sich dafür entscheiden, die Aktion zu stoppen und abzubrechen, während die Bereitstellung bereits im Gange ist, wird die Aktion in Amazon S3 abgebrochen CodePipeline, aber fortgesetzt. Amazon S3 erhält keine Anweisung zum Abbrechen des Uploads. 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 mit Arbeiten abbrechen, die nicht abgeschlossen werden müssen, bevor Sie eine neue Ausführung zur Behebung eines Fehlers starten.
Wie werden Ausführungen im SUPERSEDED-Modus verarbeitet
Der Standardmodus für die Verarbeitung von Ausführungen ist der SUPERSEDED-Modus. 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.
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.
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.
Vorher: Ausführung 2 wartet zwischen den Phasen, während Ausführung 3 in Phase 1 eintritt. Nachher: Ausführung 3 beendet Stufe 1. Ausführung 2 wird durch Ausführung 3 ersetzt.
Weitere Hinweise zu Überlegungen beim Anzeigen und Umschalten zwischen Ausführungsmodi finden Sie unter. Den Pipeline-Ausführungsmodus festlegen oder ändern Weitere Hinweise zu Kontingenten mit Ausführungsmodi finden Sie unterKontingente in AWS CodePipeline.
Wie werden Ausführungen im QUEUED-Modus verarbeitet
Bei Pipelines im QUEUED-Modus werden Phasen gesperrt, während eine Ausführung verarbeitet wird. Wartende Ausführungen überholen jedoch nicht die Ausführung, die bereits gestartet wurde.
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, wird die Phase gesperrt, sodass keine anderen Ausführungen eintreten können. Dieses Verhalten bleibt dasselbe wie im SUPERSEDED-Modus. Wenn die Ausführung die Phase beendet hat, wird die Phase entsperrt und ist bereit für die nächste Ausführung.
Das folgende Diagramm zeigt, wie Phasen in einer Pipeline im QUEUED-Modus Ausführungen verarbeiten. Während beispielsweise der Source-Schritt Ausführung 5 verarbeitet, bilden die Ausführungen für 6 und 7 die Warteschlange #1 und warten am Schritteintrittspunkt. Die nächste Ausführung in der Warteschlange wird verarbeitet, nachdem die Stufe entsperrt wurde.
Weitere Informationen zu Überlegungen zum Anzeigen und Umschalten zwischen Ausführungsmodi finden Sie unter. Den Pipeline-Ausführungsmodus festlegen oder ändern Weitere Hinweise zu Kontingenten mit Ausführungsmodi finden Sie unterKontingente in AWS CodePipeline.
Wie werden Ausführungen im PARALLEL-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 beginnen. Es gibt keine Warteschlangen. Verwenden Sie die Ansicht des Ausführungsverlaufs, um parallele Ausführungen in der Pipeline anzuzeigen.
Verwenden Sie den PARALLEL-Modus in Entwicklungsumgebungen, in denen jede Funktion ihren eigenen Feature-Branch hat und für Ziele bereitgestellt wird, die nicht von anderen Benutzern gemeinsam genutzt werden.
Weitere Informationen zu Überlegungen zum Anzeigen und Umschalten zwischen Ausführungsmodi finden Sie unterDen Pipeline-Ausführungsmodus festlegen oder ändern. Weitere Hinweise zu Kontingenten mit Ausführungsmodi finden Sie unterKontingente in AWS CodePipeline.
Verwaltung des Pipeline-Ablaufs
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 eintreten. 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, wechselt eine eingehende Ausführung in die Phase 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 Genehmigung erteilt wird (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. Dadurch wird die Ausführung wieder aufgenommen (fehlgeschlagene Aktionen werden erneut versucht und, falls sie erfolgreich sind, in der fortgesetzt). stage/pipeline
-
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 Stufe 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.
Links: Gruppierung von zuammengehörenden Test-, Bereitstellungs- und Genehmigungsaktionen (empfohlen). Rechts: Zusammengehörende Aktionen in getrennten Phasen (nicht empfohlen).
So funktionieren eingehende Hinrichtungen
Eine eingehende Ausführung ist eine Ausführung, die darauf wartet, dass eine Phase, ein Übergang oder eine Aktion, die nicht verfügbar ist, verfügbar wird, bevor sie fortgeführt wird. Die nächste Phase, der nächste Übergang oder die nächste Aktion ist möglicherweise aus folgenden Gründen nicht verfügbar:
-
Eine andere Ausführung hat bereits die nächste Phase erreicht und sie gesperrt.
-
Der Übergang zur nächsten Stufe ist deaktiviert.
Sie können einen Übergang deaktivieren, um eine eingehende Ausführung abzuhalten, wenn Sie kontrollieren möchten, ob eine aktuelle Ausführung in nachfolgenden Phasen abgeschlossen werden kann, 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 müssen die folgenden Überlegungen beachtet werden:
-
Sobald die Phase „Aktion“, „Transition“ oder „Gesperrt“ verfügbar wird, tritt die laufende eingehende Ausführung in die Phase ein und durchläuft die Pipeline weiter.
-
Während die eingehende Ausführung wartet, kann sie manuell gestoppt werden. Eine eingehende Ausführung kann den Status
InProgress,Stopped, oderFailedhaben. -
Wenn eine eingehende Ausführung gestoppt wurde oder fehlgeschlagen ist, kann sie nicht wiederholt werden, da es keine fehlgeschlagenen Aktionen gibt, die erneut versucht 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 stoppen.
