Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

CodePipeline concepts

Il est plus facile de modéliser et de configurer votre processus de publication automatisé si vous comprenez les concepts et les termes utilisés dans AWS CodePipeline. Voici quelques concepts à connaître lorsque vous utilisez CodePipeline.

Pour un exemple de DevOps pipeline, voirDevOps exemple de pipeline.

Les termes suivants sont utilisés dans CodePipeline :

Pipelines

Un pipeline est une structure de workflow qui décrit la progression des modifications logicielles d'un processus de publication. Chaque pipeline est constitué d'une série d'étapes.

Stages

Une étape est une unité logique que vous pouvez utiliser pour isoler un environnement et limiter le nombre de modifications simultanées dans cet environnement. Chaque étape contient des actions effectuées sur les artefactsde l'application. Votre code source est un exemple d'artefact. Une étape peut être une étape de construction, au cours de laquelle le code source est généré et les tests sont exécutés. Il peut également s'agir d'une étape de déploiement, où le code est déployé dans des environnements d'exécution. Chaque étape est constituée d'une série d'actions en série ou en parallèle.

Transitions

Une transition est le point où l'exécution d'un pipeline passe à l'étape suivante du pipeline. Vous pouvez désactiver la transition en entrée d'une étape pour empêcher des exécutions d'entrer dans cette étape, puis activer la transition pour permettre la poursuite des exécutions. Lorsque plusieurs exécutions arrivent à une transition désactivée, seule l'exécution la plus ancienne passe à l'étape suivante lorsque la transition est activée. Cela signifie que les exécutions plus récentes continuent de remplacer les exécutions en attente pendant que la transition est désactivée. Une fois la transition activée, l'exécution qui continue est l'exécution de remplacement.

Actions

Une action est un ensemble d'opérations effectuées sur le code d'application et configurées de manière à ce que les actions s'exécutent dans le pipeline à un point spécifié. Cela peut inclure des éléments tels qu'une action source à partir d'une modification de code, une action pour déployer l'application sur des instances, etc. Par exemple, une étape de déploiement peut contenir une action de déploiement qui déploie du code vers un service de calcul tel qu'Amazon EC2 ou. AWS Lambda

Les types CodePipeline d'action valides sont source buildtest,deploy,approval, etinvoke. Pour voir la liste des fournisseurs d'actions, consultez Fournisseurs d'actions valides dans CodePipeline.

Les actions peuvent être exécutées en série ou en parallèle. Pour plus d'informations sur les actions en série et en parallèle au cours d'une étape, consultez les runOrder informations relatives aux exigences relatives à la structure des actions.

Exécutions de pipeline

Une exécution est un ensemble de modifications publiées par un pipeline. Chaque exécution de pipeline est unique et possède son propre ID. Une exécution correspond à un ensemble de modifications, telles qu'une validation fusionnée ou une version manuelle de la dernière validation. Deux exécutions peuvent publier le même ensemble de modifications à des moments différents.

Un pipeline peut traiter plusieurs exécutions en même temps, alors qu'une étape de pipeline ne traite qu'une seule exécution à la fois. Pour ce faire, une étape est verrouillée pendant qu'elle traite une exécution. Deux exécutions de pipeline ne peuvent pas occuper la même étape en même temps. L'exécution en attente d'entrer dans la phase occupée est une exécution entrante. Une exécution entrante peut toujours échouer, être remplacée ou arrêtée manuellement. Pour plus d'informations sur le fonctionnement des exécutions entrantes, consultezComment fonctionnent les exécutions entrantes.

Les exécutions de pipeline parcourent les étapes du pipeline dans l'ordre. Les statuts valides pour les pipelines sont InProgress, Stopping, Stopped, Succeeded, Superseded et Failed.

Pour de plus amples informations, veuillez consulter PipelineExecution.

Exécutions arrêtées

L'exécution du pipeline peut être arrêtée manuellement afin que l'exécution du pipeline en cours ne se poursuive pas à travers le pipeline. Si elle est arrêtée manuellement, une exécution de pipeline affiche un statut Stopping jusqu'à ce qu'elle soit complètement arrêtée. Ensuite, elle affiche un statut Stopped. Un pipeline au statut Stopped peut faire l’objet d’une nouvelle tentative d’exécution.

Il existe deux manières d’arrêter l'exécution d'un pipeline :

Pour plus d'informations sur les cas d'utilisation pour arrêter une exécution et les détails de séquence pour ces options, veuillez consulter Arrêt des exécutions de pipeline.

Exécutions ayant échoué

Si une exécution échoue, elle s'arrête et ne parcourt pas complètement le pipeline. Son statut passe à la scène FAILED et la CodePipeline déverrouille. Une exécution plus récente peut récupérer et entrer dans l'étape déverrouillée, puis la verrouiller. Vous pouvez faire une nouvelle tentative pour l'exécution ayant échoué, sauf si celle-ci a été remplacée ou ne peut pas faire l'objet d'une nouvelle tentative. Vous pouvez revenir à une précédente exécution réussie d'une étape ayant échoué.

