Ingegneria del software
Feature flag e rilasci progressivi: governare le versioni del software aziendale
Una nuova versione può essere tecnicamente corretta e creare comunque difficoltà nel lavoro quotidiano: cambia un passaggio, modifica un tempo di elaborazione o introduce uno stato che un'integrazione non riconosce. Nel software aziendale il rilascio richiede quindi una decisione sul perimetro operativo, oltre alla distribuzione del codice. Le feature flag consentono di separare questi momenti, ma diventano utili soltanto quando attivazione, osservazione e recupero sono progettati insieme.
Distribuire il codice e attivare una funzione sono decisioni diverse
Distribuire significa rendere disponibile una versione dell'applicazione nell'ambiente previsto. Attivare significa consentire che un nuovo comportamento venga effettivamente utilizzato. Una feature flag introduce un punto di decisione tra le due operazioni: il codice contiene entrambi i percorsi, mentre una configurazione stabilisce quale applicare nel contesto richiesto. La documentazione Microsoft sulla gestione delle funzionalità descrive questa separazione come una capacità delle feature flag. Non è però una garanzia di continuità: entrambi i percorsi devono rispettare le regole fondamentali del sistema.
Per esempio, una nuova procedura di assegnazione delle richieste di assistenza può essere distribuita senza renderla subito disponibile a tutti i gruppi. Il responsabile del rilascio stabilisce quando iniziare il pilota, chi lo osserva e quali condizioni permettono di ampliarlo. Questa scelta è distinta dal diritto dell'utente a eseguire l'operazione. Una flag non sostituisce i permessi: anche se la funzione è attiva, il servizio deve verificare che l'identità corrente sia autorizzata a consultare o modificare quei dati.
Scegliere il gruppo pilota seguendo i confini del processo
Nei servizi rivolti al pubblico può avere senso ragionare per percentuali di utenti. In un'applicazione aziendale la singola persona non è sempre l'unità adatta: commerciale, magazzino e amministrazione possono lavorare sullo stesso documento. Se ricevono comportamenti incompatibili, un campione numericamente piccolo può coinvolgere molte operazioni. Il progetto deve individuare un confine coerente, come un'organizzazione, una sede o una famiglia di pratiche, e verificare quali informazioni attraversano quel confine prima di decidere come suddividere il rilascio.
Il gruppo va inoltre mantenuto stabile per il periodo di osservazione. Cambiare percorso a ogni richiesta rende difficile capire quale comportamento abbia prodotto un risultato e può confondere chi completa un'attività su più schermate. La regola di assegnazione dovrebbe essere deterministica, documentata e controllabile. Per i lavori differiti serve una decisione ulteriore: usare la configurazione corrente oppure conservare la versione della regola scelta all'avvio. La risposta dipende dagli effetti del processo e deve essere esplicita.
Il comportamento predefinito deve essere una scelta consapevole
La configurazione può non essere disponibile, arrivare in ritardo o contenere un valore non interpretabile. Il progetto deve stabilire un comportamento predefinito sicuro per ogni flag. La specifica OpenFeature prevede un valore predefinito nelle operazioni di valutazione e definisce come gestire condizioni di errore: è un riferimento utile per costruire un'interfaccia coerente. Nel progetto reale occorre comunque decidere quale percorso sia accettabile e quando sia necessario fermare l'operazione, anziché scegliere automaticamente una delle alternative.
Tornare al percorso precedente non è sempre innocuo. Se una procedura già attiva richiede un controllo aggiuntivo per proteggere l'operazione, disattivarla indiscriminatamente potrebbe rimuovere una tutela necessaria. Il valore di ripiego deve quindi essere valutato rispetto al rischio del processo, non soltanto alla disponibilità tecnica. Anche la cache della configurazione richiede un limite di freschezza: bisogna sapere quanto tempo può trascorrere prima che un arresto deciso dal responsabile raggiunga tutte le istanze coinvolte.
Disattivare una funzione non annulla i dati già modificati
Una flag può interrompere l'uso di un nuovo comportamento, ma non cancella automaticamente gli effetti già prodotti. Se una versione scrive un nuovo stato del documento o invia un messaggio a un sistema esterno, il percorso precedente deve saper convivere con quella situazione. Prima del rilascio occorre distinguere la reversibilità del codice dalla reversibilità dei dati. Il piano deve descrivere che cosa resta valido dopo la disattivazione e quali pratiche richiedono invece una gestione specifica.
Quando cambia lo schema del database, una sequenza di espansione e successiva contrazione può offrire una transizione più controllabile: prima si aggiungono strutture compatibili, poi si trasferiscono le letture e le scritture e soltanto alla fine si rimuove ciò che non serve più. La durata della convivenza deve essere limitata e verificata. Un backup rimane importante, ma ripristinare un intero archivio potrebbe eliminare operazioni valide avvenute nel frattempo; per questo il recupero richiede spesso una riconciliazione circoscritta.
Osservare gli esiti aziendali insieme ai segnali tecnici
Il rilascio progressivo richiede criteri di avanzamento definiti prima dell'attivazione. Errori applicativi e tempi di risposta sono necessari, ma possono non mostrare un cambiamento nella qualità del processo. Per una nuova assegnazione delle richieste si possono osservare pratiche senza responsabile, riassegnazioni e tempi di presa in carico. Ogni indicatore richiede una definizione e un insieme di confronto ragionevolmente comparabile. Differenze nei volumi, nei tipi di pratica e negli orari possono spiegare scostamenti che non dipendono dalla nuova versione.
Un segnale deve anche essere collegato a un'azione. La documentazione AWS AppConfig mostra come associare allarmi al monitoraggio di una distribuzione per interromperla o avviare un ritorno alla configurazione precedente. Il principio progettuale è stabilire chi osserva, quale soglia richiede attenzione e quale intervento è effettivamente consentito. Il ritorno della configurazione non prova che i dati siano stati riparati: dopo un arresto restano da verificare gli effetti prodotti e gli eventuali recuperi necessari.
Collaudare le combinazioni che contano, non solo il percorso nuovo
Ogni flag aumenta il numero dei comportamenti possibili. Non è sostenibile trattare tutte le combinazioni come equivalenti, ma nemmeno provare soltanto quella che il gruppo desidera attivare. I test devono coprire il percorso precedente ancora supportato, il nuovo percorso, la configurazione mancante e le transizioni ammesse. Vanno inoltre considerate le dipendenze tra flag: se una funzione richiede una nuova struttura dati, l'attivazione non dovrebbe poter aggirare quella condizione attraverso una combinazione non prevista.
Un buon esercizio di collaudo interrompe un'attività nel momento meno comodo: una pratica è stata acquisita, il lavoro differito non è ancora concluso e il responsabile disattiva la funzione. Il gruppo verifica come riparte l'elaborazione e come l'operatore comprende lo stato residuo. I risultati attesi devono derivare dalle regole del dominio, non essere ricavati a posteriori da ciò che il programma ha fatto. Anche gli strumenti di assistenza devono permettere di riconoscere la variante applicata alla singola operazione.
Governare la configurazione come un cambiamento di produzione
Separare attivazione e distribuzione non deve trasformare la configurazione in una via laterale senza controllo. Per ogni modifica significativa vanno registrati autore, motivazione, perimetro, momento e valore precedente. I privilegi di consultazione e modifica devono essere distinti. Una variazione che interessa un'intera organizzazione può avere un impatto maggiore di una piccola modifica al codice: il percorso di autorizzazione deve riflettere quell'impatto e prevedere un intervento rapido per gli incidenti, con tracciamento successivo.
Il registro delle flag dovrebbe inoltre includere proprietario, data prevista di rimozione, dipendenze e stato del rilascio. Quando la transizione è conclusa, mantenere indefinitamente due implementazioni aumenta il costo della manutenzione e rende meno chiaro quali comportamenti siano ancora sostenuti. La rimozione comprende codice, configurazione, test e documentazione operativa. Se una flag è destinata a restare come controllo operativo, questa scelta va dichiarata e gestita con responsabilità e prove adeguate alla sua funzione.
Proteggere le integrazioni durante la convivenza tra versioni
Un sistema esterno non conosce necessariamente le scelte di attivazione dell'applicazione. Se il nuovo percorso modifica il significato di un evento, il suo destinatario deve poterlo interpretare correttamente anche durante la convivenza. Occorre verificare contratti, versioni, valori opzionali e gestione degli stati non riconosciuti. La verifica riguarda anche i ritentativi: un evento prodotto prima della disattivazione può arrivare dopo, quando il sistema opera già secondo una configurazione diversa.
Per il contesto applicativo delle integrazioni con il prodotto SoftJob, la pagina delle API e dei Web Services di Gestionale sul Web è il riferimento pertinente. Questo articolo descrive un metodo generale di rilascio e non attribuisce al prodotto un'implementazione specifica di feature flag. Il criterio decisivo è poter ricostruire, per ogni operazione, quale regola sia stata applicata, quali effetti abbia prodotto e come gestire la transizione successiva senza affidarsi alla memoria del gruppo di sviluppo.
Riferimenti tecnici
Per approfondire i temi tecnici trattati:
- Microsoft Learn — gestione delle funzionalità e separazione tra distribuzione e attivazione
- OpenFeature — specifica della valutazione delle feature flag
- AWS AppConfig — monitoraggio delle distribuzioni e ritorno alla configurazione precedente
A cura della redazione tecnica SoftJob. Pubblicato il .