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
Gestione degli environment per il deploy con un workflow di GitHub
Usare gateway dedicati con Azure Cosmos DB per migliorare le prestazioni
Migrare un repository git da Azure DevOps a GitHub
Utilizzare le Cache API di JavaScript per salvare elementi nella cache del browser
Creare attributi generici in C#
Pubblicare un pacchetto di NuGet nel feed di GitHub
Utilizzare l'API del browser fetch
Permettere l'append ai file di un Azure Storage immutabile
Controllare gli accessi IP alle app con Azure Container Apps
Autenticazione basata su certificati con ASP.NET Core
Monitorare e prevenire problemi in produzione
Chiamare un endpoint ASP.NET Core protetto da Certificate Authentication
I più letti di oggi
- Filtrare e rimuovere gli elementi dalla cache del browser tramite le API JavaScript
- Utilizzare HiLo per ottimizzare le insert in un database con Entity Framework
- Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
- Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
- Elencare le container images installate in un cluster di Kubernetes
- Recuperare un elemento inserito nella cache del browser tramite API JavaScript
- Controllare gli accessi IP alle app con Azure Container Apps
- Utilizzare le Cache API di JavaScript per salvare elementi nella cache del browser
- Determinare lo stato di un pod in Kubernetes
- .NET Conference Italia 2022 - Milano e Online