Modes d’exécution

Pour fournir l'ensemble de modifications le plus récent via un pipeline, les exécutions plus récentes passent et remplacent les exécutions moins récentes déjà exécutées via le pipeline. Lorsque cela se produit, l'exécution la moins récente est remplacée par la plus récente. Une exécution peut être remplacée par une exécution plus récente à un certain point. Ce point se situe entre les étapes. Le mode d'exécution par défaut est SUPERSEDED.

En mode SUPERSEDED, si une exécution attend d'entrer dans une phase verrouillée, une exécution plus récente peut la rattraper et la remplacer. L'exécution la plus récente attend alors que l'étape se déverrouille, et l'exécution remplacée s'arrête avec un statut SUPERSEDED. Lorsqu'une exécution de pipeline est remplacée, l'exécution est arrêtée et ne parcourt pas complètement le pipeline. À ce stade, vous ne pouvez plus relancer l'exécution remplacée. Les autres modes d'exécution disponibles sont le mode PARALLÈLE ou le mode QUEUED.

Pour plus d'informations sur les modes d'exécution et les étapes verrouillées, consultezComment les exécutions sont traitées en mode SUPERSEDED.

Opérations scéniques

Lorsqu'une exécution de pipeline passe par une étape, celle-ci est en train de terminer toutes les actions qu'elle contient. Pour plus d'informations sur le fonctionnement des étapes et des informations sur les étapes verrouillées, consultezComment les exécutions sont traitées en mode SUPERSEDED.

Les statuts valides pour les étapes sont InProgressStopping, StoppedSucceeded, etFailed. Vous pouvez réessayer une étape qui a échoué, sauf si la phase qui a échoué ne peut pas être réessayée. Pour de plus amples informations, veuillez consulter StageExecution. Vous pouvez revenir en arrière d'une étape à une exécution réussie précédente spécifiée. Une étape peut être configurée pour revenir automatiquement en arrière en cas de panne, comme indiqué dansConfiguration de la restauration des étapes. Pour de plus amples informations, veuillez consulter RollbackStage.

Exécutions d'actions

Une exécution d'action est le processus d'exécution d'une action configurée qui fonctionne sur des artefacts désignés. Il peut s'agir d'artefacts en entrée, d'artefacts en sortie ou des deux. Par exemple, une action de build peut exécuter des commandes de build sur un artefact en entrée, comme la compilation du code source de l'application. Les détails d'une exécution d'action incluent un ID d'exécution d'action, le déclencheur source d'exécution du pipeline associé et les artefacts d'entrée et de sortie de l'action.

Les statuts valides pour les actions sontInProgress, AbandonedSucceeded, ouFailed. Pour de plus amples informations, veuillez consulter ActionExecution.

Types d'exécution

L'exécution d'un pipeline ou d'une étape peut être une exécution standard ou une exécution annulée.

Pour les types standard, l'exécution possède un identifiant unique et constitue une exécution complète du pipeline. Un rollback de pipeline comporte une étape à annuler et une exécution réussie pour cette étape en tant qu'exécution cible vers laquelle revenir en arrière. L'exécution du pipeline cible est utilisée pour récupérer les révisions des sources et les variables pour la phase à réexécuter.

Types d'action

Les types d'actions sont des actions préconfigurées qui peuvent être sélectionnées dans CodePipeline. Le type d'action est défini par son propriétaire, son fournisseur, sa version et sa catégorie. Le type d'action fournit des paramètres personnalisés qui sont utilisés pour effectuer les tâches d'action dans un pipeline.

Pour plus d'informations sur les Services AWS produits et services tiers que vous pouvez intégrer à votre pipeline en fonction du type d'action, consultezIntégrations avec les types CodePipeline d'actions.

Pour plus d'informations sur les modèles d'intégration pris en charge pour les types d'action dans CodePipeline, consultezRéférence du modèle d'intégration.

Pour plus d'informations sur la manière dont les fournisseurs tiers peuvent configurer et gérer les types d'actions dans CodePipeline, consultezUtilisation des types d'actions.

Artefacts

