1,198 26/03/2026 07/04/2026 3 min

Diagnosi probabile

Dopo un deploy in ambienti Microsoft, i problemi più comuni non sono nel build in sé ma in una catena spezzata: artifact non allineato, variabili d’ambiente diverse tra staging e produzione, servizio avviato ma non sano, oppure rollback eseguito senza ripristinare la stessa configurazione.

Se il rilascio usa Azure DevOps o GitHub Actions, la verifica post-deploy deve confermare tre cose: artifact corretto, app realmente raggiungibile e nessun drift evidente rispetto all’ambiente atteso.

Verifiche immediate

  1. Controlla che l’artifact pubblicato corrisponda alla build attesa: nome, numero di versione e hash, se disponibile. In Azure DevOps verifica il run e l’artefatto scaricato; l’esito atteso è che il pacchetto sia quello dell’ultima pipeline promossa.
  2. Verifica lo stato del servizio applicativo e la risposta HTTP del sito o API. Su Windows Server con IIS, un controllo rapido è:
Invoke-WebRequest https://app.example.com/health -UseBasicParsing | Select-Object StatusCode, Content

Esito atteso: 200 e contenuto di health coerente con l’app in produzione.

  1. Controlla il drift minimo tra ambienti: variabili, connection string, file di configurazione e permessi. Se l’app legge impostazioni da appsettings.json, da Key Vault o da Application Settings, confronta i valori con quelli previsti dal runbook; l’esito atteso è nessuna differenza non approvata.
  2. Verifica che i log non mostrino errori di bootstrap, migrazioni o dipendenze mancanti. Su Windows puoi usare Event Viewer o i log dell’application pool; l’esito atteso è assenza di errori ripetuti subito dopo il deploy.

Soluzione consigliata passo-passo

  1. Conferma l’artefatto deployato dal pannello della pipeline. In Azure DevOps apri il job di release e controlla il percorso dell’artifact, la versione e l’ora di pubblicazione. Se il nome non coincide con il run approvato, blocca il rollout e ripeti il download dall’output corretto.
  2. Esegui una verifica funzionale minima sull’endpoint di salute e su una pagina o chiamata reale. Se la health risponde ma l’app no, il problema è spesso nella configurazione o in una dipendenza esterna, non nel deploy in sé.
  3. Confronta la configurazione runtime con quella prevista. Se usi PowerShell su Windows Server, esporta i valori principali e confrontali con il baseline salvato in repository o in documentazione interna.
Get-ItemProperty 'HKLM:\SOFTWARE\MyApp' | Select-Object ApiUrl, Environment, FeatureFlagX

Esito atteso: i parametri corrispondono al profilo dell’ambiente corrente.

  1. Se trovi drift, correggi solo il minimo necessario e riavvia il servizio interessato, non l’intera macchina. Dopo il riavvio, ripeti health check e log check per confermare che il fix non abbia introdotto regressioni.
  2. Se il deploy ha introdotto un errore lato applicazione, esegui rollback all’artifact precedente già validato. Prima di farlo, annota versione, ora e motivo del rollback per evitare di perdere la traccia del problema.

Controlli finali / rollback

  1. Verifica finale: endpoint /health OK, pagina o API principale OK, log senza nuovi errori per almeno qualche minuto, e configurazione allineata al baseline.
  2. Rollback: torna alla build precedente solo se il problema persiste dopo la correzione minima o se la differenza tra ambienti è troppo ampia per essere corretta in sicurezza.
  3. Se l’ambiente è critico, conserva l’artifact precedente e il file di configurazione esportato prima di ogni modifica: è il punto di ritorno più rapido in caso di regressione.
Checklist pratica: artifact giusto, health check OK, configurazione coerente, log puliti, rollback pronto.

Assunzione: il deploy avviene su stack Microsoft con pipeline CI/CD e un endpoint di salute disponibile.