Fonctionnement des exécutions de pipeline

Cette section fournit un aperçu de la manière dont CodePipeline un ensemble de modifications est traité. CodePipelinesuit chaque exécution de pipeline qui démarre lorsqu'un pipeline est démarré manuellement ou qu'une modification est apportée au code source. CodePipeline utilise les modes d'exécution suivants pour gérer la progression de chaque exécution dans le pipeline.

• Mode REMPLACÉ : une exécution plus récente peut remplacer une ancienne. Il s’agit de l’option par défaut.

• Mode FILE D'ATTENTE : les exécutions sont traitées une par une dans l'ordre dans lequel elles sont mises en file d'attente. Cela nécessite le type de pipeline V2.

• Mode PARALLÈLE : en mode PARALLÈLE, les exécutions s'exécutent simultanément et indépendamment les unes des autres. Les exécutions n'attendent pas la fin des autres exécutions pour commencer ou terminer. Cela nécessite le type de pipeline V2.

Démarrage des exécutions de pipeline

Vous pouvez démarrer une exécution en modifiant votre code source ou en démarrant manuellement le pipeline. Vous pouvez également déclencher une exécution via une règle Amazon CloudWatch Events que vous planifiez. Par exemple, lorsqu'une modification de code source est transmise à un référentiel configuré en tant qu’action source du pipeline, le pipeline détecte la modification et lance une exécution.

Note

Si un pipeline contient plusieurs actions source, elles sont toutes réexécutées même si une modification est détectée pour une seule action source.

Comment les révisions de source sont traitées dans les exécutions de pipeline

Pour chaque exécution de pipeline qui commence par des modifications du code source (révisions de source), les révisions de source sont déterminées comme suit.

• Pour les pipelines dotés d'une CodeCommit source, le HEAD est cloné CodePipeline au moment où le commit est envoyé. Par exemple, un commit est envoyé, ce qui démarre le pipeline pour l'exécution 1. Au moment où un deuxième commit est envoyé, cela démarre le pipeline pour l'exécution 2.

  Note

  Pour les pipelines en mode PARALLÈLE avec une CodeCommit source, quel que soit le commit qui a déclenché l'exécution du pipeline, l'action source clonera toujours le HEAD au moment de son démarrage. Pour plus d’informations, consultez CodeCommit ou les révisions de source S3 en mode PARALLÈLE peuvent ne pas correspondre à EventBridge l'événement .

• Pour les pipelines dotés d'une source S3, l' EventBridge événement de mise à jour du compartiment S3 est utilisé. Par exemple, l'événement est généré lorsqu'un fichier est mis à jour dans le compartiment source, ce qui lance le pipeline pour l'exécution 1. Au moment où l'événement pour une deuxième mise à jour du bucket est créé, cela démarre le pipeline pour l'exécution 2.

  Note

  Pour les pipelines en mode PARALLÈLE avec une source S3, quelle que soit la balise d'image qui a déclenché l'exécution, l'action de la source commence toujours par la dernière balise d'image. Pour plus d’informations, consultez CodeCommit ou les révisions de source S3 en mode PARALLÈLE peuvent ne pas correspondre à EventBridge l'événement .

• Pour les pipelines dotés d'une source de connexions, comme Bitbucket, le HEAD est cloné CodePipeline au moment où le commit est envoyé. Par exemple, pour un pipeline en mode PARALLÈLE, un commit est poussé, ce qui démarre le pipeline pour l'exécution 1, et la seconde exécution du pipeline utilise le second commit.

Arrêt des exécutions de pipeline

