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
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Creare una libreria CSS universale: Clip-path
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow
Eseguire i worklow di GitHub su runner potenziati
Utilizzare il metodo Index di LINQ per scorrere una lista sapendo anche l'indice dell'elemento
Creare una libreria CSS universale: Cards
Ricevere notifiche sui test con Azure Load Testing
Utilizzare WhenEach per processare i risultati di una lista di task
Gestione CSS in Blazor con .NET 9
Creare una custom property in GitHub
Disabilitare le run concorrenti di una pipeline di Azure DevOps
Introduzione alle Container Queries