Nei workflow di GitHub sappiamo bene che, come avviene per Azure DevOps, tutti i job vengono eseguiti di default in "parallelo". Questo potrebbe essere sia un vantaggio che uno svantaggio, ma dipende chiaramente dalle condizioni di business. Il deployment, in particolare, è proprio un esempio di questo.

In molti scenari, infatti, potrebbe voler andare bene fare il deploy in qualsiasi ambiente in qualsiasi condizione, mentre in molti altri potrebbe aver senso avere approval anche per rilasciare del codice nell'ambiente di sviluppo. Vediamo invece uno scenario ibrido:

name: Deploy differenziale

on:
  push:
    branches:
      - main

jobs:
  deploy-dev:
    # ...

  deploy-staging:
    if: contains(github.event.head_commit.message, '[qa]')
    # ...

  deploy-pre-prod:
    if: contains(github.event.head_commit.message, '[pre-prod]')
    # ...
  
  deploy-prod:
    if: contains(github.event.head_commit.message, '[prod]')
    needs: [ deploy-pre-prod ]
    environment: production
    # ...

Nel codice di esempio, non facciamo alcun controllo sul job deploy-dev, quindi, ad ogni update del branch main (diretto o magari per via di una pull request), il codice può essere compilato e distribuito immediatamente. I deploy sugli ambienti di QA e pre-produzione, invece, partiranno subito come per l'ambiente di sviluppo, ma verranno verificate le condizioni di ingresso: in questo caso, i job vengono eseguiti solo nel caso in cui nel messaggio di commit contenga le parole chiave qa oppure pre-prod, ad indicare che c'è una intenzione di andare in quegli ambienti a seguito di una richiesta volontaria.

Il rilascio nell'ambiente di produzione, invece, è un caso a parte. Prima di tutto, questo job non parte in automatico poichè ha una needs specificata. Fintanto che il job di deploy-pre-prod non è stato eseguito correttamente, non può essere avviato. Seconda condizione è data dall'environment che potrebbe richiedere un ulteriore approval manuale, in base alla configurazione di GitHub per questo repository. Terza condizione è sempre la volontà, tramite messaggio di commit, di far partire il deploy nell'ambiente corretto di produzione.