Pour utiliser la console pour arrêter l'exécution d'un pipeline, vous pouvez choisir Stop execution (Arrêter l'exécution) sur la page de visualisation du pipeline, sur la page de l’historique de l'exécution ou sur la page de l’historique détaillé. Pour utiliser l'interface de ligne de commande pour arrêter l'exécution d'un pipeline, utilisez la commande stop-pipeline-execution. Pour plus d’informations, consultez Arrêter l'exécution d'un pipeline dans CodePipeline.

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

• Arrêter et attendre : toutes les exécutions d'action en cours sont autorisées à se terminer et les actions suivantes ne sont pas démarrées. Les étapes suivantes du pipeline ne sont pas exécutées. Vous ne pouvez pas utiliser cette option sur une exécution déjà à l’état Stopping.

• Arrêter et abandonner : toutes les exécutions d'action en cours sont abandonnées et ne sont pas terminées, et les actions suivantes ne sont pas lancées. Les étapes suivantes du pipeline ne sont pas exécutées. Vous pouvez utiliser cette option sur une exécution déjà à l’état Stopping.

  Note

  Cette option peut entraîner des tâches défaillantes ou hors séquence.

Chaque option aboutit à une séquence différente de phases d'exécution de pipeline et d'action, comme suit.

Option 1 : Arrêter et attendre

Lorsque vous choisissez d'arrêter et d'attendre, l'exécution sélectionnée se poursuit jusqu'à ce que les actions en cours soient terminées. Par exemple, l'exécution du pipeline suivant a été arrêtée pendant que l'action de création était en cours.

1. Dans la vue du pipeline, la bannière de message de réussite s'affiche et l'action de création se poursuit jusqu'à ce qu'elle soit terminée. L’état d'exécution du pipeline est Stopping.

   Dans la vue de l’historique, l’état des actions en cours, telles que l'action de création, est In progress jusqu'à ce que l'action de création soit terminée. Pendant que les actions sont en cours, l'état de l'exécution du pipeline est Stopping.

2. L'exécution s'arrête lorsque le processus d'arrêt est terminé. Si l'action de création se termine avec succès, son état passe à Succeeded et l'exécution du pipeline affiche l’état Stopped. Les actions suivantes ne démarrent pas. Le bouton Retry (Réessayer) est activé.

   Dans la vue de l’historique, l’état de l'exécution est Stopped une fois que l'action en cours est terminée.

   

Option 2 : Arrêter et abandonner

Lorsque vous choisissez d'arrêter et d'abandonner, l'exécution sélectionnée n'attend pas la fin des actions en cours. Les actions sont abandonnées. Par exemple, l'exécution du pipeline suivant a été arrêtée et abandonnée pendant que l'action de création était en cours.

1. Dans la vue du pipeline, le message de bannière de réussite s'affiche, l'action de création affiche l'état In progress (En cours) et l'exécution du pipeline affiche l'état Stopping (En cours d’arrêt).

2. Après l'arrêt de l'exécution du pipeline, l'action de création affiche l’état Abandoned et l'exécution du pipeline affiche l’état Stopped. Les actions suivantes ne démarrent pas. Le bouton Retry (Réessayer) est activé.

3. Dans la vue de l’historique, l'état d'exécution est Stopped.

   

Cas d'utilisation pour arrêter l'exécution d'un pipeline

Nous vous recommandons d'utiliser l'option d'arrêt et d'attente pour arrêter l'exécution d'un pipeline. Cette option est plus sûre car elle permet d'éviter d'éventuels échecs ou out-of-sequence tâches dans votre pipeline. Lorsqu'une action est abandonnée dans CodePipeline, le fournisseur d'actions poursuit toutes les tâches liées à l'action. Dans le cas d'une AWS CloudFormation action, l'action de déploiement dans le pipeline est abandonnée, mais la mise à jour de la pile peut se poursuivre et entraîner l'échec de la mise à jour.

À titre d'exemple d'actions abandonnées pouvant entraîner des out-of-sequence tâches, si vous déployez un fichier volumineux (1 Go) par le biais d'une action de déploiement S3 et que vous choisissez d'arrêter et d'abandonner l'action alors que le déploiement est déjà en cours, l'action est abandonnée dans Amazon S3 CodePipeline, mais se poursuit dans celui-ci. Amazon S3 ne reçoit aucune instruction lui demandant d'annuler le téléchargement. Ensuite, si vous démarrez une nouvelle exécution de pipeline avec un très petit fichier, deux déploiements seront en cours. Étant donné la petite taille du fichier de la nouvelle exécution, le nouveau déploiement se termine alors que l'ancien déploiement est toujours en cours de téléchargement. Lorsque l'ancien déploiement se termine, le nouveau fichier est remplacé par l'ancien fichier.

Vous pouvez utiliser l'option d’arrêt et d’abandon dans le cas d’une action personnalisée. Par exemple, vous pouvez abandonner une action personnalisée avec un travail qu'il n'est pas nécessaire de terminer avant de commencer une nouvelle exécution pour corriger un bogue.

Comment les exécutions sont traitées en mode REMPLACÉ

Le mode par défaut pour le traitement des exécutions est le mode SUPERSEDED. Une exécution consiste en un ensemble de modifications collectées et traitées par l'exécution. Les pipelines peuvent traiter plusieurs exécutions en même temps. Chaque exécution est exécutée à travers le pipeline séparément. Le pipeline traite chaque exécution dans l'ordre et peut remplacer une exécution antérieure par une exécution plus récente. Les règles suivantes sont utilisées pour traiter les exécutions dans un pipeline en mode SUPERSEDED.

Règle 1 : les phases sont verrouillées lorsqu'une exécution est en cours de traitement

Une étape ne pouvant traiter qu'une seule exécution à la fois, elle est verrouillée lorsqu’elle est en cours. Lorsque l'exécution termine une étape, elle passe à l'étape suivante du pipeline.

Avant : Stage 1 is locked as Execution 1 enters. Après : Stage 2 is locked as Execution 1 enters.

Règle 2 : Les exécutions suivantes attendent le déverrouillage de l’étape

Lorsqu’une étape est verrouillée, les exécutions en attente sont conservées devant l’étape verrouillée. Toutes les actions configurées pour une étape doivent réussir avant que l'étape ne soit considérée comme étant achevée. Une défaillance libère le verrou sur l’étape. Lorsqu'une exécution est arrêtée, l'exécution ne se poursuit pas et la phase est déverrouillée.

Note

Avant d'arrêter une exécution, nous vous recommandons de désactiver la transition au début de la phase. De cette façon, lorsque la phase est déverrouillée en raison de l'arrêt de l’exécution, la phase n'accepte aucune exécution de pipeline ultérieure.

Avant : Stage 2 is locked as Execution 1 enters. Après : Execution 2 exits Stage 1 and waits between stages.

Règle 3 : Les exécutions en attente sont remplacées par des exécutions plus récentes

Les exécutions ne sont remplacées qu'entre les étapes. Une étape verrouillée conserve une exécution à l'avant de l’étape en attendant la fin de l’étape. Une exécution plus récente dépasse une exécution en attente et passe à l'étape suivante dès que l’étape est déverrouillée. L'exécution remplacée ne se poursuit pas. Dans cet exemple, l’exécution 2 a été remplacée par l’exécution 3 pendant l’attente de l’étape verrouillée. L'exécution 3 passe à l’étape suivante.

Avant : l'exécution 2 attend entre les étapes tandis que l'exécution 3 entre dans l'étape 1. Après : l'exécution 3 quitte l'étape 1 et l'exécution 2 est remplacée par l'exécution 3.

Pour plus d'informations sur les considérations relatives à l'affichage et au passage d'un mode d'exécution à un autre, consultezDéfinir ou modifier le mode d'exécution du pipeline. Pour plus d'informations sur les quotas avec modes d'exécution, consultezQuotas dans AWS CodePipeline.

Comment les exécutions sont traitées en mode QUEUED

Pour les pipelines en mode QUEUED, les étapes sont verrouillées lorsqu'une exécution est en cours de traitement ; toutefois, les exécutions en attente ne remplacent pas les exécutions déjà démarrées.

Les exécutions en attente se rassemblent aux points d'entrée des scènes verrouillées dans l'ordre dans lequel elles arrivent sur scène, formant une file d'attente d'exécutions. Avec le mode QUEUED, vous pouvez avoir plusieurs files d'attente dans le même pipeline. Lorsqu'une exécution en file d'attente entre dans une phase, celle-ci est verrouillée et aucune autre exécution ne peut y accéder. Ce comportement reste le même que celui du mode SUPERSEDED. Lorsque l'exécution termine l'étape, celle-ci est déverrouillée et prête pour la prochaine exécution.

Le schéma suivant montre comment les étapes d'un processus de pipeline en mode QUEUED s'exécutent. Par exemple, pendant que l'étape Source traite l'exécution 5, les exécutions des étapes 6 et 7 forment Queue #1 et attendent au point d'entrée de l'étape. La prochaine exécution de la file d'attente sera traitée une fois l'étape déverrouillée.

Pour plus d'informations sur les considérations relatives à l'affichage et au passage d'un mode d'exécution à un autre, consultezDéfinir ou modifier le mode d'exécution du pipeline. Pour plus d'informations sur les quotas avec modes d'exécution, consultezQuotas dans AWS CodePipeline.

Comment les exécutions sont traitées en mode PARALLÈLE

Pour les pipelines en mode PARALLÈLE, les exécutions sont indépendantes les unes des autres et n'attendez pas que les autres exécutions soient terminées pour commencer. Il n'y a pas de files d'attente. Pour visualiser les exécutions parallèles dans le pipeline, utilisez la vue de l'historique des exécutions.

Utilisez le mode PARALLÈLE dans les environnements de développement où chaque fonctionnalité possède sa propre branche de fonctionnalité et est déployée sur des cibles qui ne sont pas partagées par d'autres utilisateurs.

Pour plus d'informations sur les considérations relatives à l'affichage et au passage d'un mode d'exécution à un autre, consultezDéfinir ou modifier le mode d'exécution du pipeline. Pour plus d'informations sur les quotas avec modes d'exécution, consultezQuotas dans AWS CodePipeline.

Gestion du débit du pipeline

Le flux des exécutions de pipeline peut être contrôlé par :

• Une transition, qui contrôle le flux des exécutions dans l’étape. Les transitions peuvent être activées ou désactivées. Lorsqu'une transition est désactivée, les exécutions de pipeline ne peuvent pas entrer dans la phase. L'exécution du pipeline en attente d'entrer dans une phase où la transition est désactivée est appelée exécution entrante. Une fois que vous avez activé la transition, une exécution entrante passe dans la scène et la verrouille.

  Comme pour les exécutions en attente d'une étape verrouillée, lorsqu'une transition est désactivée, l'exécution en attente d'entrer dans l’étape peut toujours être remplacée par une nouvelle exécution. Lorsqu'une transition désactivée est réactivée, l’exécution la plus récente, y compris toute exécution ayant remplacé des anciennes exécutions pendant que la transition était désactivée, entre dans l’étape.

• Une action d'approbation, qui empêche un pipeline de passer à l'action suivante tant que l'autorisation n'est pas accordée (par exemple, par le biais d'une approbation manuelle à partir d'une identité autorisée). Vous pouvez utiliser une action d'approbation pour contrôler l'heure à laquelle un pipeline passe à une étape de production finale, par exemple.

  Note

  Une étape avec une action d'approbation est verrouillée jusqu'à ce que l'action d'approbation soit approuvée ou rejetée, ou qu’elle ait expiré. Une action d'approbation ayant expiré est traitée de la même manière qu'une action ayant échoué.

• Un échec, lorsqu’une action d'une étape n'aboutit pas. La révision ne passe pas à l'action suivante de l'étape ou à la prochaine étape du pipeline. Les événements suivants peuvent se produire :

  • Vous relancez manuellement l'étape qui contient les actions ayant échoué. L'exécution reprend (nouvelle tentative d’exécution des actions ayant échoué et, en cas de réussite, poursuite de l’étape ou du pipeline).

  • Une autre exécution entre dans l’étape ayant échoué et remplace l'exécution ayant échoué. À ce stade, l'exécution ayant échoué ne peut pas faire l’objet d’une nouvelle tentative.

Structure de pipeline recommandée

Lorsque vous décidez de la manière dont une modification de code doit circuler dans votre pipeline, il est préférable de regrouper les actions connexes au sein d'une étape de sorte que, lorsque l’étape se verrouille, les actions traitent toutes la même exécution. Vous pouvez créer une étape pour chaque environnement d'application Région AWS, ou zone de disponibilité, etc. Un pipeline avec trop d'étapes (c'est-à-dire, trop granulaire) peut autoriser un nombre de modifications simultanées trop important, tandis qu'un pipeline avec de nombreuses actions dans une étape volumineuse (trop « grossière ») peut prendre trop de temps pour publier une modification.

