Ospitare il CI/CD nel cloud può accelerare le interazioni tra le pipeline di sviluppo e i repository di codice sorgente e semplificare la vita degli sviluppatori. Esiste un numero sorprendente di opzioni.
Se i vostri obiettivi sono lo sviluppo di software ad alta velocità e la frequente delivery di build funzionanti alla produzione, dovete automatizzare almeno una parte del processo di test e delivery. Ciò significa implementare pipeline CI/CD per i vostri progetti, insieme a suite di test per individuare gli errori prima che i clienti vedano il software e a script che implementano le fasi delle pipeline.
La Continuous integration (CI) è una metodologia per automatizzare la creazione, il confezionamento e i test del software in modo coerente. La CI aiuta a dare al team la certezza che le modifiche inserite nel controllo di versione del codice sorgente non interromperanno la compilazione o non introdurranno bug nel software. Il punto di arrivo del CI è tipicamente un check-in completato nel ramo principale di un repository software.
La Continuous delivery (CD) automatizza la consegna di software testato agli ambienti infrastrutturali. Di solito non significa effettuare il deploy direttamente in produzione. In genere, le organizzazioni iniziano inviando la build a un ambiente di sviluppo. Dopo che gli sviluppatori stessi hanno controllato la nuova build e l’hanno rilasciata, di solito viene trasferita in un ambiente di test, dove viene utilizzata da un gruppo più ampio di utenti (a volte solo da tester interni dedicati, a volte da un gruppo più ampio di utenti iscritti al beta testing o “dog-fooding”) e monitorata da vicino. Infine, se tutto va bene, i tester approvano e inviano la nuova versione all’ambiente di produzione.
In ogni fase del CD, ci sono opzioni per ritornare rapidamente a una build precedente e generare ticket di segnalazione di bug che gli sviluppatori dovranno risolvere nella nuova build. L’obiettivo è migliorare e potenziare continuamente il software senza introdurre regressioni. Un altro termine per definire queste pratiche è “devops”.
Perchè ospitare la CI/CD nel cloud?
Ospitare una piattaforma CI/CD nel proprio data center è un’opzione valida, soprattutto per le aziende che vogliono ospitare le proprie applicazioni e i propri dati all’interno del firewall. Lo svantaggio è che è necessario un team dedicato per la manutenzione dell’infrastruttura. Inoltre si dovranno sostenere alcune spese per l’acquisto dei server.
Se si ha la possibilità di utilizzare il cloud, di solito è un’opzione migliore. Il costo di gestione nel cloud è modesto e le spese operative sono compensate dai servizi forniti: onboarding, manutenzione dell’infrastruttura, manutenzione della sicurezza, assistenza e manutenzione del software CI/CD. Ospitare il software CI/CD nello stesso cloud spesso rende più facile e veloce l’interazione delle pipeline con i repository del codice sorgente. Se gli sviluppatori e i tester sono distribuiti geograficamente, il repository in cloud offre spesso agli sviluppatori un’esperienza migliore rispetto a risiedere in server remoti dietro firewall.
È anche possibile distribuire CI/CD in una infrastruttura ibrida con server on-premises e cloud. In uno scenario di distribuzione ibrida, è possibile posizionare ciascun componente dove ha più senso, in base alla posizione fisica degli sviluppatori stessi e alle posizioni di rete degli altri server dell’infrastruttura di sviluppo.
Gli strumenti CI/CD devono supportare i linguaggi e gli strumenti di programmazione in uso
Ogni linguaggio di programmazione o gruppo di linguaggi (linguaggi JVM, linguaggi compilati LLVM, linguaggi .NET e così via) tende ad avere i propri strumenti di compilazione e test. Per essere utile, uno strumento CI/CD deve supportare tutti i linguaggi che fanno parte di un determinato progetto. Altrimenti, potreste dover scrivere uno o più plug-in per lo strumento.
Le immagini Docker stanno diventando sempre più importanti per le distribuzioni di software distribuito, modulare e a microservizi. È molto utile se il vostro strumento CI/CD sa come gestire le immagini Docker, compresa la creazione di un’immagine dal codice sorgente e dai binari e la distribuzione in un ambiente specifico. Ancora una volta, in mancanza di questo, potreste dover scrivere plug-in o script per implementare le funzionalità Docker di cui avete bisogno. Allo stesso modo, è necessario che lo strumento CI/CD supporti Kubernetes e qualsiasi altro sistema di orchestrazione dei container utilizzato nei propri ambienti.
È possibile scegliere strumenti CI/CD diversi per progetti diversi
Sebbene si tende ad utilizzare sempre la stessa piattaforma CI/CD, non date per scontato che una sola piattaforma sia ottimale per tutti i progetti di sviluppo software. La maggior parte delle aziende utilizza diversi linguaggi di programmazione e ambienti e non tutte le piattaforme CI/CD li supportano bene.
L’approccio migliore è scegliere le piattaforme CI/CD che funziona meglio per ciascuno dei vostri progetti, piuttosto che utilizzare indistintamente un’unica piattaforma. I principi generali del CI e del CD sono applicabili da una piattaforma all’altra, anche se gli script non sono sempre portabili.
Dove sono i vostri attuali asset cloud?
Per ottimizzare una configurazione CI/CD basata su cloud (o qualsiasi applicazione cloud), è utile che tutte le risorse siano “vicine” tra loro. In questo contesto, “vicino” si riferisce in parte alla posizione geografica e in parte alla posizione della rete.
Ad esempio, se il vostro database si trova in Australia e la vostra applicazione in Nord America, avrete un forte ritardo ogni volta che l’applicazione deve leggere o scrivere dati. Su scala ridotta, se l’applicazione e il database si trovano nella stessa zona di disponibilità (AZ), la latenza tra loro sarà ridotta al minimo. Se si trovano in zone diverse della stessa regione, la latenza sarà maggiore, ma non così elevata come se si trovassero in regioni diverse.
Allo stesso modo, se il database si trova su Google Cloud Platform in Virginia e l’applicazione su Microsoft Azure in Virginia, la latenza sarà maggiore rispetto a quella che si avrebbe se entrambi si trovassero sullo stesso cloud provider nella stessa AZ. Tutto questo vale anche per il vostro repository (che è essenzialmente un database), il vostro software CI/CD, l’applicazione vera e propria e i vostri sviluppatori e tester. È utile che tutti siano “vicini”, anche se gli effetti del ritardo non sono così evidenti in questa situazione come lo sarebbero, ad esempio, per un gioco interattivo in tempo reale.
Se gli sviluppatori possono inserire i commit di codice nel repository master in modo affidabile e senza tempi di attesa degni di nota, di solito saranno soddisfatti. Allo stesso modo, se gli utenti e i tester sono abbastanza “vicini” all’applicazione da ottenere tempi di risposta inferiori al secondo, saranno anch’essi soddisfatti. Per il software CI/CD, la chiave è l’affidabilità delle connessioni ai punti di distribuzione. Un po’ di ritardo può essere tollerato, purché non causi time-out o cadute di pacchetti.
Prodotti cloud CI/CD
Esiste una vasta offerta di servizi basati sul cloud che supportano il devops. Di seguito elenco i principali prodotti cloud CI/CD maggiormente utilizzati.
AWS CodePipeline
AWS CodePipeline è un servizio di continuous delivery completamente gestito che aiuta ad automatizzare le pipeline di rilascio per aggiornamenti rapidi e affidabili di applicazioni e infrastrutture. CodePipeline automatizza le fasi di creazione, test e distribuzione del processo di rilascio ogni volta che viene apportata una modifica al codice, in base al modello di rilascio definito dall’utente. Ciò consente di fornire funzionalità e aggiornamenti in modo rapido e affidabile. È possibile integrare facilmente AWS CodePipeline con servizi di terze parti come GitHub o con un plugin personalizzato.
Azure DevOps
Azure DevOps fornisce servizi per sviluppatori che aiutano i team a pianificare il lavoro, a collaborare allo sviluppo del codice e a creare e distribuire applicazioni. È possibile lavorare nel cloud utilizzando Azure DevOps Services o on-premises utilizzando Azure DevOps Server. Azure DevOps fornisce funzionalità integrate a cui è possibile accedere tramite il browser web o il client IDE. Azure Pipelines fornisce servizi di build e release che supportano l’integrazione e la consegna continua. Altri servizi autonomi includono Azure Repos (controllo sorgente Git e Team Foundation), Agile Boards (una suite di strumenti Agile), Azure Test Plans (strumenti per test manuali/esplorativi e test continui) e Azure Artifacts (consente ai team di condividere pacchetti da registri pubblici e privati).
Google Cloud Build
Google Cloud Build è una piattaforma CI/CD completamente gestita e ospitata nel cloud che consente di eseguire le build su Google Cloud, su altri cloud pubblici e su sistemi on-premise, o esclusivamente all’interno della propria rete privata. È possibile creare pipeline come parte delle fasi di creazione per automatizzare le distribuzioni e distribuire utilizzando le integrazioni integrate con Google Kubernetes Engine, Google App Engine, Google Cloud Functions e Google Firebase. È possibile impostare dei trigger per costruire, testare o distribuire automaticamente il codice sorgente quando si inviano le modifiche a GitHub, a Google Cloud Source Repositories o a un repository Bitbucket. Cloud Build può essere utilizzato con Spinnaker per creare ed eseguire pipeline complesse.
Bitbucket Cloud
Bitbucket Cloud di Atlassian combina l’hosting e il controllo dei codici Git e una soluzione CI/CD integrata in Bitbucket Pipelines. Offre inoltre integrazioni con gli strumenti Jira (tracciamento delle funzionalità e dei problemi) e Trello (gestione dei progetti in stile Kanban) di Atlassian, offrendo ai team di sviluppo un luogo centrale per pianificare i progetti, collaborare sul codice, testare e distribuire.
CircleCI
CircleCI è in grado di automatizzare le build su più ambienti, sia basati su cloud che on-premise, si integra con GitLab, GitHub e Bitbucket e distribuisce su target che vanno da AWS, Azure e Google Cloud ad Artifactory e npm. È possibile scegliere tra migliaia di integrazioni esistenti o crearne di proprie, ottimizzare le build per la velocità ed eseguire lavori in parallelo e garantire che i progetti siano costruiti, distribuiti e mantenuti in modo sicuro. Gli ambienti di compilazione includono Docker, Linux (compresi gli emulatori Android), macOS, Windows, GPU e Arm.
GitHub Actions
GitHub Actions è una piattaforma di continuous integration e continuous delivery ospitata da GitHub che consente di automatizzare la pipeline di build, test e deployment. È possibile creare flussi di lavoro che costruiscono e testano ogni richiesta di pull del repository o distribuiscono le richieste di pull unite alla produzione. GitHub Actions consente anche di eseguire flussi di lavoro quando si verificano altri eventi nel repository. (Ad esempio, è possibile eseguire un flusso di lavoro per aggiungere automaticamente le etichette appropriate ogni volta che qualcuno crea un nuovo problema nel repository). GitHub mette a disposizione macchine virtuali Linux, Windows e macOS per l’esecuzione dei flussi di lavoro, oppure è possibile eseguirli nelle proprie macchine virtuali, nel cloud o on-premise, utilizzando runner self-hosted. GitHub Actions supporta Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET e Swift.
GitLab CI/CD
GitLab CI/CD è la parte di GitLab che potete utilizzare per tutti i metodi continui (continuous Integration, continuous delivery e continuous deployment). Con GitLab CI/CD, potete costruire, testare, distribuire e monitorare le vostre applicazioni, senza bisogno di applicazioni o integrazioni di terze parti. GitLab rileva automaticamente il linguaggio di programmazione e utilizza modelli CI/CD per creare ed eseguire pipeline predefinite per costruire e testare l’applicazione. Quindi, è possibile configurare le distribuzioni per distribuire le applicazioni in staging e in produzione e impostare le App di revisione per visualizzare in anteprima le modifiche per ramo. In questo modo GitLab CI/CD vi aiuta a individuare bug ed errori nelle prime fasi del ciclo di sviluppo e a garantire che tutto il codice distribuito in produzione sia conforme agli standard di codice stabiliti per la vostra applicazione.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.