Quando lavoriamo con Azure Functions nel piano Flex Consumption l'aggiornamento con un nuovo deploy comporta il riavvio coordinato dell'app: le istanze vengono terminate e ricreate con la nuova versione. Questo passaggio è semplice, ma introduce rischi concreti: brevi finestre di indisponibilità, esecuzioni interrotte, connessioni HTTP reset, picchi di cold start e possibili messaggi duplicati o persi se i trigger non sono idempotenti o se i client non gestiscono il retry.

Per superare questi limiti, la nuova modalità Rolling update aggiorna l'app a scorrimento, senza fermare il traffico complessivo. La piattaforma divide le istanze in piccoli batch, mette in drain il primo gruppo (non accettano nuove richieste ma completano quelle in corso), avvia istanze con la nuova build e ribilancia il traffico; poi prosegue con il batch successivo finché tutte eseguono la versione aggiornata. In questo modo puntiamo a zero downtime e a una transizione controllata, ideale per workload con code, webhook e job di durata media.

Per abilitarla questa strategia dobbiamo intervenire via ARM sull'impostazione functionAppConfig.siteUpdateStrategy.type e impostarla a RollingUpdate.

Con ARM template lo schema diventa il seguente:

{
  "type": "Microsoft.Web/sites",
  "apiVersion": "2023-12-01",
  "kind": "functionapp,linux,container,flexconsumption",
  "properties": {
    "functionAppConfig": {
      "siteUpdateStrategy": {
         "type": "RollingUpdate"
         }
      }
   }
}

Adottando questa strategia l'aggiornamento può risultare più lento, poiché le istanze vengono aggiornate a scaglioni. Durante la convivenza tra versioni diverse del codice, dobbiamo garantire la retrocompatibilità delle modifiche per evitare comportamenti incoerenti.