Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →
Distribuzione dell'Esecuzione dei Task (DTE)
Lerna accelera i tempi medi della tua CI con la cache e il flag --since. Tuttavia, nessuna di queste funzionalità aiuta nello scenario peggiore. Quando viene modificato qualcosa al cuore del tuo repository e ogni task deve essere eseguito nella CI, l'unico modo per migliorare le prestazioni è aggiungere più job agent e parallelizzare efficientemente i task.
Il modo più ovvio per parallelizzare i task è suddividerli per tipo: eseguire tutti i test su un job, tutte le build su un altro e tutti i task di lint su un terzo. Questa strategia è chiamata binning. Ciò può diventare difficile se alcuni task di test hanno come prerequisiti task di build, ma supponendo che tu trovi un modo per gestirlo, una configurazione tipica può apparire come nel diagramma seguente. Qui i task di test vengono ritardati finché tutti gli artefatti di build necessari sono pronti, mentre i task di build e lint possono iniziare immediatamente.
Il problema dell'approccio binning è che si verificherà del tempo di inattività in uno o più job. La distributed task execution di Nx riduce questo tempo di inattività al minimo possibile assegnando ogni singolo task ai job agent in base al tempo medio di esecuzione del task. Nx garantisce inoltre che i task vengano eseguiti nell'ordine corretto e utilizza la cache distribuita per assicurarsi che gli artefatti di build dei task precedenti siano presenti su ogni job agent che ne ha bisogno.
Quando configuri la distributed task execution di Nx, il tuo grafo dei task apparirà più simile a questo:
Non solo la CI terminerà più velocemente, ma l'esperienza di debug sarà identica a quella che avresti eseguendo tutta la tua CI su un singolo job. Questo perché Nx utilizza la cache distribuita per ricreare tutti i log e gli artefatti di build sul job principale.
Trova maggiori informazioni in questa guida dettagliata per migliorare i tempi della tua CI nello scenario peggiore.
Configurazione
Per distribuire l'esecuzione dei tuoi task, devi (1) connetterti a Nx Cloud e (2) abilitare la DTE nel tuo flusso di lavoro di CI.
npx nx connect-to-nx-cloud
Configura il tuo flusso di lavoro di CI
Ogni organizzazione gestisce le proprie pipeline CI/CD in modo diverso, quindi non è possibile coprire ogni caso possibile. Tuttavia, i seguenti esempi di configurazione della DTE per la CLI di Nx in provider popolari ti daranno un buon punto di partenza e sono facilmente adattabili ai comandi specifici di Lerna come lerna run (invece di nx run-many o nx affected):
Nota: solo le operazioni memorizzabili nella cache possono essere distribuite perché devono essere riprodotte sul job principale.
Per maggiori dettagli sulla configurazione della DTE, consulta questa guida.
Flusso di Esecuzione nella CI
La distributed task execution funziona con qualsiasi provider di CI. Sei responsabile del lancio dei job nel tuo sistema di CI. Nx Cloud coordina poi il modo in cui questi job lavorano insieme. Dovrai creare due tipi diversi di job nel tuo sistema di CI.
-
Un job principale che controlla cosa verrà eseguito
-
Multipli job agent che eseguono effettivamente i task
Il flusso di esecuzione del job principale appare così:
# 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
Il flusso di esecuzione del job agent è molto semplice:
# Wait for tasks to execute
- npx nx-cloud start-agent
Il job principale appare più o meno come se non avessi utilizzato alcuna distribuzione. L'unica cosa che devi fare è invocare npx nx-cloud start-ci-run all'inizio e opzionalmente invocare npx nx-cloud stop-all-agents alla fine.
I job agent eseguono processi start-agent a lunga durata che eseguono tutti i task associati a una specifica esecuzione di CI. L'unica cosa che devi fare per configurarli è invocare npx nx-cloud start-agent. Questo processo continuerà a essere eseguito finché Nx Cloud non gli dice di terminare.
Nota: è importante che il job principale e i job agent abbiano lo stesso ambiente e lo stesso codice sorgente. Partono più o meno allo stesso tempo. E, una volta che il job principale è completato, tutti gli agenti verranno fermati.
È importante sottolineare che un agente Nx Cloud non è una macchina fisica ma un processo a lunga durata che viene eseguito su una macchina. In altre parole, Nx Cloud non gestisce i tuoi agenti - devi farlo nella tua configurazione CI (vedi gli esempi CI sopra).
Nx Cloud è un orchestratore. Il job principale dice a Nx Cloud cosa vuoi eseguire, e Nx Cloud distribuirà quei task tra gli agenti. Nx Cloud sposterà automaticamente i file da un agente all'altro, e dagli agenti al job principale.
Il risultato finale è che quando, ad esempio, lerna run build --since=main viene completato sul job principale, tutti gli artefatti di file creati sugli agenti vengono copiati sul job principale, come se il job principale avesse costruito tutto localmente.
Esecuzione in Parallelo
--concurrency viene propagato agli agenti. Ad esempio, npx lerna run build --since=main --concurrency=3 --dte dice a Nx Cloud di eseguire fino a 3 target di build in parallelo su ogni agente. Quindi se hai, diciamo, 10 agenti, eseguirai fino a 30 build in parallelo tra tutti loro.
Dovresti anche eseguire più comandi in parallelo che puoi. Per esempio,
- lerna run lint --since=main
- lerna run test --since=main
- lerna run build --since=main
è peggio di
- lerna run lint --since=main & lerna run test --since=main & lerna run build --since=main
Quest'ultimo pianificherà tutti e tre i comandi contemporaneamente, quindi se un agente non trova nulla da costruire, inizierà a eseguire test e lint. Il risultato è una migliore utilizzazione degli agenti e un tempo di CI più breve.