Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# In che modo CI/CD i processi sono completamente diversi
Le pipeline CI/CD utilizzano un moderno *flusso di lavoro basato su trunk, in cui gli sviluppatori uniscono* aggiornamenti piccoli e frequenti in un ramo principale (o *trunk*) che viene creato e testato tramite la parte CD della pipeline. CI/CD Questo flusso di lavoro ha sostituito il flusso di lavoro *Gitflow*, in cui i rami di sviluppo e rilascio sono separati da una pianificazione dei rilasci. In molte organizzazioni, Gitflow è ancora un metodo popolare per il controllo e la distribuzione delle versioni. Tuttavia, ora è considerato obsoleto e può essere difficile integrarlo in una CI/CD pipeline.
Per molte organizzazioni, la transizione da un flusso di lavoro Gitflow a un flusso di lavoro basato su trunk è stata incompleta e il risultato è che rimangono bloccate da qualche parte lungo il percorso e non migrano mai completamente a CI/CD. In qualche modo, le loro pipeline finiscono per rimanere aggrappate a certi resti del flusso di lavoro tradizionale, bloccate in uno stato di transizione tra passato e presente. Esamina le differenze nei flussi di lavoro Git, quindi scopri come l'utilizzo di un flusso di lavoro legacy può influire su quanto segue:
+ [Integrità dell'ambiente](environment-integrity.md)
+ [Rilasci](releases.md)
+ [Sicurezza](security.md)
[Per semplificare l'identificazione dei resti di un flusso di lavoro Git legacy in una configurazione moderna, confrontiamo [Gitflow](#gitflow-approach) con il moderno approccio basato su trunk.](#trunk-based-approach)
## Approccio Gitflow
L'immagine seguente mostra un flusso di lavoro Gitflow. L'approccio Gitflow utilizza più rami per tenere traccia di diverse versioni del codice contemporaneamente. Pianifichi i rilasci degli aggiornamenti di un'applicazione per un certo periodo futuro mentre gli sviluppatori lavorano ancora sulla versione corrente del codice. I repository basati su Trunk possono utilizzare i flag di funzionalità per eseguire questa operazione, ma per impostazione predefinita sono integrati in Gitflow.
![\[Un flusso di lavoro Gitflow con rami relativi a funzionalità, sviluppo, rilascio e hotfix\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
Un risultato dell'approccio Gitflow è che gli ambienti applicativi di solito non sono sincronizzati. In un'implementazione standard di Gitflow, gli ambienti di sviluppo riflettono lo stato attuale del codice, mentre gli ambienti di preproduzione e produzione rimangono bloccati sullo stato della base di codice della versione più recente.
Ciò complica le cose quando appare un difetto nell'ambiente di produzione, perché la base di codice su cui lavorano gli sviluppatori non può essere unita alla produzione senza esporre funzionalità inedite. Il modo in cui Gitflow gestisce questa situazione consiste nell'utilizzare un hotfix. Un ramo hotfix viene creato dal ramo di rilascio e quindi distribuito direttamente negli ambienti superiori. Il ramo hotfix viene quindi unito al ramo di sviluppo per mantenere il codice aggiornato.
## Approccio basato su Trunk
L'immagine seguente mostra un flusso di lavoro basato su trunk. In un flusso di lavoro basato su trunk, gli sviluppatori creano e testano le funzionalità localmente in un ramo di funzionalità, quindi uniscono tali modifiche nel ramo principale. Il ramo principale viene quindi integrato negli ambienti di sviluppo, preproduzione e produzione, in sequenza. I test unitari e di integrazione vengono eseguiti tra ogni ambiente.
![\[Un flusso di lavoro basato su trunk con feature branch e un branch principale.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
Utilizzando questo flusso di lavoro, tutti gli ambienti utilizzano la stessa base di codice. Non è necessario un ramo hotfix per gli ambienti superiori perché è possibile implementare modifiche nel ramo principale senza esporre funzionalità non rilasciate. Si presume sempre che il ramo principale sia stabile, privo di difetti e pronto per il rilascio. Questo ti aiuta a integrarlo come fonte per una CI/CD pipeline, che può testare e distribuire automaticamente la tua base di codice in tutti gli ambienti della pipeline.
# Vantaggi dell'integrità ambientale di un approccio basato su trunk
Come molti sviluppatori sanno, una modifica al codice a volte può creare un [effetto farfalla](https://www.americanscientist.org/article/understanding-the-butterfly-effect) (articolo di American Scientist), in cui una piccola deviazione apparentemente non correlata innesca una reazione a catena che causa risultati inaspettati. Gli sviluppatori devono quindi indagare a fondo per scoprire la causa principale.
Quando gli scienziati conducono un esperimento, separano i soggetti del test in due gruppi: il gruppo sperimentale e il gruppo di controllo. L'intenzione è di rendere il gruppo sperimentale e il gruppo di controllo completamente identici ad eccezione dell'oggetto testato nell'esperimento. Quando succede qualcosa nel gruppo sperimentale che non accade nel gruppo di controllo, l'unica causa può essere la cosa testata.
Pensate ai cambiamenti in una distribuzione come a un gruppo sperimentale e pensate a ciascun ambiente come a gruppi di controllo separati. I risultati dei test in un ambiente inferiore sono affidabili solo quando i controlli sono gli stessi di un ambiente superiore. Più gli ambienti si discostano, maggiore è la possibilità di scoprire difetti negli ambienti superiori. In altre parole, se le modifiche al codice dovessero fallire in fase di produzione, preferiremmo di gran lunga che fallissero prima nella versione beta in modo che non arrivino mai in produzione. Questo è il motivo per cui è necessario fare ogni sforzo per mantenere sincronizzato ogni ambiente, dall'ambiente di test più basso alla produzione stessa. Questa si chiama *integrità dell'ambiente*.
L'obiettivo di ogni CI/CD processo completo è quello di scoprire i problemi il prima possibile. Preservare l'integrità dell'ambiente utilizzando un approccio basato su trunk può praticamente eliminare la necessità di aggiornamenti rapidi. In un flusso di lavoro basato su trunk, è raro che un problema compaia per la prima volta nell'ambiente di produzione.
In un approccio Gitflow, dopo che un hotfix è stato distribuito direttamente negli ambienti superiori, viene quindi aggiunto al ramo di sviluppo. In questo modo viene preservata la correzione per le versioni future. Tuttavia, l'hotfix è stato sviluppato e testato direttamente sullo stato corrente dell'applicazione. Anche se l'hotfix funziona perfettamente in produzione, esiste la possibilità che si verifichino problemi quando interagisce con le nuove funzionalità del ramo di sviluppo. Poiché in genere non è consigliabile implementare un hotfix per un hotfix, gli sviluppatori dedicano più tempo a cercare di adattare l'hotfix all'ambiente di sviluppo. In molti casi, ciò può comportare un notevole indebitamento tecnico e ridurre la stabilità complessiva dell'ambiente di sviluppo.
Quando si verifica un errore in un ambiente, tutte le modifiche vengono ripristinate in modo che l'ambiente ritorni allo stato precedente. Qualsiasi modifica a una base di codice dovrebbe riavviare la pipeline sin dalla prima fase. Quando si verifica un problema nell'ambiente di produzione, la correzione dovrebbe riguardare anche l'intera pipeline. Il tempo aggiuntivo necessario per gestire gli ambienti inferiori è in genere trascurabile rispetto ai problemi che si evitano utilizzando questo approccio. Poiché l'intero scopo degli ambienti inferiori è quello di catturare gli errori prima che raggiungano la produzione, aggirare questi ambienti attraverso un approccio Gitflow è un rischio inefficiente e non necessario.
# Scopri i vantaggi di un approccio basato su trunk
Uno degli aspetti che spesso rende necessario un hotfix è che, in un workflow legacy, lo stato dell'applicazione su cui stanno lavorando gli sviluppatori potrebbe contenere diverse funzionalità inedite che non sono ancora disponibili in produzione. L'ambiente di produzione e l'ambiente di sviluppo si sincronizzano solo quando si verifica un rilascio pianificato e quindi ricominciano immediatamente a divergere fino alla successiva versione pianificata.
È possibile disporre di rilasci programmati all'interno di un CI/CD processo completo. È possibile ritardare il rilascio del codice alla produzione utilizzando i flag di funzionalità. Tuttavia, un CI/CD processo completo consente una maggiore flessibilità rendendo superflui i rilasci programmati. Dopotutto, *continuo* è una parola chiave in CI/CD e ciò suggerisce che le modifiche vengono rilasciate non appena sono pronte. Evitate di mantenere un ambiente di rilascio separato, quasi sempre non sincronizzato con gli ambienti di test precedenti.
Se una pipeline non è completamente CI/CD, la divergenza tra gli ambienti superiori e quelli inferiori di solito si verifica a livello di filiale. Gli sviluppatori lavorano in un ramo di sviluppo e gestiscono un ramo di rilascio separato che viene aggiornato solo quando è il momento di una versione pianificata. Man mano che il ramo di rilascio e il ramo di sviluppo divergono, possono sorgere altre complicazioni.
Oltre alla mancata sincronizzazione degli ambienti, man mano che gli sviluppatori lavorano nel ramo di sviluppo e si abituano a uno stato dell'applicazione molto più avanzato di quello in produzione, devono riadattarsi allo stato di produzione ogni volta che si verifica un problema. Lo stato del ramo di sviluppo potrebbe riguardare molte funzionalità prima della produzione. Quando gli sviluppatori lavorano ogni giorno in quel settore, è difficile ricordare cosa viene rilasciato e cosa non viene rilasciato alla produzione. Ciò aumenta il rischio che vengano introdotti nuovi bug durante il processo di correzione di altri bug. Il risultato è un ciclo apparentemente infinito di correzioni che allungano le tempistiche e ritardano il rilascio delle funzionalità per settimane, mesi o addirittura anni.
# Vantaggi in termini di sicurezza di un approccio basato su trunk
Un CI/CD processo completo fornisce un approccio all'implementazione basato su un'unica fonte di verità completamente automatizzato. La pipeline ha un unico punto di ingresso. Gli aggiornamenti software entrano nella pipeline all'inizio e vengono passati così come sono da un ambiente all'altro. Se viene rilevato un problema in qualsiasi fase della pipeline, le modifiche al codice che lo risolvono devono passare attraverso lo stesso processo e iniziare nella prima fase. La riduzione dei punti di ingresso in una pipeline riduce anche i possibili modi in cui le vulnerabilità possono essere introdotte nella pipeline.
Inoltre, poiché il punto di ingresso è il punto più lontano possibile dall'ambiente di produzione, ciò riduce drasticamente la probabilità che le vulnerabilità raggiungano la produzione. Se si implementa un processo di approvazione manuale in una pipeline CI/CD completa, è comunque possibile decidere se promuovere o meno le modifiche all'ambiente successivo. Il decisore non è necessariamente la stessa persona che implementa le modifiche. Ciò separa le responsabilità dell'autore delle modifiche al codice e dell'approvatore di tali modifiche. Inoltre, consente a un responsabile organizzativo meno tecnico di svolgere il ruolo di approvatore.
Infine, il punto di ingresso singolo consente di limitare l'accesso in scrittura alla console dell'interfaccia utente (UI) dell'ambiente di produzione a pochi o addirittura zero utenti. Riducendo il numero di utenti che possono apportare modifiche manuali alla console, riduci il rischio di eventi di sicurezza. La capacità di gestire manualmente la console nell'ambiente di produzione è molto più necessaria nei flussi di lavoro legacy che in un approccio CI/CD automatizzato. Queste modifiche manuali sono più difficili da tracciare, rivedere e testare. Di solito vengono eseguite per risparmiare tempo, ma a lungo termine aggiungono un notevole debito tecnico al progetto.
I problemi di sicurezza delle console non sono necessariamente causati da malintenzionati. Molti dei problemi che si verificano nella console sono accidentali. L'esposizione accidentale alla sicurezza è molto comune e ha portato alla nascita del modello di sicurezza zero-trust. *Questo modello presuppone, in parte, che gli incidenti di sicurezza siano meno probabili quando anche il personale interno ha il minor accesso possibile, le cosiddette autorizzazioni con privilegi minimi.* Preservare l'integrità dell'ambiente di produzione limitando tutti i processi a una pipeline automatizzata elimina praticamente il rischio di problemi di sicurezza relativi alla console.