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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Applicare un filtro per recuperare alcune issue di GitHub
.NET Conference Italia 2024
Escludere alcuni file da GitHub Secret Scanning
Eseguire i worklow di GitHub su runner potenziati
Eseguire una ricerca avanzata per recuperare le issue di GitHub
Garantire la provenienza e l'integrità degli artefatti prodotti su GitHub
Implementare l'infinite scroll con QuickGrid in Blazor Server
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
Sfruttare al massimo i topic space di Event Grid MQTT
Eseguire script pre e post esecuzione di un workflow di GitHub
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow