Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
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.
# Configuration du comportement de mise en file d'attente des exécutions
Par défaut CodeCatalyst, sur Amazon, lorsque plusieurs flux de travail sont exécutés en même temps, ils sont placés en CodeCatalyst file d'attente et traités un par un, dans l'ordre dans lequel ils ont été démarrés. Vous pouvez modifier ce comportement par défaut en spécifiant un *mode d'exécution*. Il existe quelques modes d'exécution :
+ (Par défaut) Mode d'exécution en file d'attente : CodeCatalyst les processus s'exécutent un par un
+ Mode d'exécution remplacé : CodeCatalyst les processus s'exécutent un par un, les nouvelles exécutions remplaçant les anciennes
+ Mode d'exécution parallèle : CodeCatalyst les processus s'exécutent en parallèle
Pour plus d'informations sur les exécutions de flux de travail, consultez[Exécution d'un flux de travail](workflows-working-runs.md).
**Topics**
+ [À propos du mode d'exécution en file d'attente](#workflows-configure-runs-queued)
+ [À propos du mode d'exécution remplacé](#workflows-configure-runs-superseded)
+ [À propos du mode d'exécution parallèle](#workflows-configure-runs-parallel)
+ [Configuration du mode d'exécution](#workflows-configure-runs-configure)
## À propos du mode d'exécution en file d'attente
En *mode exécution en file* d'attente, les exécutions se produisent en série, les séries en attente formant une file d'attente.
Les files d'attente se forment aux points d'entrée des actions et des groupes d'actions. Vous pouvez donc avoir *plusieurs files d'attente dans le même flux de travail* (voir[Figure 1](#figure-1-workflow-queued-run-mode)). Lorsqu'une exécution en file d'attente entre dans une action, celle-ci est verrouillée et aucune autre exécution ne peut y entrer. Lorsque l'exécution se termine et quitte l'action, l'action est déverrouillée et prête pour la prochaine exécution.
[Figure 1](#figure-1-workflow-queued-run-mode)illustre un flux de travail configuré en mode d'exécution en file d'attente. Il contient les éléments suivants :
+ Sept cycles se frayent un chemin dans le flux de travail.
+ Deux files d'attente : une en dehors de l'entrée de la source d'entrée (**Repo:Main**) et une en dehors de l'entrée de l'action. **BuildTestActionGroup**
+ Deux blocs verrouillés : la source d'entrée (**Repo:main**) et le. **BuildTestActionGroup**
Voici comment les choses se dérouleront au fur et à mesure que le flux de travail terminera le traitement :
+ **Lorsque **Run-4d444** aura fini de cloner le référentiel source, il quittera la source d'entrée et rejoindra la file d'attente située derrière Run-3c333.** Ensuite, **RUN-5e555** entrera dans la source d'entrée.
+ Lorsque **Run-1a111** aura fini de créer et de tester, il quittera l'**BuildTestActionGroup**action et entrera dans l'action. **DeployAction** Ensuite, **Run-2b222** entrera dans l'action. **BuildTestActionGroup**
**Figure 1** : Un flux de travail configuré en « mode exécution en file d'attente »
![\[Un flux de travail configuré en « mode d'exécution en file d'attente »\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
Utilisez le mode d'exécution en file d'attente si :
+ **Vous souhaitez conserver une one-to-one relation entre les fonctionnalités et les exécutions. Ces fonctionnalités peuvent être regroupées lorsque vous utilisez le mode remplacé.** Par exemple, lorsque vous fusionnez la fonctionnalité 1 dans le commit 1, l'exécution 1 démarre, et lorsque vous fusionnez l'entité 2 dans le commit 2, l'exécution 2 démarre, etc. Si vous deviez utiliser le mode remplacé au lieu du mode en file d'attente, vos fonctionnalités (et vos validations) seront regroupées lors de l'exécution qui remplacera les autres.
+ **Vous souhaitez éviter les conditions de course et les problèmes inattendus qui peuvent survenir lors de l'utilisation du mode parallel**. Par exemple, si deux développeurs de logiciels, Wang et Saanvi, lancent des exécutions de flux de travail à peu près au même moment pour les déployer sur un cluster Amazon ECS, l'exécution de Wang peut lancer des tests d'intégration sur le cluster tandis que celle de Saanvi déploie un nouveau code d'application sur le cluster, ce qui entraîne l'échec des tests de Wang ou le test du mauvais code. Autre exemple, vous pouvez avoir une cible dépourvue de mécanisme de verrouillage, auquel cas les deux essais peuvent remplacer les modifications de l'autre de manière inattendue.
+ **Vous souhaitez limiter la charge** sur les ressources de calcul CodeCatalyst utilisées pour traiter vos exécutions. Par exemple, si votre flux de travail comporte trois actions, vous pouvez exécuter au maximum trois exécutions en même temps. L'imposition d'une limite au nombre d'exécutions pouvant être effectuées simultanément rend le débit d'exécution plus prévisible.
+ **Vous souhaitez limiter le nombre de demandes adressées à des services tiers** par le flux de travail. Par exemple, votre flux de travail peut comporter une action de génération qui inclut des instructions pour extraire une image de Docker Hub. [Docker Hub limite le nombre de pull requests](https://www.docker.com/increase-rate-limits) que vous pouvez effectuer à un certain nombre par heure et par compte, et vous serez bloqué si vous dépassez cette limite. L'utilisation du mode d'exécution en file d'attente pour ralentir votre débit d'exécution aura pour effet de générer moins de demandes à Docker Hub par heure, limitant ainsi les risques de verrouillages et d'échecs de compilation et d'exécution qui en résultent.
**Taille maximale de la file d'attente** : 50
Remarques sur la **taille maximale de la file d'attente** :
+ La taille maximale de la file d'attente fait référence au nombre maximum d'exécutions autorisées dans *toutes les files d'attente* du flux de travail.
+ Si une file d'attente dépasse 50 essais, la 51e et les suivantes sont supprimées. CodeCatalyst
**Comportement de défaillance** :
Si une exécution ne répond plus alors qu'elle est traitée par une action, les exécutions qui la suivent sont maintenues dans la file d'attente jusqu'à ce que l'action expire. Les actions expirent au bout d'une heure.
Si une exécution échoue dans le cadre d'une action, la première exécution en file d'attente qui la suit est autorisée à se poursuivre.
## À propos du mode d'exécution remplacé
Le mode d'*exécution remplacé est identique au mode* d'*exécution en file d'attente sauf* que :
+ Si une exécution en file d'attente rattrape une autre course de la file d'attente, la dernière remplace (remplace) la précédente, et la précédente est annulée et marquée comme « remplacée ».
+ En raison du comportement décrit dans le premier point, une file d'attente ne peut inclure qu'une seule exécution lorsque le mode d'exécution remplacé est utilisé.
En utilisant le flux de travail [Figure 1](#figure-1-workflow-queued-run-mode) comme guide, l'application d'un mode d'exécution remplacé à ce flux de travail entraînerait les résultats suivants :
+ **Run-7g777** **remplacerait les deux autres exécutions de sa file d'attente et serait la seule exécution restante dans la file \$11.** **Run-6f666** et **Run-5e555** seraient annulés.
+ **Run-3c333** **remplacerait **Run-2b222 et serait le seul run restant** dans la file d'attente \$12.** **Run-2b222 serait annulé**.
Utilisez le mode d'exécution remplacé si vous souhaitez :
+ meilleur débit qu'en mode file d'attente
+ encore moins de demandes adressées à des services tiers qu'en mode file d'attente ; cela est avantageux si le service tiers impose des limites de débit, comme Docker Hub
## À propos du mode d'exécution parallèle
En *mode d'exécution parallèle*, les exécutions sont indépendantes les unes des autres et n'attendez pas la fin des autres exécutions pour démarrer. Il n'y a pas de files d'attente et le débit d'exécution n'est limité que par la rapidité avec laquelle les actions du flux de travail sont effectuées.
Utilisez le mode d'exécution parallèle dans les environnements de développement où chaque utilisateur possède sa propre branche de fonctionnalités et effectue des déploiements sur des cibles qui ne sont pas partagées par d'autres utilisateurs.
**Important**
Si vous avez une cible partagée vers laquelle plusieurs utilisateurs peuvent effectuer un déploiement, telle qu'une fonction Lambda dans un environnement de production, n'utilisez pas le mode parallel, car cela pourrait entraîner des conditions de course. Une *situation de course* se produit lorsque des workflows parallèles tentent de modifier une ressource partagée en même temps, ce qui entraîne des résultats imprévisibles.
**Nombre maximum de courses en parallèle** : 1000 par CodeCatalyst espace
## Configuration du mode d'exécution
Vous pouvez définir le mode d'exécution sur queued, superseded ou parallel. La valeur par défaut est mise en file d'attente.
Lorsque vous passez du mode d'exécution en file d'attente ou remplacé au mode parallèle CodeCatalyst , vous annulez les exécutions mises en file d'attente et autorisez les exécutions en cours de traitement par une action à se terminer avant de les annuler.
Lorsque vous passez du mode d'exécution de parallel à un mode en file d'attente ou à un mode remplacé, CodeCatalyst toutes les exécutions parallèles en cours d'exécution sont terminées. Toutes les exécutions que vous démarrez après avoir changé le mode d'exécution en mode file d'attente ou remplacé utilisent le nouveau mode.
------
#### [ Visual ]
**Pour modifier le mode d'exécution à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. En haut à droite, sélectionnez **Propriétés du flux de travail**.
1. Développez le mode **Avancé**, puis sous **Mode d'exécution**, choisissez l'une des options suivantes :
1. **En file d'attente — voir** [À propos du mode d'exécution en file d'attente](#workflows-configure-runs-queued)
1. **Remplacé — voir** [À propos du mode d'exécution remplacé](#workflows-configure-runs-superseded)
1. **Parallèle** — voir [À propos du mode d'exécution parallèle](#workflows-configure-runs-parallel)
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour modifier le mode d'exécution à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Choisissez votre projet.
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Ajoutez la `RunMode` propriété, comme suit :
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
Pour plus d'informations, consultez la description de la `RunMode` propriété dans la [Propriétés de haut niveau](workflow-reference.md#workflow.top.level) section du[Définition du flux de travail YAML](workflow-reference.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------