Immagina due team di sviluppo.
Il primo prepara una nuova versione dell'applicazione.
Uno sviluppatore finisce il proprio task. Qualcuno controlla il codice. Poi bisogna eseguire i test. Qualcuno prepara il pacchetto. Qualcun altro accede al server. Successivamente bisogna eseguire alcune operazioni manuali, controllare la configurazione e osservare il sistema dopo il deployment. Se tutto va bene, la nuova versione è disponibile.
Il secondo team lavora in modo diverso.
Il codice finisce nel repository. Partono automaticamente i test, l'analisi della qualità e i controlli di sicurezza. Il sistema costruisce la versione dell'applicazione, la distribuisce nell'ambiente di test, esegue ulteriori verifiche e, al verificarsi di determinate condizioni, può distribuirla in produzione. Se qualcosa va storto, il deployment viene interrotto oppure il sistema può tornare alla versione precedente.
Entrambi i team sviluppano software.
Ma solo uno di loro ha costruito un processo ripetibile di delivery del software.
Ed è proprio questo il senso del CI/CD.
"Funziona in produzione" non è ancora un processo maturo
Molte aziende misurano il successo con un indicatore molto semplice: l'applicazione funziona.
Questo è ovviamente un requisito di base.
Ma con la crescita del sistema emergono altre domande:
- Quanto velocemente possiamo distribuire una correzione?
- Quanto spesso possiamo pubblicare nuove funzionalità?
- Quante operazioni manuali eseguiamo a ogni deployment?
- Ogni sviluppatore può avviare il processo di rilascio secondo le stesse regole?
- Sappiamo quale versione è attualmente in esecuzione?
- Siamo in grado di tornare alla versione precedente?
- Dopo il deployment controlliamo automaticamente se il sistema funziona correttamente?
- Abbiamo un monitoraggio?
- Sappiamo che il deployment ha causato un problema prima che lo segnali il cliente?
Queste sono domande di software delivery, non solo di programmazione.
CI e CD - due elementi di un unico processo
CI, cioè Continuous Integration, significa integrazione continua delle modifiche.
In pratica, si tratta di fare in modo che le modifiche arrivino spesso al repository condiviso e vengano controllate automaticamente.
Una pipeline tipica può eseguire, tra le altre cose:
-
compilazione o build dell'applicazione,
-
test unitari,
-
test di integrazione,
-
linting,
-
analisi statica del codice,
-
scansione delle dipendenze,
-
controlli di sicurezza,
-
creazione degli artifact di deployment.
In questo modo il problema può essere individuato prima che il codice finisca in produzione.
CD, cioè Continuous Delivery o Continuous Deployment, riguarda la fase successiva - la consegna delle modifiche.
A seconda del modello adottato, il sistema può preparare una versione pronta per il deployment oppure distribuirla automaticamente dopo il superamento di determinati controlli.
Questa è una distinzione importante.
Continuous Delivery non deve necessariamente significare il deployment automatico di ogni modifica in produzione.
Può semplicemente significare che ogni versione viene preparata in modo ripetibile per il deployment.
Perché i deployment manuali diventano un problema?
Un deployment manuale non deve per forza essere una cosa negativa.
In un piccolo progetto può essere del tutto sufficiente.
Il problema inizia quando il processo cresce insieme all'applicazione.
All'inizio c'è una persona sola che sa come distribuire il sistema. Poi si aggiunge un secondo server. Poi l'ambiente di test. Successivamente il database, la cache, le code, lo storage, alcuni servizi e API esterne. A questo si aggiungono diverse configurazioni per development, test e produzione.
Dopo alcuni anni, il processo può apparire più o meno così:
"Prima avvia X, poi modifica il parametro Y, quindi riavvia il servizio Z, ma prima fai un backup del database. E se compare un errore, chiama la persona che ha fatto il deployment l'ultima volta."
Questo non è più un processo. È conoscenza nascosta nella testa di una persona. Ed è proprio allora che il rischio cresce.
L'automazione non serve solo alla comodità degli sviluppatori
Spesso il CI/CD viene presentato come uno strumento per aumentare il comfort dei developer. È vero, ma è solo una parte del quadro.
L'automazione del delivery aumenta soprattutto la ripetibilità del processo.
Se il deployment viene eseguito da una persona, esiste la possibilità che ogni volta faccia qualcosa in modo leggermente diverso.
Se lo fa una pipeline, si può definire una sequenza precisa di passi.
La stessa versione.
Gli stessi test.
Gli stessi controlli.
Le stesse regole.
Questo è particolarmente importante nei progetti sviluppati da più persone o più team.
I test prima del deployment sono più importanti della velocità di deployment
L'automazione senza test può solo fare in modo che gli errori compaiano più rapidamente.
Per questo una pipeline ben progettata non dovrebbe essere solo un meccanismo: "codice → produzione".
Dovrebbe essere un sistema di controllo qualità.
A seconda del progetto, può includere:
- Test unitari - verificano i singoli elementi della logica.
- Test di integrazione - verificano la collaborazione tra i componenti.
- Test end-to-end - simulano scenari reali dell'utente.
- Test di sicurezza - verificano, tra le altre cose, le dipendenze e le vulnerabilità note.
- Test di performance - necessari quando è importante gestire un determinato carico.
Non ogni applicazione ha bisogno di tutti questi livelli nella stessa misura.
Ed è importante.
CI/CD non consiste nell'inserire il maggior numero possibile di strumenti nella pipeline.
Si tratta di scegliere i controlli in base al rischio del sistema specifico.
Cosa succede quando un test non passa?
Questa è una delle domande più importanti dell'intero processo.
Una pipeline matura dovrebbe avere regole chiaramente definite.
Se un test critico fallisce, la versione non dovrebbe essere considerata pronta per il deployment.
Se una scansione di sicurezza rileva un determinato livello di rischio, la pipeline può bloccare il processo.
Se la build non viene eseguita, non c'è nulla da distribuire.
Sembra banale. Ma proprio queste "porte" automatiche fanno sì che la qualità non dipenda solo dalla memoria e dalla precisione della persona.
E se comunque il deployment fallisce?
Nemmeno il processo migliore elimina tutti gli errori. Per questo il secondo elemento di un delivery maturo è la possibilità di annullare in modo controllato una modifica.
Il rollback può significare il ritorno all'artefatto precedente, all'immagine del container o alla versione dell'applicazione. Ma qui emerge un problema importante. Il rollback del codice non significa sempre rollback dei dati.
Se la nuova versione ha modificato la struttura del database, la situazione diventa più complicata.
Therefore, database migrations should be designed so that the whole process is as safe and reversible as possible, or at least compatible with the previous version of the application.
This is one of the examples showing that professional CI/CD is an architectural problem, not just a tool configuration issue.
Blue-green, canary and other deployment strategies
In more demanding systems, you do not have to switch all users to the new version right away. You can use different deployment strategies.
Blue-green deployment
Two versions of the environment run at the same time.
One handles traffic, the other is prepared to take over traffic.
After positive verification, the switch occurs.
Its advantage is the ability to quickly return to the previous environment.
Its drawback may be greater infrastructure usage.
Canary deployment
The new version is first rolled out to a small portion of users or traffic.
If monitoring does not show any issues, the scope of the deployment can be gradually increased.
This limits the potential reach of the error.
However, it requires appropriate infrastructure, monitoring and traffic management.
Feature flags
A feature can be deployed to the system, but remain disabled for users.
This makes code deployment and feature activation two separate processes.
This gives greater control, especially with large changes.
However, that does not mean feature flags are a solution for every project. Too many of them can also increase system complexity.
Post-deployment monitoring
You can run all the tests. You can have a great pipeline. You can deploy a new version without any errors. And a few minutes later the application may start behaving differently under real load.
That is why the process should not end at deployment. It needs observability, meaning the ability to understand what is happening inside the running system.
Depending on the architecture, it includes among others:
-
logs,
-
metrics,
-
tracing,
-
infrastructure monitoring,
-
application monitoring,
-
alerts,
-
error information,
-
business indicators.
It is not about collecting everything. It is about being able to answer important questions based on data.
Is the application working?
Is it running slower than before?
Has the number of errors increased?
Which service is causing the problem?
Does the problem affect all users or only some of them?
100 deployments a day is not always the goal
The title of this article talks about 100 deployments per day, but the point is not to set that number as a goal.
In an internal system updated once a month, it makes no sense to artificially aim for hundreds of deployments. In a heavily developed system, such a frequency may, however, be technically possible.
The key is the ability to deliver changes safely, not the number of deployments itself. That is a fundamental difference.
Process maturity is measured not by how often we deploy, but by how predictably and safely we can do it.
When can CI/CD be overkill?
Not every application needs a complex deployment infrastructure.
If we have a small application, a small team and a few deployments a year, an extensive pipeline may cost more than the problems it solves.
The same applies to very specific systems where deployment requires manual control for reasons of security, regulations or the nature of the infrastructure.
That is why delivery architecture should result from the needs of the system. Not from trends.
When does deployment automation pay off especially well?
It is worth considering especially when:
-
the system is developed regularly,
-
several people work on the code,
-
there is more than one environment,
-
deployments are frequent,
-
manual deployments generate errors,
-
the system is critical to the business,
-
we need a quick rollback,
-
the application has many components,
-
audits or a change trail are required,
-
the time to deliver a feature matters to the business.
In such cases, a well-designed pipeline can be one of the most important elements of the software development process.
CI/CD will not fix bad architecture
This is also worth emphasizing.
You can build a great pipeline for a bad application.
Automatically test bad code.
Automatically deploy bad architecture.
Automatically scale a poorly designed system.
Automation therefore does not replace architecture, tests or the team’s competence.
It strengthens the existing process.
If the process is good, it helps scale it.
If the process is bad, it may simply do bad things faster.
What does a mature process look like?
There is no single universal pipeline.
But a mature process should have several basic properties.
Repeatability - the deployment is carried out according to defined steps.
Automation - machines perform as much of the repetitive work as possible.
Testability - changes are automatically verified.
Security - the process includes appropriate security controls.
Observability - after deployment, you know what is happening with the system.
Reversibility - there is a planned way to respond to an unsuccessful change.
Change tracking - you know which version was deployed and what it was built from.
Access control - not everyone can deploy everything to production freely.
That is exactly how a professional software delivery process is built.
The most important change starts with a different question
Companies often ask: "How quickly can we build this feature?"
It is worth adding a second question: "How quickly and safely will we be able to deliver the next 50 features?"
Because a single deployment can be done manually. You can even deploy an application manually for several years. But as the product, the team, the number of users and the number of changes grow, the cost of such an approach also rises.
That is why CI/CD, automated tests, monitoring and controlled deployments are not just solutions for large corporations.
They are infrastructure elements of a process that allows you to develop software without adding unnecessary risk to each subsequent change.
And in the end, that is exactly the point.
Not 100 deployments a day.
Not trendy tools.
Non si tratta della pipeline più complessa.
Solo della possibilità di dire:
"Abbiamo una modifica. L'abbiamo verificata. Sappiamo cosa stiamo distribuendo. Sappiamo come monitorarla. E sappiamo cosa fare se qualcosa va storto."
