Strategie di ramificazione per IaC

La metodologia Git tipica utilizza un trunk base primario (ad esempiomain) 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 distribuzione blu/verde.

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) 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 processo CI/CD con una gestione complessa delle variabili.

• Separa gli ambienti in repository separati.

• La soluzione meno comune: utilizzare più rami del tronco.