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à. # Strategie di ramificazione per IaC La metodologia Git tipica utilizza un trunk base primario (ad esempio`main`) branch per la produzione, un ramo di sviluppo e feature branch. Molte organizzazioni adottano immediatamente lo stesso design per l'infrastruttura come codice (IaC). Tuttavia, la metodologia Git non è direttamente compatibile con i modelli di progettazione dell'infrastruttura comuni. Considerate i seguenti punti: + Le applicazioni hanno diversi ambienti. + Gli esempi di ambiente includono sandbox, sviluppo, staging e produzione. + Gli ambienti non sono strettamente collegati. + La produzione è spesso strettamente associata a implementazioni di staging di successo. + La produzione e la messa in scena sono in genere completamente disaccoppiate dall'ambiente di sviluppo. + Lo sviluppo è in genere completamente disaccoppiato dall'ambiente sandbox. + Ogni applicazione ha il proprio set di standard ambientali. + Molte applicazioni non utilizzano un ambiente sandbox. + Alcune applicazioni non richiedono un ambiente di staging ma utilizzano invece una strategia di blue/green distribuzione. Immagina uno scenario in cui un repository di applicazioni fornisca tre ambienti che utilizzano una metodologia basata su trunk. L'ambiente di sviluppo è legato alla `develop` filiale, lo staging alla filiale e la produzione alla `staging` filiale. `main` Per questa applicazione, è necessaria una nuova funzionalità per connettere un gateway di transito alla soluzione, gestita da un altro team e da un altro repository. Uno sviluppatore scrive il codice dell'infrastruttura in un ramo di funzionalità e lo unisce al `develop` ramo quando è pronto. Sembra tutto a posto. Tuttavia, si presenta una sfida. Un altro sviluppatore ha una storia utente separata per una funzionalità separata, la scrive in un ramo di funzionalità e la unisce al `develop` ramo. La seconda funzionalità è ora pronta per essere integrata nella messa in scena e nella produzione. Tuttavia, la funzionalità di gateway di transito originale non è pronta a causa di un criterio di rischio all'interno dell'organizzazione. Ora tutte le funzionalità sono bloccate dalla promozione alla produzione e il codice dell'applicazione è effettivamente bloccato o danneggiato. In questo scenario, considerate le seguenti possibili soluzioni: + La *soluzione più comune:* aumentare la ripetizione del codice (ridurre il [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)) nelle posizioni mirate della struttura del codice impostando `./environments` cartelle separate nel repository. Ciò consente al codice degli ambienti di trovarsi nello stesso repository, ma disaccoppiato. + Imposta un CI/CD processo con una gestione complessa delle variabili. + Separa gli ambienti in repository separati. + *La soluzione meno comune:* utilizzare più rami del tronco.