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.
Fonctionnement des exécutions de pipeline
Cette section fournit une vue d'ensemble de la manière dont CodePipeline traite un ensemble de modifications. 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. Pour de plus amples informations, veuillez consulter Définir ou modifier le mode d'exécution du pipeline.
-
Mode REMPLACÉ : une exécution plus récente peut remplacer une exécution plus 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 démarrer ou terminer. Cela nécessite le type de pipeline V2.
Important
Pour les pipelines en mode PARALLÈLE, la restauration des étapes n'est pas disponible. De même, les conditions de défaillance avec un type de résultat d'annulation ne peuvent pas être ajoutées à un pipeline en mode PARALLÈLE.
Démarrage des exécutions de pipeline
Vous pouvez démarrer une exécution lorsque vous modifiez votre code source ou démarrer 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 pipelines
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 ayant une CodeCommit source, le HEAD est cloné CodePipeline au moment où le commit est poussé. Par exemple, un commit est poussé, ce qui démarre le pipeline pour l'exécution 1. Au moment où un deuxième commit est poussé, 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 de plus amples informations, veuillez consulter 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 bucket source, ce qui démarre le pipeline pour l'exécution 1. Au moment où l'événement pour une deuxième mise à jour du bucket est créé, le pipeline pour l'exécution 2 démarre.
Note
Pour les pipelines en mode PARALLEL avec une source S3, quelle que soit la balise d'image qui a déclenché l'exécution, l'action source commencera toujours par la dernière balise d'image. Pour de plus amples informations, veuillez consulter CodeCommit ou les révisions de source S3 en mode PARALLÈLE peuvent ne pas correspondre à EventBridge l'événement.
-
Pour les pipelines ayant une source de connexions, comme vers Bitbucket, le HEAD est cloné par CodePipeline au moment où le commit est poussé. 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.
Fonctionnement des remplacements de source avec le transformateur EventBridge d'entrée
Vous pouvez utiliser des remplacements pour démarrer un pipeline avec un ID de révision source spécifique que vous fournissez pour l'exécution du pipeline. Par exemple, si vous souhaitez démarrer un pipeline qui traitera un ID de validation spécifique à partir de votre CodeCommit source, vous pouvez ajouter l'ID de validation en tant que remplacement lorsque vous démarrez votre pipeline.
Il existe quatre types de révision des sources pour revisionType :
-
COMMIT_ID -
IMAGE_DIGEST -
S3_OBJECT_VERSION_ID -
S3_OBJECT_KEY
Note
Pour les révisions de source COMMIT_ID et les IMAGE_DIGEST types de révisions, l'ID de révision source s'applique à tout le contenu du référentiel, dans toutes les branches.
Note
Pour les S3_OBJECT_VERSION_ID et S3_OBJECT_KEY types de révisions de source, l'un ou l'autre des types peut être utilisé indépendamment, ou ils peuvent être utilisés ensemble pour remplacer la source par un identifiant de version spécifique ObjectKey . PourS3_OBJECT_KEY, le paramètre de configuration AllowOverrideForS3ObjectKey doit être défini surtrue. Pour plus d'informations sur les paramètres de configuration des sources S3, consultezParamètres de configuration.
Vous pouvez spécifier des remplacements de source à l'aide du transformateur d'entrée. EventBridge Utilisez le transformateur d'entrée pour transmettre les données de l'une des manières suivantes :
-
Vous pouvez utiliser le transformateur d'entrée pour transmettre les données sous forme de paramètres JSON.
-
Vous pouvez utiliser le transformateur d'entrée pour transmettre les variables du pipeline.
Pour des exemples de transmission de données sous forme de paramètres JSONActions et ressources relatives aux sources Amazon ECR EventBridge, consultez, Connexion à la source Amazon S3 : actions qui utilisent EventBridge et AWS CloudTrail pour S3 et CodeCommit actions à la source et EventBridge pour CodeCommit.
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 de plus amples informations, veuillez consulter Arrêtez 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.
-
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.
-
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.
-
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).
-
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é.
-
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 évite d'éventuelles tâches défaillantes ou hors séquence dans votre pipeline. Lorsqu'une action est abandonnée dans CodePipeline, le fournisseur de l'action poursuit toutes les tâches liées à l'action. Dans le cas d'une 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 un échec de mise à jour.
À titre d'exemple d'actions abandonnées qui peuvent entraîner des tâches hors séquence, 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 Amazon S3. Amazon S3 ne reçoit aucune instruction pour 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 dont le travail n'a pas besoin d'être terminé avant de commencer une nouvelle exécution pour corriger un bogue.
Comment les exécutions sont traitées en mode SUPERSEDED
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 pour le 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.
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.
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 à la commutation entre les modes d'exécution, consultezDéfinir ou modifier le mode d'exécution du pipeline. Pour plus d'informations sur les quotas associés à des 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 dépassent pas les exécutions qui ont déjà commencé.
Les exécutions en attente se rassemblent aux points d'entrée des étapes verrouillées dans l'ordre dans lequel elles atteignent l'étape, formant une file d'exécutions en attente. 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 entrer. 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 pipeline en mode QUEUED sont exécutées. Par exemple, alors que le stage Source traite l'exécution 5, les exécutions des 6 et 7 forment la file d'attente #1 et attendent au point d'entrée de l'étape. La prochaine exécution dans la file d'attente sera traitée après le déverrouillage de l'étape.
Pour plus d'informations sur les considérations relatives à l'affichage et à la commutation entre les modes d'exécution, 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 démarrer. Il n'y a pas de files d'attente. Pour visualiser les exécutions parallèles dans le pipeline, utilisez la vue 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és et se déploie 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 à la commutation entre les modes d'exécution, 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 des canalisations
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 du 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 à la phase 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.
-
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é. Cela reprend l'exécution (il réessaie les actions qui ont échoué et, en cas de succès, continue dans le stage/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 un stage pour chaque environnement d'application Région AWS, chaque 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 de poursuivre. L'étape, la transition ou l'action suivante peut ne pas être disponible pour les raisons suivantes :
-
Une autre exécution est déjà entrée dans la phase suivante et l'a bloquée.
-
La transition pour passer à l'étape suivante est désactivée.
Vous pouvez désactiver une transition pour suspendre 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 consulter le résultat de la get-pipeline-state commande.
Les exécutions entrantes prennent en compte les 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étatInProgressStopped, 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é à recommencer. 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 consulter ou arrêter une exécution entrante.
