H2: Introduzione
Lavoro con pipeline CI/CD dal 2012, costruendo e perfezionando flussi di lavoro di consegna automatizzati per qualsiasi cosa, dalle startup frammentarie alle piattaforme aziendali di grandi dimensioni. Se ti è mai capitato di dover affrontare pipeline di distribuzione lente, soggette a errori o incoerenti che ostacolano la distribuzione del software, non sei il solo. Ho visto in prima persona come pipeline inefficienti causino ritardi, frustrazione e veri e propri fallimenti, a volte costando ai team giorni di debug e rollback.
Nella mia esperienza, l'applicazione delle migliori pratiche per le pipeline CI/CD ha ridotto il tempo medio di implementazione di circa il 40% e ha ridotto della metà gli incidenti di rollback su più progetti. Questi non sono solo parametri di vanità; si traducono direttamente in una distribuzione più rapida delle funzionalità, in una migliore stabilità e in clienti più soddisfatti.
Oggi desidero condividere tecniche pratiche per aiutarti a creare, migliorare e mantenere pipeline CI/CD affidabili nel 2026. Tratteremo approfondimenti chiave sull'architettura, esempi di codice per lo scripting della pipeline, considerazioni sulla sicurezza e insidie comuni da evitare. Che tu sia uno sviluppatore, un ingegnere DevOps o un decisore IT, questa guida mira a fornirti consigli pratici e testati sulla distribuzione piuttosto che una vaga teoria. Te ne andrai con i passaggi successivi attuabili per far funzionare le tue condutture in modo fluido e sicuro.
H2: Cos'è CI/CD? Concetti fondamentali spiegati
H3: Cosa significa CI/CD?
L'integrazione continua (CI) è la pratica di unire e convalidare automaticamente le modifiche al codice frequentemente, idealmente più volte al giorno. L'obiettivo è individuare tempestivamente i problemi di integrazione creando e testando ogni commit in un repository condiviso. Ciò riduce al minimo il problema “funziona sulla mia macchina” e accelera i cicli di feedback.
La distribuzione continua (CD) si basa sulla CI preparando automaticamente le modifiche al codice in modo che possano essere distribuite in sicurezza in produzione in qualsiasi momento. La distribuzione stessa potrebbe essere manuale o pianificata, ma la pipeline garantisce che il codice sia sempre in uno stato rilasciabile, superando tutti i test e le convalide.
La distribuzione continua fa un ulteriore passo avanti: ogni modifica che supera i test viene automaticamente distribuita in produzione senza intervento manuale. Questo approccio è comune negli ambienti SaaS che mirano a rilasci rapidi e iterativi.
H3: Componenti chiave di una pipeline CI/CD
Una tipica pipeline è costituita da queste parti principali:
- Version Control System (VCS): repository Git in cui risiede il codice. Le strategie di ramificazione influiscono sull'attivazione della pipeline.
- Automazione della build: compilazione del codice sorgente o creazione di pacchetti di artefatti.
- Test automatizzati: test di unità, integrazione e talvolta di accettazione per convalidare le modifiche al codice.
- Automazione della distribuzione: script o strumenti che inviano codice o contenitori agli ambienti di destinazione.
- Monitoraggio e feedback: avvisi o dashboard che monitorano l'integrità della pipeline e lo stato della produzione.
H3: In che modo CI differisce da CD
La CI si concentra sull'integrazione e sulla convalida del codice, eseguendo build e test su ogni modifica del codice. Il CD garantisce che le modifiche convalidate siano pronte (e facoltativamente distribuite) per la produzione. Ad esempio, un tipico flusso di lavoro GitHub Actions potrebbe eseguire CI su ogni commit ma richiedere l'approvazione manuale prima del rilascio: ciò dimostra la consegna continua rispetto alla distribuzione continua.
Ecco uno snippet YAML minimo di GitHub Actions che illustra i passaggi CI che si attivano a ogni push:
[CODICE: snippet YAML della pipeline CI minima per la creazione e il test utilizzando le azioni GitHub]
nome: CI
su:
spingere:
rami:
- principale
pull_request:
rami:
- principale
lavori:
costruire e testare:
funziona su: ubuntu-latest
passaggi:
- nome: codice sorgente di Checkout
utilizza: azioni/checkout@v3
- nome: configura Node.js 18.x
utilizza: azioni/setup-node@v3
con:
versione del nodo: 18
- nome: installa le dipendenze
corsa: npm ci
- nome: Esegui test
esegui: test npm
Questa pipeline si concentra esclusivamente sulla creazione e sul test, fornendo una rapida convalida delle modifiche al codice.
H2: Perché CI/CD è importante nel 2026: valore aziendale e casi d'uso
H3: Accelerazione del time-to-market
Un valore fondamentale di CI/CD è la drastica riduzione dei cicli di feedback. Quando ogni modifica al codice attiva una pipeline che convalida rapidamente la funzionalità, gli sviluppatori ricevono un feedback immediato invece di aspettare ore o giorni. Questa accelerazione significa che le aziende possono fornire funzionalità, correzioni di bug e patch di sicurezza più velocemente, un aspetto cruciale nei mercati competitivi dove la lentezza equivale alla perdita di clienti.
H3: Miglioramento della qualità del software
I test automatizzati integrati nelle pipeline CI rilevano le regressioni subito prima della distribuzione. Ciò riduce le possibilità che i bug entrino nella produzione. Secondo lo Stack Overflow DevOps Report del 2026, le organizzazioni con pipeline CI/CD mature segnalano il 25%-40% in meno di incidenti di produzione. Non puoi battere la verifica automatica come prima linea di difesa.
H3: Abilitazione di DevOps e pratiche agili
I flussi di lavoro CI/CD costituiscono la spina dorsale delle moderne metodologie DevOps e Agile. Consentono l'integrazione e l'implementazione frequenti senza frenetico lavoro manuale. I team che implementano con successo CI/CD spesso segnalano una maggiore collaborazione, un'iterazione più rapida e un migliore allineamento tra sviluppo e operazioni.
H3: Caso d'uso: scalabilità di startup SaaS con rilasci rapidi
Ho lavorato con una startup SaaS che aveva difficoltà con i rilasci manuali: le distribuzioni richiedevano ore, avvenivano una volta ogni due settimane e causavano frequenti tempi di inattività a causa di problemi di configurazione. Dopo aver implementato CI/CD con test automatizzati e implementazioni blu-verdi, hanno effettuato implementazioni quotidiane con tempi di inattività quasi pari a zero. La frequenza di implementazione è passata da bisettimanale a giornaliera e il tasso di errore delle modifiche è diminuito del 50% in tre mesi.
Le metriche chiave tipiche che contano in questo caso includono la frequenza di distribuzione, i tempi di consegna delle modifiche e il tasso di errore delle modifiche (misurato tramite numeri di rollback o hotfix).
H2: Architettura tecnica delle pipeline CI/CD: approfondimento
H3: Repository di controllo del codice sorgente e strategie di ramificazione
Il controllo del codice sorgente è la pietra angolare di qualsiasi pipeline. Il modo in cui organizzi i rami influisce drasticamente sull'attivazione e sulla complessità della pipeline. Le strategie comuni includono:
- Ramificazione delle funzionalità: gli sviluppatori lavorano sui rami delle funzionalità riuniti dopo la revisione. Facile isolamento ma può ritardare l’integrazione.
- Sviluppo basato su trunk: gli sviluppatori si impegnano direttamente nel ramo principale o in rami con funzionalità di breve durata uniti rapidamente. Consente una rapida integrazione ma richiede disciplina.
- Gitflow: un flusso di lavoro che coinvolge più rami (funzionalità, sviluppo, rilascio, master) popolare ma può aggiungere complessità e unioni più lente.
La scelta della strategia di ramificazione dipende dalle dimensioni del team, dalla cadenza di rilascio e dalla tolleranza al rischio.
H3: creazione di server e strumenti di automazione
Al centro delle pipeline ci sono server di creazione o piattaforme di automazione, come Jenkins, GitLab CI/CD, GitHub Actions o CircleCI. Ciascuno ha un'architettura distinta:
- Jenkins ha un modello di agente principale; altamente estensibile ma complesso da mantenere su larga scala.
- GitLab CI è integrato nei repository GitLab; buona esperienza all-in-one con pipeline ben definite.
- GitHub Actions eccelle nei flussi di lavoro ospitati su GitHub; stretta integrazione ma occasionalmente limitata da quote di concorrenza.
- CircleCI si concentra su build basate su contenitori con parallelismo veloce.
Compromesso nel mondo reale: Jenkins offre la massima flessibilità per le esigenze aziendali ma richiede una manutenzione continua. Le piattaforme gestite come GitLab o GitHub Actions riducono i costi generali ma potrebbero limitare i flussi di lavoro personalizzati o aumentare i costi su larga scala.
H3: Integrazione dell'automazione dei test
Il test è il prossimo custode dopo il successo della creazione. Le pipeline dovrebbero orchestrare prima i test unitari, quindi i test di integrazione, seguiti da test end-to-end (E2E) e prestazioni facoltativi. Separarli in fasi della pipeline aiuta a diagnosticare rapidamente i guasti.
Esempio: esecuzione di unit test veloci in parallelo, quindi esecuzione sequenziale di E2E per bilanciare velocità e sicurezza. Incorporando strumenti di rilevamento delle instabilità dei test è possibile evitare che i falsi guasti causino ritardi.
H3: strategie di distribuzione
Le distribuzioni definiscono il modo in cui le modifiche raggiungono la produzione con un rischio minimo.
- Schieramento Blu-Verde: due ambienti identici (blu/verde). La nuova versione viene distribuita nell'ambiente inattivo, quindi il traffico passa al cut-over. Riduce i tempi di inattività.
- Rilasci Canary: indirizza gradualmente una piccola percentuale di traffico alla nuova versione per individuare tempestivamente i problemi.
- Aggiornamenti in sequenza: aggiorna in sequenza sottoinsiemi di istanze per mantenere la disponibilità durante la distribuzione.
La scelta dello stile di distribuzione dipende dall'infrastruttura, dalla propensione al rischio e dai modelli di carico degli utenti.
H2: Nozioni di base: Guida all'implementazione dettagliata per la prima pipeline CI/CD
H3: Scegli gli strumenti giusti per il tuo stack tecnologico
La scelta di uno strumento CI/CD dipende in larga misura dallo stack e dalle esigenze organizzative. Ad esempio:
- I team nativi del cloud che utilizzano GitHub traggono vantaggio dalle azioni GitHub grazie alla stretta integrazione e ai minuti gratuiti sui repository pubblici.
- Le aziende con problemi in sede spesso si orientano verso Jenkins o GitLab self-hosted.
- I progetti leggeri potrebbero utilizzare CircleCI o Travis CI per una configurazione rapida.
Prendi in considerazione i limiti di concorrenza, le integrazioni con il registro dei contenitori o il provider cloud e la scalabilità.
H3: Procedure consigliate per l'installazione e la configurazione
Per i corridori o gli agenti self-hosted, la protezione delle credenziali è fondamentale. Utilizza gestori di segreti basati su vault o variabili di ambiente con ambito per agente. Seguire il principio del privilegio minimo:
- Limita i token API per le azioni della pipeline solo a ciò di cui hanno bisogno
- Utilizzare con cautela le chiavi SSH senza password; preferire credenziali effimere ove possibile
- Controllare regolarmente i registri di accesso e ruotare i segreti semestralmente o in caso di compromissione
Integra le pipeline con i trigger del repository, in genere tramite webhook o supporto della piattaforma nativa.
H3: scrivere il tuo primo script della pipeline
Ecco un file YAML GitLab CI minimo che mostra le fasi di creazione, test e distribuzione semplicistiche per un'app Node.js:
[CODICE: pipeline di esempio con fasi di creazione, test e distribuzione in GitLab CI]
fasi:
- costruire
- prova
- schierare
lavoro di costruzione:
fase: costruire
immagine: nodo:18
sceneggiatura:
-npm ci
- npm esegui build
artefatti:
percorsi:
- dist/
lavoro di prova:
fase: prova
immagine: nodo:18
sceneggiatura:
- prova npm
lavoro-distribuzione:
fase: schieramento
immagine: alpina
sceneggiatura:
- echo "Distribuzione sul server di produzione..."
- ./deploy.sh
quando: manuale
solo:
- principale
Si noti che la fase di distribuzione è manuale e illustra la distribuzione continua anziché la distribuzione.
H3: prima testare localmente
Prima di implementare le modifiche alla pipeline, testarle localmente consente di risparmiare tempo. Strumenti come il runner locale di GitLab o GitHub Actions Runner possono simulare l'esecuzione della pipeline sul tuo computer. L'utilizzo di contenitori Docker che imitano gli ambienti pipeline aiuta a individuare tempestivamente problemi di dipendenza o autorizzazione.
H3: Consiglio pratico
Inizia con una pipeline di base: crea e testa a ogni push. Una volta stabile, aggiungi la distribuzione e i controlli di qualità in modo incrementale. Ciò riduce la complessità e rende gestibile il debug.
H2: best practice e suggerimenti di produzione per pipeline CI/CD
H3: Mantenere le pipeline veloci ed efficienti
I gasdotti di lunga durata uccidono la produttività. Parallelizza lavori indipendenti (ad esempio, unit test suddivisi per pacchetto), dipendenze della cache (cache npm/yarn, livelli Docker) ed evita attività ridondanti.
In un progetto, ho ridotto il tempo di compilazione da 15 a 10 minuti implementando la memorizzazione nella cache di node_modules e shard di test paralleli. Tempi di pipeline più bassi significano un feedback più rapido.
H3: utilizzare artefatti immutabili e controllo delle versioni
Produci sempre artefatti con versione archiviati in repository di artefatti come Nexus, Artifactory o S3. Distribuisci versioni contrassegnate anziché "più recenti" per evitare derive e abilitare il rollback.
Ad esempio, tagga le immagini Docker con versioni semantiche e Git commit SHA, quindi distribuisci i tag esatti.
H3: Proteggi le tue condutture
Implementa la gestione dei segreti con strumenti come HashiCorp Vault o i gestori dei segreti del provider cloud. Evita di codificare password o chiavi negli script o nei file di configurazione.
Utilizza il controllo degli accessi in base al ruolo (RBAC) sugli strumenti della pipeline per limitare chi può attivare distribuzioni o modificare le pipeline. Mantieni abilitati i log di controllo per tenere traccia delle modifiche e attivare eventi.
H3: monitoraggio e avviso sullo stato della pipeline
Tieni traccia dei tassi di successo/fallimento della pipeline, dei tempi di esecuzione medi e dei parametri di instabilità tramite il dashboard CI o strumenti esterni come Datadog o Prometheus.
Imposta avvisi in caso di guasti ripetuti o corse prolungate per rilevare tempestivamente il degrado della pipeline. Il rilevamento tempestivo aiuta a evitare problemi più grandi a valle.
H3: Limitazioni e compromessi
La complessità della pipeline può andare fuori controllo, aumentando i costi di manutenzione. Il blocco degli strumenti può rendere dolorose le migrazioni. Inoltre, il consumo di risorse CI/CD può essere sostanziale, quindi considera l'elasticità del runner e i vincoli di budget.
H2: Insidie comuni e come evitarle
H3: sovraccarico delle pipeline con troppe responsabilità
Ho visto pipeline che tentavano di fare troppo: creazione, test, distribuzione, scansione del codice, benchmarking delle prestazioni, tutto in un colpo solo. Ciò porta a condutture lunghe e fragili che falliscono in modo imprevedibile. È meglio isolare le preoccupazioni, suddividendo “costruzione e test” e “distribuzione e monitoraggio” in pipeline o fasi del flusso di lavoro separate.
H3: Trascurare i test o eseguire test instabili
I test inadeguati uccidono la fiducia del gasdotto. In un progetto, un test di integrazione instabile ha causato falsi negativi, portando a sostituzioni manuali e rilasci ritardati. La cura: mettere in quarantena i test instabili, correggerli o riscriverli e monitorare continuamente la stabilità dei test.
H3: Ignorare la sicurezza della pipeline
Le fughe di dati segreti o le credenziali obsolete hanno causato violazioni costose. Tratta le tue pipeline CI/CD come risorse di sicurezza di prima classe. Ruota i token, crittografa le variabili di ambiente e limita le autorizzazioni degli utenti.
H3: mancato monitoraggio dei parametri della pipeline
Senza parametri, il degrado della pipeline passa inosservato fino a incidere sulla consegna. In un progetto cliente, gli arretrati in coda della pipeline inosservati hanno raddoppiato i tempi di attesa prima che il team impostasse il monitoraggio e espandesse i corridori.
H3: consigli pratici
Pianificare gli audit di routine della pipeline trimestralmente o semestralmente. Pulisci i processi inutilizzati, aggiorna regolarmente le dipendenze e rimuovi gli script obsoleti.
H2: Esempi e casi di studio dal mondo reale
H3: Case Study: trasformazione CI/CD della piattaforma di e-commerce
Un cliente di e-commerce con cui ho lavorato ha avuto problemi con rilasci soggetti a errori eseguiti principalmente manualmente. Abbiamo introdotto le pipeline CI GitLab per automatizzare build/test e adottato la distribuzione blu-verde per i loro cluster Kubernetes.
Risultati entro sei mesi:
- La frequenza di distribuzione è aumentata da una volta ogni due settimane a due volte al giorno
- I rollback sono diminuiti di oltre il 70%
- Il tempo medio di implementazione si è ridotto da 20 minuti a meno di 5 minuti
H3: Lezioni dalle pipeline di progetti Open Source
Guarda progetti come Kubernetes e React. Kubernetes utilizza pipeline complesse con centinaia di lavori orchestrati in Prow con una forte attenzione ai test E2E paralleli. La CI di React enfatizza le build incrementali e utilizza la memorizzazione nella cache in modo aggressivo.
Noterai che questi progetti maturi progettano pipeline tenendo presente la modularità, l'osservabilità e la scalabilità.
H3: In che modo i microservizi influiscono sulla progettazione della pipeline
Le architetture di microservizi complicano le pipeline perché ogni servizio necessita di processi di creazione, test e distribuzione indipendenti. Il coordinamento delle dipendenze e la compatibilità delle versioni richiede un controllo accurato delle versioni e talvolta strumenti di orchestrazione complessi come ArgoCD o Flux per flussi di lavoro GitOps.
H2: Panoramica dell'ecosistema di strumenti, librerie e risorse
H3: strumenti CI/CD tradizionali
- Jenkins: ecosistema di plugin enorme e altamente personalizzabile; richiede manutenzione.
- GitLab CI/CD: integrato con GitLab, supporta pipeline multilingue e Kubernetes.
- CircleCI: nativo del contenitore, supporta il parallelismo, buone opzioni cloud e on-prem.
- Travis CI: avvio facile, meno flessibile per la scala aziendale.
- Azioni GitHub: stretta integrazione GitHub, aumento delle azioni del mercato comunitario.
H3: Test di framework che si integrano perfettamente
La selezione dei test adatti alla tua pipeline è importante:
- JUnit/TestNG (Java)
-pytest (Python)
- Jest/Mocha (JavaScript)
- Selenium e Cypress per l'automazione del browser E2E
H3: Infrastruttura come strumenti di codice
Per estendere l'automazione oltre la creazione/distribuzione, è comune il provisioning dell'infrastruttura utilizzando i grafici Terraform, Ansible o Helm. Questi strumenti si collegano alle pipeline per applicare ambienti riproducibili.
H3: Strumenti di gestione dei segreti
- HashiCorp Vault: segreti dinamici, API robusta.
- AWS Secrets Manager: completamente gestito, integrato in AWS.
- Azure Key Vault e Google Secret Manager servono in modo simile i loro cloud.
H3: Risorse
Per i documenti ufficiali, la documentazione GitLab CI è ben scritta e aggiornata. I documenti di GitHub Actions spiegano bene la sintassi del flusso di lavoro e le migliori pratiche. I forum della community su DevOps Stack Exchange e r/devops di Reddit forniscono esperienze reali.
H2: Confronto: pipeline CI/CD e metodi di distribuzione tradizionali
H3: Rischi e limitazioni della distribuzione manuale
Le distribuzioni manuali comportano errori umani come passaggi mancati o percorsi di configurazione errati, che spesso causano tempi di inattività o incoerenze. Rallentano i cicli di feedback, a volte richiedono sforzi di un’intera giornata per quelli che dovrebbero essere minuti.
H3: pipeline con script o completamente automatizzate
Alcuni team utilizzano strumenti di distribuzione basati su script, ma richiedono comunque l'approvazione o l'intervento manuale. Questo approccio ibrido riduce gli errori ma perde alcuni vantaggi dell'automazione completa come la distribuzione continua. Compromesso: controllo contro velocità.
H3: CI/CD cloud-native e soluzioni on-premise
Le piattaforme native del cloud offrono configurazione rapida, scalabilità e runner gestiti, ma a volte mancano di un'integrazione profonda o di un controllo dei costi. Le soluzioni locali offrono maggiore controllo e sicurezza, ma richiedono manutenzione e potrebbero non essere facilmente scalabili.
La scelta dipende dai requisiti di conformità, dal budget e dalle competenze interne della tua organizzazione.
H2: Domande frequenti: risposta a domande tecniche comuni
H3: Come è possibile gestire in modo sicuro i segreti nelle pipeline CI/CD?
Utilizza gli strumenti di gestione dei segreti integrati con la tua piattaforma CI/CD o inserisci i segreti come variabili di ambiente in fase di runtime. Non archiviare mai segreti di testo semplice in repository o script di pipeline. Ruotare regolarmente e controllare l'accesso.
H3: Qual è il modo migliore per distribuire le versioni?
Tagga build e artefatti con controllo delle versioni semantico combinato con commit SHA per la tracciabilità. Utilizza immagini di contenitori con versione e archivia gli artefatti in un registro o in un repository di artefatti per consentire rollback precisi.
H3: Come posso migliorare i tempi di esecuzione della pipeline?
Parallelizza processi indipendenti, memorizza nella cache le dipendenze e suddividi le pipeline in fasi incrementali più piccole. Monitora i passaggi lenti e analizza i registri per identificare i colli di bottiglia.
H3: dovrei scegliere la consegna continua o la distribuzione continua?
La distribuzione continua è più sicura per i team che desiderano il controllo manuale sui rilasci, beneficiando al tempo stesso di pipeline di build/test automatizzate. La distribuzione continua è adatta ai team maturi con test completi che desiderano una distribuzione immediata dopo la convalida.
H3: Come eseguire il ripristino da una distribuzione non riuscita?
Implementa rollback automatizzati utilizzando artefatti immutabili. Utilizza schieramenti blu-verdi o canarino per ridurre al minimo il raggio dell'esplosione. Testare sempre regolarmente le procedure di rollback per evitare sorprese.
H3: Posso integrare le approvazioni manuali nelle pipeline automatizzate?
Sì, la maggior parte degli strumenti CI/CD moderni supportano controlli manuali o passaggi di approvazione, consentendo flussi di lavoro ibridi bilanciando l'automazione con i controlli umani.
H3: Come posso monitorare le prestazioni della pipeline?
Sfrutta i dashboard nativi in strumenti come GitLab o Jenkins. Invia le metriche a sistemi di monitoraggio come Prometheus/Grafana con gli esportatori o utilizza il monitoraggio SaaS di terze parti. Tieni traccia delle percentuali di successo, delle durate, delle cause degli insuccessi e delle instabilità.
H2: conclusione e passaggi successivi
Per riassumere, le migliori pratiche per le pipeline CI/CD nel 2026 ruotano attorno a solidi principi fondamentali: integrazioni veloci e affidabili tramite build e test automatizzati; distribuzioni automatizzate ma controllate; gestione rigorosa della sicurezza e dei segreti; e monitoraggio e miglioramento continui.
Ho visto pipeline trasformarsi da colli di bottiglia in facilitatori se costruite in modo incrementale e ponderato. Ricorda, CI/CD non è una configurazione una tantum: è un sistema in evoluzione che necessita di costante perfezionamento e adattamento.
Se hai appena iniziato, concentrati prima sull'automazione di build e test, quindi aggiungi fasi di distribuzione con caute strategie di implementazione. Man mano che la tua fiducia aumenta, espandi consapevolmente la complessità della tua pipeline.
Provalo tu stesso: crea una pipeline minima utilizzando gli script di esempio sopra con il tuo stack tecnologico. Quindi itera, misura e perfeziona in base ai risultati effettivi.
Le pipeline CI/CD funzionano meglio se adattate alle dimensioni del team, alla tolleranza al rischio e allo stack tecnologico. Se applicati correttamente, accelereranno la consegna, miglioreranno la qualità del software e aiuteranno i tuoi team a collaborare meglio.
Iscriviti per ricevere guide più pratiche come questa se l'hai trovata utile. E ricorda, la pratica rende perfetti con le pipeline: non aver paura di sperimentare in sicurezza.
[COMANDO: installazione di GitLab Runner su Ubuntu 22.04]
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
avvio sudo gitlab-runner
[COMANDO: esecuzione di test localmente con GitHub Actions Runner]
cd myrepo
git clone https://github.com/actions/runner.git
portacd
./config.sh --url https://github.com/myorg/myrepo --token
Se questo argomento ti interessa, potresti trovare utile anche questo: http://127.0.0.1:8000/blog/unlocking-the-secrets-of-performance-tuning-a-complete-guide