L'integrazione continua (CI) è una pratica di sviluppo in cui i team di sviluppo apportano modifiche piccole e frequenti al codice. Questa pratica incoraggia il commit di piccole modifiche più spesso rispetto a grandi cambiamenti che implicano tempi più lunghi. Ogni commit attiva una build durante la quale vengono eseguiti dei test che aiutano a identificare se qualcosa è stato rotto dalle modifiche.
L'integrazione continua è la prima parte di CI/CD, una pratica che consente ai team di sviluppo di rilasciare modifiche al codice incrementali alla produzione in modo rapido e regolare.
L'obiettivo di CI è stabilire un modo coerente e automatizzato per creare, confezionare e testare le applicazioni, portando a una migliore qualità del software. Quindi miglioramento della qualità del software e riduzione del rischio. Le migliori pratiche di CI includono:
- Commit frequenti del codice
- Classificazione dei test per sviluppatori
- Una macchina dedicata per compilazione e integrazione
- Meccanismi di feedback continuo
- Staging build
E' un approccio per la distribuzione del software in cui i team di sviluppo producono e testano il codice in cicli brevi ma continui, solitamente con alti gradi di automazione, per migliorare la qualità del software. Questo processo consente ai team di sviluppo di creare, testare e distribuire rapidamente il software incoraggiando più aggiornamenti incrementali, piuttosto che dedicare gran parte del tempo a una revisione completa di un determinato prodotto.
La distribuzione continua è un approccio diffuso per la distribuzione del software, in particolare per i team che praticano DevOps. In genere è abbinato all'integrazione continua (CI) per formare una catena di processi per lo sviluppo del software, l'implementazione e i cicli di feedback chiamati pipeline CI/CD.
Solitamente il codice viene distrubuito regolarmente ai test di accettazione dell'utente o a un ambiente di staging, viene testato per tutti gli aspetti della funzionalità per ridurre i problemi di prestazioni o imprevisti in produzione. Qualsiasi componente che supera i test automatizzati è un candidato valido per il rilascio. In questa fase finale, la distribuzione in produzione viene effettuata da uno sviluppatore. In alternativa, la build può essere distribuita automaticamente. Quest'ultimo processo viene chiamato distribuzione continua.
Gli strumenti CI/CD possono aiutare un team ad automatizzare lo sviluppo, la distribuzione e il test. Alcuni strumenti gestiscono specificamente il lato di integrazione (CI), alcuni gestiscono lo sviluppo e la distribuzione (CD), mentre altri sono specializzati in test continui o funzioni correlate.
Uno degli strumenti open source più noti per CI/CD è il server di automazione Jenkins. Progettato per gestire qualsiasi cosa, da un semplice server CI a un hub CD completo.
Tekton Pipelines è un framework CI/CD per piattaforme Kubernetes che fornisce un'esperienza CI/CD cloud-native standard con i container.
Oltre a Jenkins e Tekton Pipelines, altri strumenti CI/CD open source sono:
- Spinnaker, una piattaforma CD creata per ambienti multi-cloud.
- GoCD, un server CI / CD con particolare attenzione alla modellazione e alla visualizzazione.
- Concourse, "una continua attività open source".
- Screwdriver, una piattaforma di costruzione progettata per CD.
Inoltre, è probabile che qualsiasi strumento fondamentale per DevOps faccia parte di un processo CI/CD. Gli strumenti per l'automazione della configurazione (come Ansible, Chef e Puppet), i runtime dei container (come Docker, rkt e cri-o) e l'orchestrazione dei container (Kubernetes) non sono strettamente strumenti CI/CD, ma mostreranno in molti flussi di lavoro CI/CD.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
