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 i processi CI/CD 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) 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 pipeline CI/CD.
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 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:
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 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.
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 sorgente per una pipeline CI/CD, che può testare e distribuire automaticamente la tua base di codice in tutti gli ambienti della pipeline.
