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

La modélisation et la configuration de votre processus de publication automatisé sont plus faciles si vous comprenez les concepts et les termes utilisés dans AWS CodePipeline. Voici quelques concepts à connaître au fur et à mesure de votre utilisation 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.

Étapes

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 phase de déploiement peut contenir une action de déploiement qui déploie du code vers un service informatique 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 de la section 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 appelée 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 plus d'informations, consultez 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 est FAILED et l'étape est déverrouillée. 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 rétablir une étape ayant échoué jusqu'à une exécution réussie précédente.

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. SUPERSEDEDest le mode d'exécution par défaut.

En SUPERSEDED mode, 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 QUEUED le mode PARALLEL or.

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

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 opérations d'étape et des informations sur les étapes verrouillées, consultezComment les exécutions sont traitées en SUPERSEDED mode.

Les statuts valides pour les étapes sont InProgressStopping, StoppedSucceeded, etFailed. Vous pouvez réessayer une étape qui a échoué, sauf si l'étape échouée ne peut pas être réessayée. Pour plus d'informations, consultez StageExecution. Vous pouvez revenir 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 d'échec, comme indiqué dansConfiguration de la restauration d'une étape. Pour plus d'informations, consultez 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 plus d'informations, consultez ActionExecution.

Types d'exécution

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

Pour les types standard, l'exécution possède un identifiant unique et est une exécution complète du pipeline. Un rollback de pipeline comporte une étape à annuler et une exécution réussie de l'étape en tant qu'exécution cible à laquelle revenir. L'exécution du pipeline cible est utilisée pour récupérer les révisions de la source et les variables pour que l'étape soit réexécutée.

Types d'action

Les types d'action 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 dans votre pipeline en fonction du type d'action, voirIntégrations avec les types CodePipeline d'action.

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'action dans CodePipeline, voirUtilisation des types d'action.

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 le résultat à une autre action pour un traitement ultérieur à l'aide du bucket d'artefacts du pipeline. CodePipeline copie les artefacts dans le magasin 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 de source. Pour GitHub et les CodeCommit référentiels, 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 une modification de version source.

Déclencheurs

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 de source d'un pipeline. Par exemple, les CloudWatch événements doivent être configurés avec des ressources d'événements d'Amazon CloudWatch auxquelles le pipeline ARN 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 dotés d'une action source CodeCommit ou S3. Les webhooks sont un type de déclencheur configuré pour les événements de référentiels 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 requêtes push ou pull. Vous pouvez filtrer les événements push du code sur les balises Git, les branches ou les chemins de fichiers. Vous pouvez filtrer les événements de pull request par événement (ouvert, mis à jour, fermé), par branche ou par chemin de fichier.

Pour plus d'informations sur les déclencheurs, consultez Démarrez un pipeline dans CodePipeline. Pour un didacticiel expliquant comment utiliser les balises Git comme déclencheurs pour votre pipeline, consultezTutoriel : utilisez 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 soit déclarées au niveau du pipeline, soit é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 d'exécution. 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 terminée avec succès. Pour de plus amples informations, veuillez consulter Référence aux variables.

Conditions

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

Il existe trois types de maladies. Les conditions d'entrée répondent à la question « Si les règles de la condition sont remplies, entrez dans l'étape ». La phase est verrouillée lorsque l'exécution entre dans la phase, puis les règles sont exécutées. Pour les conditions En cas d'échec, 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 pour vérifier la présence d'alarmes avant de poursuivre. Par exemple, une condition On Success peut entraîner l'annulation d'une étape réussie si la CloudWatchAlarm règle détecte des alarmes dans l'environnement de déploiement. Pour de plus amples informations, veuillez consulter Comment fonctionnent les conditions scéniques ?.

Règles

Les conditions utilisent une ou plusieurs règles préconfigurées qui exécutent et effectuent des vérifications qui activeront ensuite le résultat configuré lorsque la condition n'est pas remplie. Par exemple, le respect de toutes les règles d'une règle de condition d'entrée qui vérifie l'état des alarmes et les heures des fenêtres de déploiement permet de déployer une étape réussie une fois toutes les vérifications passées. Pour de plus amples informations, veuillez consulter Comment fonctionnent les conditions scéniques ?.