Orchestrare il deployment di un'applicazione non è mai semplice, in quanto sono coinvolti diversi attori. Il più importante è sicuramente l'architettura del software, in quanto il rilascio di un sistema a microservizi è certamente più complesso di un sistema a monolite, ma altrettanto significativo è l'impatto dell'infrastruttura su cui dovrà essere hostato il sistema. Ciò che accumuna, però, tutte queste varianti, è che non possiamo permetterci di andare in produzione senza una approvazione specifica di qualche manager e senza aver effettuato tutti i controlli necessari, altrimenti si correrebbero dei rischi incalcolabili.
In GitHub esiste il concetto di Environment, che vengono agganciati ai job di deployment. Di fatto, non sono l'ambiente in cui fare il deploy del software, ma solo una loro rappresentazione logica che ci permette di individuare ed effettuare una serie di check pre-deployment. Vediamone un esempio.
name: Deploy on: push: branches: [ main, feat/*, release/*, hotfix/* ] jobs: deploy-dev: name: Deploy to testing environment: dev runs-on: ubuntu-latest steps: - run: echo 'Deploying in DEV' deploy-staging: name: Deploy to staging environment: Staging needs: [ deploy-dev ] if: github.event.ref == 'refs/heads/main' || github.event.ref == 'refs/heads/release/*' || github.event.ref == 'refs/heads/hotfix/*' runs-on: ubuntu-latest steps: - run: echo 'Deploying in staging' deploy-production: name: Deploy to production environment: Production needs: [ deploy-staging ] runs-on: ubuntu-latest steps: - run: echo 'Deploying in production'
Abbiamo simulato il rilascio in tre ambienti distinti. Nel primo, il deployment viene eseguito in un ambiente di sviluppo e pertanto non sono necessari ulteriori controlli. Nell'ambiente di staging, invece, vogliamo assicurarci che il deployment in dev sia andato a buon fine e che il codice provenga solo da un branch principale e/o di rilascio (seguendo le best-practice di GitFlow).
Nel terzo caso, invece, c'è solo una reference all'ambiente di produzione. Infatti, gli stessi check possono essere fatti anche lato GitHub UI all'interno dei settings del repository. Infatti, è proprio qui che possiamo impostare un owner dell'ambiente così che gli venga chiesto un approval prima che il job venga messo in esecuzione, piuttosto che limitare il branch che conterrà il codice o, ancora, impostare variabili d'ambiente e secret dedicate.

Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eseguire una ricerca avanzata per recuperare le issue di GitHub
Eliminare una project wiki di Azure DevOps
Creare una libreria CSS universale - Rotazione degli elementi
Ottimizzare le pull con Artifact Cache di Azure Container Registry
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Disabilitare automaticamente un workflow di GitHub (parte 2)
Escludere alcuni file da GitHub Secret Scanning
Migrare una service connection a workload identity federation in Azure DevOps
Utilizzare l'espressione if inline in una pipeline di Azure DevOps
Generare la software bill of material (SBOM) in GitHub
Utilizzare una qualunque lista per i parametri di tipo params in C#