Amazon CodeCatalyst ist nicht mehr offen für Neukunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter [Wie migriert man von CodeCatalyst](migration.md).
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.
# Workflow-Konzepte
Im Folgenden finden Sie einige Konzepte und Begriffe, die Sie kennen sollten, wenn Sie Ihren Code mit Workflows erstellen, testen oder bereitstellen CodeCatalyst.
## Workflows
Ein *Workflow* ist ein automatisiertes Verfahren, das beschreibt, wie Sie Ihren Code als Teil eines CI/CD-Systems (Continuous Integration and Continuous Delivery) erstellen, testen und bereitstellen. Ein Workflow definiert eine Reihe von Schritten oder *Aktionen*, die während einer Workflow-Ausführung ausgeführt werden sollen. Ein Workflow definiert auch die Ereignisse oder *Auslöser*, die den Start des Workflows auslösen. Um einen Workflow einzurichten, erstellen Sie mit dem [visuellen Editor oder dem YAML-Editor](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) der CodeCatalyst Konsole eine *Workflow-Definitionsdatei*.
**Tipp**
Um einen kurzen Überblick darüber zu erhalten, wie Sie Workflows in einem Projekt verwenden könnten, [erstellen Sie ein Projekt mit einem Blueprint](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Jeder Blueprint stellt einen funktionierenden Workflow bereit, den Sie überprüfen, ausführen und mit dem Sie experimentieren können.
## Workflow-Definitionsdateien
Eine *Workflow-Definitionsdatei* ist eine YAML-Datei, die Ihren Workflow beschreibt. Standardmäßig wird die Datei in einem `~/.codecatalyst/workflows/` Ordner im Stammverzeichnis Ihres [Quell-Repositorys](source-repositories.md) gespeichert. Die Datei kann die Erweiterung „.yml“ oder „.yaml“ haben, und die Erweiterung muss in Kleinbuchstaben geschrieben werden.
Weitere Informationen zur Workflow-Definitionsdatei finden Sie unter. [YAML-Workflow-Definition](workflow-reference.md)
## Aktionen
Eine *Aktion* ist der Hauptbaustein eines Workflows und definiert eine logische Arbeitseinheit oder Aufgabe, die während einer Workflow-Ausführung ausgeführt werden soll. In der Regel umfasst ein Workflow mehrere Aktionen, die nacheinander oder parallel ausgeführt werden, je nachdem, wie Sie sie konfiguriert haben.
Weitere Informationen zu Aktionen finden Sie unter[Workflow-Aktionen konfigurieren](workflows-actions.md).
## Aktionsgruppen
Eine *Aktionsgruppe* enthält eine oder mehrere Aktionen. Das Gruppieren von Aktionen in Aktionsgruppen hilft Ihnen dabei, Ihren Arbeitsablauf zu organisieren, und ermöglicht es Ihnen auch, Abhängigkeiten zwischen verschiedenen Gruppen zu konfigurieren.
Weitere Informationen zu Aktionsgruppen finden Sie unter[Gruppierung von Aktionen in Aktionsgruppen](workflows-group-actions.md).
## -Artefakte
Ein *Artefakt* ist das Ergebnis einer Workflow-Aktion und besteht in der Regel aus einem Ordner oder Archiv mit Dateien. Artefakte sind wichtig, weil sie es Ihnen ermöglichen, Dateien und Informationen zwischen Aktionen gemeinsam zu nutzen.
Weitere Informationen zu Artefakten finden Sie unter [Artefakte und Dateien zwischen Aktionen teilen](workflows-working-artifacts.md).
## Datenverarbeitung
*Compute* bezieht sich auf die Computing-Engine (CPU, Arbeitsspeicher und Betriebssystem), die CodeCatalyst zur Ausführung von Workflow-Aktionen verwaltet und gewartet wird.
Weitere Informationen zu Compute finden Sie unter[Konfiguration von Compute- und Runtime-Images](workflows-working-compute.md).
## Umgebungen
Eine CodeCatalyst *Umgebung*, nicht zu verwechseln mit einer [Entwicklungsumgebung](https://docs.aws.amazon.com/codecatalyst/latest/userguide/devenvironment.html), definiert das Ziel AWS-Konto und die optionale Amazon-VPC, mit der ein CodeCatalyst [Workflow](workflow.md) eine Verbindung herstellt. Eine Umgebung definiert auch die [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Workflow benötigt, um auf die AWS Dienste und Ressourcen innerhalb des Zielkontos zuzugreifen.
Sie können mehrere Umgebungen einrichten und ihnen Namen wie „Entwicklung“, „Test“, „Staging“ und „Produktion“ geben. Wenn Sie die Bereitstellung in diesen Umgebungen durchführen, werden Informationen zu den Bereitstellungen auf den Registerkarten CodeCatalyst **Bereitstellungsaktivität** und **Bereitstellungsziele** in der Umgebung angezeigt.
Weitere Informationen zu Umgebungen finden Sie unter[Einsatz in AWS-Konten und VPCs](deploy-environments.md).
## Tore
Ein *Gate* ist eine Workflow-Komponente, mit der Sie verhindern können, dass ein Workflow-Lauf fortgesetzt wird, sofern nicht bestimmte Bedingungen erfüllt sind. Ein Beispiel für ein Gate ist das **Genehmigungstor**, bei dem Benutzer eine Genehmigung in der CodeCatalyst Konsole einreichen müssen, bevor die Workflow-Ausführung fortgesetzt werden kann.
Sie können Gates zwischen Aktionssequenzen in einem Workflow oder vor der ersten Aktion (die unmittelbar nach dem Herunterladen der **Quelldatei** ausgeführt wird) hinzufügen. Sie können Gates auch nach der letzten Aktion hinzufügen, falls Sie dies benötigen.
Weitere Informationen zu Gates finden Sie unter[Gating eines Workflow-Laufs](workflows-gates.md).
## Berichte
Ein *Bericht* enthält Details zu Tests, die während einer Workflow-Ausführung durchgeführt werden. Sie können Berichte wie einen Testbericht, einen Bericht zur Codeabdeckung, einen Analysebericht zur Softwarezusammensetzung und einen statischen Analysebericht erstellen. Sie können einen Bericht verwenden, um ein Problem während eines Workflows zu beheben. Wenn Sie über viele Berichte aus mehreren Workflows verfügen, können Sie anhand Ihrer Berichte Trends und Fehlerraten anzeigen und so Ihre Anwendungen und Bereitstellungskonfigurationen optimieren.
Weitere Informationen zu Berichten finden Sie unter[Typen von Qualitätsberichten](test-workflow-actions.md#test-reporting).
## Ausführungen
Eine *Ausführung* ist eine einzelne Iteration eines Workflows. CodeCatalystFührt während eines Laufs die in der Workflow-Konfigurationsdatei definierten Aktionen aus und gibt die zugehörigen Protokolle, Artefakte und Variablen aus.
Weitere Informationen zu Läufen finden Sie unter[Einen Workflow ausführen](workflows-working-runs.md).
## Quellen
Eine *Quelle*, auch *Eingabequelle* genannt, ist ein Quell-Repository, mit dem eine [Workflow-Aktion](workflows-actions.md) eine Verbindung herstellt, um die Dateien abzurufen, die sie zur Ausführung ihrer Operationen benötigt. Beispielsweise kann eine Workflow-Aktion eine Verbindung zu einem Quell-Repository herstellen, um Anwendungsquelldateien für die Erstellung einer Anwendung abzurufen.
Weitere Informationen zu Quellen finden Sie unter [Quell-Repositorys mit Workflows verbinden](workflows-sources.md).
## Variablen
Eine *Variable* ist ein Schlüssel-Wert-Paar, das Informationen enthält, auf die Sie in Ihrem CodeCatalyst Amazon-Workflow verweisen können. Der Wertteil der Variablen wird bei der Ausführung des Workflows durch einen tatsächlichen Wert ersetzt.
Weitere Informationen zu Variablen finden Sie unter[Verwenden von Variablen in Workflows](workflows-working-with-variables.md).
## Workflow-Auslöser
Mit einem *Workflow-Trigger* oder einfach einem *Trigger* können Sie eine Workflow-Ausführung automatisch starten, wenn bestimmte Ereignisse eintreten, z. B. ein Code-Push. Möglicherweise möchten Sie Trigger so konfigurieren, dass Ihre Softwareentwickler Workflow-Läufe nicht manuell über die CodeCatalyst Konsole starten müssen.
Sie können drei Arten von Triggern verwenden:
+ **Push** — Ein Code-Push-Trigger bewirkt, dass ein Workflow-Lauf immer dann gestartet wird, wenn ein Commit übertragen wird.
+ **Pull-Request** — Ein Pull-Request-Trigger bewirkt, dass ein Workflow-Lauf immer dann gestartet wird, wenn ein Pull-Request entweder erstellt, überarbeitet oder geschlossen wird.
+ **Zeitplan** — Ein Zeitplan-Trigger bewirkt, dass ein Workflow-Lauf nach einem von Ihnen definierten Zeitplan gestartet wird. Erwägen Sie, einen Zeitplan-Trigger zu verwenden, um nächtliche Builds Ihrer Software auszuführen, sodass Ihre Softwareentwickler am nächsten Morgen mit der neuesten Version arbeiten können.
Sie können Push-, Pull-Request- und Schedule-Trigger einzeln oder in Kombination im selben Workflow verwenden.
Trigger sind optional. Wenn Sie keine konfigurieren, können Sie einen Workflow nur manuell starten.
Weitere Informationen zu Auslösern finden Sie unter [Automatisches Starten einer Workflow-Ausführung mithilfe von Triggern](workflows-add-trigger.md).