Les artefacts font référence à l'ensemble des données (code source de l'application, applications créées, dépendances, fichiers de définitions, modèles, etc.) utilisées par les actions de pipeline. Les artefacts sont produits par certaines actions et consommés par d'autres. Dans un pipeline, les artefacts peuvent être l'ensemble de fichiers utilisés par une action (artefacts d'entrée) ou la sortie mise à jour d'une action terminée (artefacts de sortie).

Les actions transmettent la sortie à une autre action pour un traitement ultérieur à l'aide du compartiment d'artefacts du pipeline. CodePipeline copie les artefacts dans la boutique d'artefacts, où l'action les récupère. Pour plus d'informations sur les artefacts, consultez Artefacts d'entrée et de sortie.

Révisions source

Lorsque vous modifiez le code source, une nouvelle version est créée. Une révision source est la version d'une modification de la source qui déclenche l'exécution d'un pipeline. Une exécution traite les révisions des sources. Pour les CodeCommit dépôts GitHub et les dépôts, il s'agit du commit. Pour les actions ou les compartiments S3, il s'agit de la version de l'objet.

Vous pouvez démarrer l'exécution d'un pipeline avec une révision de source, telle qu'un commit, que vous spécifiez. L'exécution traitera la révision spécifiée et remplacera la révision qui aurait été utilisée pour l'exécution. Pour de plus amples informations, veuillez consulter Démarrer un pipeline avec un remplacement de révision de la source.

Triggers

Les déclencheurs sont des événements qui démarrent votre pipeline. Certains déclencheurs, tels que le démarrage manuel d'un pipeline, sont disponibles pour tous les fournisseurs d'actions source d'un pipeline. Certains déclencheurs dépendent du fournisseur source d'un pipeline. Par exemple, les CloudWatch événements doivent être configurés avec des ressources événementielles d'Amazon CloudWatch dont l'ARN du pipeline a été ajouté en tant que cible dans la règle d'événement. Amazon CloudWatch Events est le déclencheur recommandé pour la détection automatique des modifications pour les pipelines avec une action source CodeCommit ou S3. Les webhooks sont un type de déclencheur configuré pour les événements du référentiel tiers. Par exemple, WebHookV2 est un type de déclencheur qui permet d'utiliser des balises Git pour démarrer des pipelines avec des fournisseurs de sources tiers tels que GitHub.com GitHub Enterprise Server GitLab.com, GitLab self-managed ou Bitbucket Cloud. Dans la configuration du pipeline, vous pouvez spécifier un filtre pour les déclencheurs, tels que les demandes push ou pull. Vous pouvez filtrer les événements de code push sur les balises Git, les branches ou les chemins de fichiers. Vous pouvez filtrer les événements de demande d'extraction en fonction de l'événement (ouvert, mis à jour, fermé), des branches ou des chemins de fichiers.

Pour plus d'informations sur les déclencheurs, consultez Démarrez un pipeline dans CodePipeline. Pour un didacticiel qui explique comment utiliser les balises Git comme déclencheurs pour votre pipeline, consultezTutoriel : Utiliser les balises Git pour démarrer votre pipeline.

Variables

Une variable est une valeur qui peut être utilisée pour configurer dynamiquement des actions dans votre pipeline. Les variables peuvent être déclarées au niveau du pipeline ou émises par des actions dans le pipeline. Les valeurs des variables sont résolues au moment de l'exécution du pipeline et peuvent être consultées dans l'historique des exécutions. Pour les variables déclarées au niveau du pipeline, vous pouvez soit définir des valeurs par défaut dans la configuration du pipeline, soit les remplacer pour une exécution donnée. Pour les variables émises par une action, la valeur est disponible une fois l'action exécutée avec succès. Pour de plus amples informations, veuillez consulter Référence des variables.

Conditions

Une condition contient un ensemble de règles qui sont évaluées. Si toutes les règles d'une condition réussissent, la condition est remplie. Vous pouvez configurer les conditions de sorte que lorsque les critères ne sont pas remplis, le résultat spécifié, tel que l'échec de l'étape, soit activé. Les conditions sont également appelées portes car elles vous permettent de spécifier quand une exécution entrera et traversera une étape ou quittera la phase après l'avoir parcourue. Cela revient à autoriser une ligne de circulation sur une route à se rassembler à une barrière fermée, puis à spécifier l'ouverture de la barrière pour permettre la circulation dans une zone. Les résultats pour les types de conditions incluent l'échec de l'étape ou l'annulation de la phase. Les conditions vous aident à spécifier à quel moment ces actions se produisent au cours d'une étape du pipeline. Vous pouvez modifier les conditions lors de l'exécution.

Il existe trois types de conditions. Les conditions d'entrée répondent à la question « Si les règles de la condition sont remplies, passez à l'étape ». L'étape est verrouillée lorsque l'exécution entre dans la phase, puis les règles sont exécutées. Pour les conditions On Failure, la règle s'active lorsqu'une étape échoue, ce qui entraîne l'annulation d'une étape échouée. Pour les conditions On Success, la règle s'active lorsqu'une étape est réussie, par exemple en vérifiant la réussite d'une exécution pour détecter les alarmes avant de continuer. Par exemple, une condition En cas de réussite entraîne l'annulation d'une étape réussie si la CloudWatchAlarm règle détecte la présence d'alarmes dans l'environnement de déploiement. Pour de plus amples informations, veuillez consulter Comment fonctionnent les conditions scéniques ?.

Rules

Les conditions utilisent une ou plusieurs règles préconfigurées qui s'exécutent et effectuent des vérifications qui activeront ensuite le résultat configuré lorsque la condition n'est pas remplie. Par exemple, si vous respectez toutes les règles relatives à une règle de condition d'entrée qui vérifie l'état de l'alarme et les délais de déploiement, une étape sera déployée avec succès une fois toutes les vérifications réussies. Pour de plus amples informations, veuillez consulter Comment fonctionnent les conditions scéniques ?.