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.