Tempo di lettura: 3 min.
Continua da QUI
Molti team che gestiscono pipeline CI/CD in ambienti cloud utilizzano anche container come Docker e sistemi di orchestrazione come Kubernetes. I container consentono applicazioni di packaging e shipping in modalità standard e portabili. I container rendono facile la scalabilità o lo snellimento di ambienti con carichi di lavoro variabili.
Ci sono molti approcci per usare i container, le infrastrutture come codice e le pipeline CI/CD insieme. È possibile esplorare le opzioni lavorando attraverso tutorial come Kubernetes con Jenkins o Kubernetes con Azure DevOps.
Le architetture di calcolo serverless presentano un’altra strada per il deploy e lo scaling delle applicazioni. In un ambiente serverless, l’infrastruttura è completamente gestita dal fornitore di servizi cloud e l’applicazione consuma risorse in base alla sua configurazione. Su AWS, ad esempio, le applicazioni serverless funzionano come funzioni Lambda e le distribuzioni possono essere integrate in una pipeline CI/CD Jenkins con un plug-in.
CI/CD consente un deploy più frequente del codice
Per riassumere, i pacchetti CI e i test del software costruiscono e avvertono gli sviluppatori se le loro modifiche non superano i test unitari. Il CD è l’automazione che fornisce le modifiche all’infrastruttura ed esegue ulteriori test.
Le pipeline CI/CD sono progettate per le aziende che vogliono migliorare le applicazioni frequentemente e richiedono un processo di delivery affidabile. L’ulteriore sforzo per standardizzare le build, sviluppare i test e automatizzare le distribuzioni è il processo di produzione per la distribuzione delle modifiche al codice. Una volta in funzione, consente ai team di concentrarsi sul processo di miglioramento delle applicazioni e meno sui dettagli del sistema di consegna agli ambienti informatici.
CI/CD è una best practice di sviluppo perché affronta il disallineamento tra gli sviluppatori che vogliono applicare le modifiche di frequente, con operazioni che vogliono applicazioni stabili. Con l’automazione in atto, gli sviluppatori possono applicare i cambiamenti con maggiore frequenza. I team operativi vedono una maggiore stabilità perché gli ambienti hanno configurazioni standard, ci sono test continui nel processo di consegna, le variabili ambientali sono separate dall’applicazione e le procedure di rollback sono automatizzate.
L’impatto dell’implementazione di pipeline CI/CD può essere misurato come indicatore di performance chiave di sviluppo (KPI). I KPI, come la frequenza di distribuzione, il tempo di risposta al cambiamento e il tempo medio di recupero (MTTR) da un incidente sono spesso migliorati quando si implementa un CI/CD con test continuo. Tuttavia, CI/CD è solo un processo che può guidare questi miglioramenti, e ci sono altri prerequisiti per migliorare le frequenze di implementazione.
Per iniziare a lavorare con CI/CD è necessario che i team di sviluppo e i team operativi collaborino su tecnologie, pratiche e priorità. I team devono sviluppare il consenso sui giusti approcci per la loro attività e le loro tecnologie in modo che, una volta che il CI/CD è in funzione, il team sia in grado di seguire le pratiche in modo coerente.
[hubspot type=form portal=7275494 id=613e0623-c3fa-498c-aedd-0d8b5531fa46]