Par exemple, une action de test après une action de déploiement dans la même phase permet de s’assure que le test portera sur la modification qui a été déployée. Dans cet exemple, une modification est déployée dans un environnement de test, puis testée ; ensuite, la dernière modification de l'environnement de test est déployée dans un environnement de production. Dans l'exemple recommandé, l'environnement de test et l'environnement de production constituent des étapes distinctes.

Gauche : Actions associées au test, au déploiement et à l'approbation regroupées (recommandé). Droite : Actions associées dans des étapes distinctes (non recommandé).

Comment fonctionnent les exécutions entrantes

Une exécution entrante est une exécution qui attend qu'une étape, une transition ou une action non disponible soit disponible avant d'aller de l'avant. Il est possible que l'étape, la transition ou l'action suivante ne soit pas disponible pour les raisons suivantes :

• Une autre exécution est déjà entrée dans l'étape suivante et l'a verrouillée.

• La transition pour passer à l'étape suivante est désactivée.

Vous pouvez désactiver une transition pour bloquer une exécution entrante si vous souhaitez contrôler si une exécution en cours a le temps de se terminer lors des étapes suivantes, ou si vous souhaitez arrêter toutes les actions à un moment donné. Pour déterminer s'il s'agit d'une exécution entrante, vous pouvez consulter le pipeline dans la console ou le résultat de la get-pipeline-state commande.

Les exécutions entrantes fonctionnent en tenant compte des considérations suivantes :

• Dès que l'étape d'action, de transition ou de verrouillage devient disponible, l'exécution entrante en cours entre dans la phase et se poursuit dans le pipeline.

• Pendant que l'exécution entrante est en attente, elle peut être arrêtée manuellement. Une exécution entrante peut avoir un Failed état InProgressStopped, ou.

• Lorsqu'une exécution entrante a été arrêtée ou a échoué, elle ne peut pas être réessayée car aucune action n'a échoué. Lorsqu'une exécution entrante a été arrêtée et que la transition est activée, l'exécution entrante arrêtée ne se poursuit pas dans la phase.

Vous pouvez afficher ou arrêter une exécution entrante.