Distribuire in produzione con gate di approvazione
Impari a promuovere in sicurezza le build dallo staging alla produzione usando le regole di protezione degli ambienti di GitHub Actions, le approvazioni manuali e i gate di deployment.
Distribuire in produzione con gate di approvazione è una lezione CI/CD with GitHub Actions & DevOps Pipelines gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento CI/CD with GitHub Actions & DevOps Pipelines, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso CI/CD with GitHub Actions & DevOps Pipelines include 4 lezioni in totale.
Perché la produzione richiede dei gate
Il Continuous Deployment distribuisce il codice automaticamente, ma inviarlo direttamente in produzione senza alcun punto di controllo è rischioso. Una release difettosa può avere effetti immediati su ogni utente.
Un gate di approvazione è una pausa deliberata durante la quale una persona o un controllo automatico conferma che il deploy debba procedere.
- Riduce il raggio d'impatto degli errori
- Crea una traccia di audit di chi ha approvato cosa
- Permette di separare i livelli di affidabilità di
stagingeproduction
Ambienti GitHub
GitHub Actions offre una funzionalità chiamata Environments. Un ambiente, come production, può avere secret, variabili e proprie regole di protezione.
È possibile indicare un ambiente in un job utilizzando la chiave environment. Questa è la base per aggiungere gate di approvazione.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: echo 'Deploying to production'Revisori obbligatori
Nelle impostazioni del repository, in Settings > Environments > production, è possibile abilitare i revisori obbligatori.
Quando un job è destinato a quell'ambiente, l'esecuzione del workflow si mette in pausa e attende che uno dei revisori indicati faccia clic su Approve.
- È possibile configurare fino a 6 revisori
- Per impostazione predefinita, una singola approvazione sblocca il job
- A seconda delle impostazioni, l'approvatore non può essere la persona che ha avviato l'esecuzione
Un workflow completo con gate
In questo caso viene eseguito prima un job build, quindi un job deploy che dipende da esso tramite needs ed è destinato all'ambiente protetto production.
Il deploy non verrà avviato finché il revisore obbligatorio non lo avrà approvato nell'interfaccia di Actions.
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo 'build artifact'
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.example.com
steps:
- run: echo 'deploy to prod'Timer di attesa
Oltre ai revisori, gli ambienti supportano un timer di attesa. Questo impone un ritardo, fino a 30 giorni, prima che un deploy possa procedere.
Un timer di attesa breve è utile come periodo di raffreddamento di sicurezza: offre al team una finestra per annullare un'esecuzione prima che raggiunga la produzione.
Restrizioni sui branch di deploy
Gli ambienti possono limitare i branch autorizzati a eseguire il deploy. Per production, in genere si consente solo main o i tag di release.
In questo modo si impedisce un deploy accidentale in produzione da un branch di funzionalità.
- Branch protetti — solo branch con regole di protezione
- Branch selezionati — un elenco esplicito di elementi consentiti o un modello di tag
Secret con ambito limitato all'ambiente
Ogni ambiente dispone dei propri secret. Un ambiente production può contenere PROD_DB_URL, mentre staging contiene STAGING_DB_URL.
I secret definiti nell'ambiente sono disponibili solo ai job destinati a quell'ambiente, aggiungendo un ulteriore livello di isolamento.
steps:
- name: Deploy
env:
DB_URL: ${{ secrets.PROD_DB_URL }}
run: ./deploy.shMonitoraggio dello stato del deploy
Impostando un url sull'ambiente si aggiunge un link selezionabile al deploy nell'interfaccia di GitHub e si registra un oggetto deployment tramite l'API Deployments.
In questo modo si ottiene una cronologia visibile: quale commit è stato inviato in produzione, quando e da chi.
environment:
name: production
url: https://myapp.example.comApprovazione di un'esecuzione in attesa
Quando un job con gate è in attesa, nella pagina dell'esecuzione del workflow viene visualizzato un banner giallo Review deployments.
- Apra l'esecuzione nella scheda Actions
- Faccia clic su
Review deployments - Selezioni l'ambiente e faccia clic su
Approve and deployoppureReject
È anche possibile lasciare un commento per spiegare la decisione.
Combinazione di più gate
Il gate di produzione più efficace combina diverse regole:
- Revisori obbligatori (approvazione umana)
- Un timer di attesa (periodo di raffreddamento)
- Restrizioni sui branch (solo
main) - Secret dell'ambiente (isolamento)
La combinazione di questi elementi crea un processo solido di promozione da staging a production.
Come bypassare i gate in sicurezza
A volte è necessario applicare un hotfix di emergenza. Anziché rimuovere le regole di protezione, consideri un workflow per hotfix separato e con ambito limitato, dotato di registrazione propria e revisori più rigorosi.
Non disabiliti mai definitivamente i gate per comodità: verrebbe meno lo scopo del meccanismo di sicurezza.
Verifica rapida
Verifichi la comprensione dei gate di approvazione per la produzione.
Riepilogo
Ha imparato ad aggiungere gate di approvazione per i deploy in produzione utilizzando gli ambienti GitHub.
- Utilizzi la chiave
environmentper indicare un ambiente protetto - I revisori obbligatori aggiungono l'approvazione umana
- I timer di attesa aggiungono una finestra di raffreddamento
- Le restrizioni sui branch e i secret dell'ambiente aggiungono isolamento
Insieme, questi gate rendono sicura e verificabile la promozione da staging a production.
Domande Frequenti
La lezione «Distribuire in produzione con gate di approvazione» è gratuita?
Sì — il testo completo di «Distribuire in produzione con gate di approvazione» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso CI/CD with GitHub Actions & DevOps Pipelines, passa a CoddyKit PRO. Il corso CI/CD with GitHub Actions & DevOps Pipelines include 4 lezioni in totale.
Cosa imparerò in «Distribuire in produzione con gate di approvazione»?
Impari a promuovere in sicurezza le build dallo staging alla produzione usando le regole di protezione degli ambienti di GitHub Actions, le approvazioni manuali e i gate di deployment. Eserciti CI/CD with GitHub Actions & DevOps Pipelines con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare CI/CD with GitHub Actions & DevOps Pipelines?
Non è richiesta alcuna esperienza precedente. CI/CD with GitHub Actions & DevOps Pipelines su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «Distribuire in produzione con gate di approvazione»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione CI/CD with GitHub Actions & DevOps Pipelines?
Sì. Ogni lezione CI/CD with GitHub Actions & DevOps Pipelines include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Introduzione al Continuous Deployment
- Eseguire il deploy in un ambiente di staging
- Variabili d’ambiente e segreti
- Distribuire in produzione con gate di approvazione