Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →
Exécution distribuée des tâches (DTE)
Lerna accélère le temps moyen d'exécution de votre CI grâce à la mise en cache et à l'option --since. Mais aucune de ces fonctionnalités ne résout le scénario le plus défavorable. Lorsqu'une modification touche le cœur de votre repo et que toutes les tâches doivent être exécutées en CI, la seule façon d'améliorer les performances est d'ajouter des jobs d'agents supplémentaires et de paralléliser efficacement les tâches.
La méthode la plus évidente pour paralléliser consiste à répartir les tâches par type : exécuter tous les tests sur un job, toutes les builds sur un autre et les tâches de lint sur un troisième. Cette stratégie s'appelle le binning. Elle peut se complexifier si certaines tâches de test nécessitent des builds préalables, mais en supposant que vous trouviez une solution, une configuration typique ressemble au diagramme ci-dessous. Les tâches de test sont alors retardées jusqu'à la disponibilité des artefacts de build nécessaires, tandis que les builds et les lints démarrent immédiatement.
Le problème du binning est qu'il génère des temps d'inactivité sur un ou plusieurs jobs. L'exécution distribuée des tâches de Nx réduit cette inactivité au minimum en assignant chaque tâche individuelle à des jobs d'agents selon leur durée moyenne d'exécution. Nx garantit aussi l'ordre d'exécution correct et utilise un cache distribué pour fournir les artefacts des tâches précédentes à chaque job d'agent qui en a besoin.
Lorsque vous configurez l'exécution distribuée des tâches de Nx, votre graphe de tâches ressemblera davantage à ceci :
Non seulement le CI se terminera plus rapidement, mais l'expérience de débogage sera identique à une exécution sur un seul job. Cela grâce au cache distribué qui recrée tous les logs et artefacts sur le job principal.
Plus d'informations dans ce guide détaillé pour optimiser vos temps de CI dans les pires scénarios.
Configuration
Pour distribuer l'exécution de vos tâches, vous devez : (1) vous connecter à Nx Cloud et (2) activer la DTE dans votre workflow CI.
npx nx connect-to-nx-cloud
Configurer votre workflow CI
Chaque organisation gère ses pipelines CI/CD différemment, il est donc impossible de couvrir tous les cas. Cependant, les exemples suivants de configuration de la DTE pour la CLI Nx dans des fournisseurs populaires devraient vous donner une bonne base, et sont facilement adaptables aux commandes spécifiques de Lerna comme lerna run (au lieu de nx run-many ou nx affected) :
Notez que seules les opérations pouvant être mises en cache peuvent être distribuées, car elles doivent être rejouées sur le travail principal.
Pour plus de détails sur la configuration de la DTE, consultez ce guide.
Flux d'exécution CI
L'exécution distribuée fonctionne avec tout fournisseur CI. Vous lancez les jobs dans votre système, et Nx Cloud coordonne leur collaboration. Deux types de jobs sont nécessaires :
-
Un job principal contrôlant l'exécution
-
Plusieurs jobs d'agents exécutant réellement les tâches
Le flux du job principal :
# Coordinate the agents to run the tasks
- npx nx-cloud start-ci-run
# Run any commands you want here
- lerna run lint --since=main & lerna run test --since=main & lerna run build --since=main
# Stop any run away agents
- npx nx-cloud stop-all-agents
Le flux des jobs d'agents est très simple :
# Wait for tasks to execute
- npx nx-cloud start-agent
Le job principal reste similaire à une exécution sans distribution. La seule action requise est d'appeler npx nx-cloud start-ci-run au début et éventuellement npx nx-cloud stop-all-agents à la fin.
Les jobs d'agents exécutent des processus start-agent de longue durée pour les tâches associées au run CI. Leur configuration se limite à appeler npx nx-cloud start-agent. Ce processus persiste jusqu'à l'instruction d'arrêt de Nx Cloud.
Notez l'importance d'un environnement et d'un code source identiques entre le job principal et les jobs d'agents. Ils démarrent simultanément. Une fois le job principal terminé, tous les agents s'arrêtent.
Notez également qu'un agent Nx Cloud n'est pas une machine mais un processus de longue durée s'exécutant sur une machine. Autrement dit, Nx Cloud ne gère pas vos agents - vous devez le faire dans votre configuration CI (consultez les exemples CI ci-dessus).
Nx Cloud est un orchestrateur. Le travail principal indique à Nx Cloud ce que vous souhaitez exécuter, et Nx Cloud répartira ces tâches entre les agents. Nx Cloud déplacera automatiquement les fichiers d'un agent à un autre, et des agents vers le travail principal.
Le résultat final est que lorsque, par exemple, lerna run build --since=main se termine sur le travail principal, tous les artefacts de fichiers créés sur les agents sont copiés vers le travail principal, comme si le travail principal avait tout construit localement.
Exécution en parallèle
--concurrency est propagé aux agents. Par exemple, npx lerna run build --since=main --concurrency=3 --dte indique à Nx Cloud d'exécuter jusqu'à 3 cibles de build en parallèle sur chaque agent. Ainsi, si vous avez disons 10 agents, vous exécuterez jusqu'à 30 builds en parallèle sur l'ensemble des agents.
Vous devez également exécuter autant de commandes en parallèle que possible. Par exemple,
- lerna run lint --since=main
- lerna run test --since=main
- lerna run build --since=main
est moins efficace que
- lerna run lint --since=main & lerna run test --since=main & lerna run build --since=main
Cette dernière approche planifie les trois commandes simultanément, donc si un agent ne trouve rien à construire, il commencera à exécuter les tests et les vérifications de code. Le résultat est une meilleure utilisation des agents et un temps d'intégration continue plus court.