Tuning delle prestazioni della pipeline
Identifichi i colli di bottiglia e applichi tecniche avanzate per ottimizzare la velocità di esecuzione e il consumo di risorse dei workflow di GitHub Actions.
Tuning delle prestazioni della pipeline è una lezione CI/CD with GitHub Actions & DevOps Pipelines gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento CI/CD with GitHub Actions & DevOps Pipelines, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso CI/CD with GitHub Actions & DevOps Pipelines include 4 lezioni in totale.
Aumenti la velocità della pipeline
Benvenuto nel tuning delle prestazioni delle pipeline! Nello sviluppo moderno, pipeline CI/CD veloci sono fondamentali per ottenere feedback rapidi e utilizzare le risorse in modo efficiente.
Le pipeline lente fanno perdere tempo e denaro. In questa lezione apprenderà tecniche avanzate per identificare i colli di bottiglia e velocizzare significativamente i workflow di GitHub Actions.
Individuazione dei colli di bottiglia del workflow
Prima di ottimizzare, deve sapere *cosa* ottimizzare. GitHub Actions offre strumenti eccellenti per individuare i passaggi o i job più lenti.
- Interfaccia di GitHub: visualizzi i log delle esecuzioni del workflow. La vista della timeline mostra chiaramente quanto tempo ha richiesto ogni job e ogni passaggio.
- Riepiloghi dei job: cerchi i passaggi con durate insolitamente lunghe.
- Log delle action: i log dettagliati possono rivelare comandi o processi specifici che consumano più tempo.
Si concentri sui passaggi che richiedono costantemente più tempo.
Esecuzione parallela dei job indipendenti
Se alcune parti del workflow non dipendono l'una dall'altra, le esegua contemporaneamente! È un modo semplice ma efficace per ridurre il tempo complessivo di esecuzione.
Definisca più job di primo livello nel workflow. GitHub Actions li eseguirà in parallelo per impostazione predefinita, purché non specifichi dipendenze needs tra loro.
name: Parallel Jobs Example
on: [push]
jobs:
build-frontend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Frontend
run: echo "Building frontend..."
build-backend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Backend
run: echo "Building backend..."
Ottimizzazione dell'action di checkout
L'action actions/checkout recupera il codice del repository. Per i repository di grandi dimensioni o con una cronologia molto estesa, questa operazione può essere lenta. La ottimizzi:
- Clone superficiale: utilizzi
fetch-depth: 1per recuperare solo l'ultimo commit, risparmiando molto tempo nella maggior parte delle attività CI/CD. - Checkout parziale: se Le serve solo un sottoinsieme di file, valuti l'utilizzo del checkout parziale, anche se spesso è più complesso da configurare.
Eviti fetch-depth: 0 a meno che non sia assolutamente necessario, poiché scarica l'intera cronologia.
name: Optimized Checkout
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 1 # Only fetch the latest commit
- name: Run Build
run: echo "Code checked out and building..."
Riduzione delle dimensioni degli artefatti di build
Se il workflow carica o scarica artefatti, come binari compilati o report dei test, le loro dimensioni influiscono direttamente sulle prestazioni.
Per velocizzare il processo:
- Includa solo i file necessari: non carichi directory temporanee di build o log di cui non ha bisogno.
- Comprima gli artefatti: se possibile, comprima gli artefatti di grandi dimensioni prima di caricarli. L'action
actions/upload-artifactgestisce automaticamente la compressione, ma si assicuri che i file di origine siano ridotti al minimo.
Filtraggio dei percorsi per una maggiore efficienza
Non ogni modifica al codice deve attivare ogni job. Utilizzi il filtraggio dei percorsi per eseguire i job solo quando vengono modificati file pertinenti.
È particolarmente utile nei repository più grandi, dove una modifica alla documentazione non dovrebbe attivare una build completa del backend.
Specifichi paths o paths-ignore all'interno del trigger on del workflow.
name: Path Filter Example
on:
push:
paths:
- 'frontend/**'
- 'shared/**'
jobs:
build-frontend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Frontend
run: echo "Frontend files changed, building..."
Runner più veloci e allocazione delle risorse
Le macchine virtuali, ovvero i runner, che eseguono i workflow sono disponibili in diverse dimensioni e tipologie. Per le attività che richiedono molta CPU, un runner più potente può ridurre drasticamente il tempo di esecuzione.
- Runner più grandi ospitati da GitHub: GitHub offre runner più grandi, ad esempio
ubuntu-latest-xlarge, per i carichi di lavoro più impegnativi. - Runner self-hosted: se ha esigenze hardware molto specifiche o desidera ridurre al minimo la latenza di rete verso le risorse interne, i runner self-hosted possono essere ottimizzati in base ai Suoi requisiti precisi.
Strategie avanzate di caching
Il caching delle dipendenze, come i pacchetti npm o gli artefatti Maven, è essenziale. Vada oltre il caching di base con questi suggerimenti:
- Chiavi di cache granulari: utilizzi chiavi di cache più specifiche per evitare cache miss non necessari. Ad esempio, includa un hash di uno specifico file di lock e del sistema operativo.
- Più cache: non inserisca tutto in un'unica cache di grandi dimensioni. Cache separate per diversi tipi di dipendenze, ad esempio node_modules e pacchetti pip, possono migliorare il tasso di hit.
- Chiavi di ripristino: utilizzi
restore-keysper provare più chiavi di cache se quella principale non dà risultati, aumentando la probabilità di un hit parziale.
name: Advanced Caching
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Cache Node Modules
uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: | # Try less specific keys if primary misses
${{ runner.os }}-node-
- name: Install Dependencies
run: npm ci
Ottimizzi questo workflow
Consideri un workflow che esegue la build sia del codice frontend sia di quello backend. Attualmente viene eseguito in sequenza e il checkout recupera l'intera cronologia. Quali due modifiche ne migliorerebbero significativamente le prestazioni?
name: Inefficient Workflow
on: [push]
jobs:
build-all:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Frontend Deps
run: npm install
- name: Build Frontend
run: npm run build
- name: Install Backend Deps
run: pip install -r requirements.txt
- name: Build Backend
run: python setup.py build
Riepilogo: ottimizzare per la velocità
Ha appreso tecniche efficaci per ottimizzare i workflow di GitHub Actions!
- Identificare i colli di bottiglia: utilizzi l'interfaccia e i log di GitHub.
- Eseguire i job in parallelo: esegua contemporaneamente le attività indipendenti.
- Ottimizzare il checkout: utilizzi cloni superficiali.
- Ridurre gli artefatti: mantenga ridotte le dimensioni di upload e download.
- Filtrare i percorsi: esegua i job solo quando cambiano i file pertinenti.
- Utilizzare runner più veloci: scelga risorse del runner adeguate.
- Applicare un caching avanzato: utilizzi chiavi granulari e più cache.
Applicando queste strategie, può rendere le pipeline più veloci ed efficienti e risparmiare tempo e risorse preziosi.
Domande Frequenti
La lezione «Tuning delle prestazioni della pipeline» è gratuita?
Sì — il testo completo di «Tuning delle prestazioni della pipeline» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso CI/CD with GitHub Actions & DevOps Pipelines, passa a CoddyKit PRO. Il corso CI/CD with GitHub Actions & DevOps Pipelines include 4 lezioni in totale.
Cosa imparerò in «Tuning delle prestazioni della pipeline»?
Identifichi i colli di bottiglia e applichi tecniche avanzate per ottimizzare la velocità di esecuzione e il consumo di risorse dei workflow di GitHub Actions. Eserciti CI/CD with GitHub Actions & DevOps Pipelines con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare CI/CD with GitHub Actions & DevOps Pipelines?
Non è richiesta alcuna esperienza precedente. CI/CD with GitHub Actions & DevOps Pipelines su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «Tuning delle prestazioni della pipeline»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione CI/CD with GitHub Actions & DevOps Pipelines?
Sì. Ogni lezione CI/CD with GitHub Actions & DevOps Pipelines include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Metriche DORA e salute della CI/CD
- Tuning delle prestazioni della pipeline
- Tendenze future nell’automazione DevOps
- Ottimizzare i costi CI/CD e l'efficienza dei runner