Feature Flags: come evolve il software senza aspettare la versione successiva?

Siamo abituati a vedere una nuova funzionalità arrivare insieme a una nuova versione del software. L’applicazione viene aggiornata, la versione viene pubblicata e il cambiamento diventa disponibile.

Ma il software moderno non funziona sempre in questo modo.

Una funzionalità può essere già inclusa nella versione in produzione e, allo stesso tempo, non essere ancora attiva. Può essere abilitata inizialmente solo per il team che la sta sviluppando, poi per un piccolo gruppo di utenti e, infine, per tutti.

E se si verifica un problema, può essere disattivata senza che sia sempre necessario pubblicare immediatamente una nuova versione.

Dietro questa flessibilità c’è un meccanismo chiamato Feature Flags.

Il codice può essere pronto. La release può aspettare.

Il principio di base è relativamente semplice.

Un Feature Flag funziona come un livello di controllo su una determinata funzionalità. Il codice può essere già stato distribuito in produzione, ma è il flag a determinare se la funzionalità debba essere attiva oppure no.

Questo permette di separare due momenti tradizionalmente molto legati tra loro: il deployment del codice in produzione e il rilascio della funzionalità agli utenti.

Per i team di sviluppo, questo offre maggiore flessibilità. Una nuova versione non deve necessariamente aspettare che tutte le funzionalità al suo interno siano pronte per essere rese disponibili a tutti.

E una funzionalità non deve necessariamente aspettare la versione successiva solo perché il momento previsto per il suo rilascio è cambiato.

Non tutti i cambiamenti devono essere disponibili immediatamente per tutti

Uno degli utilizzi più pratici dei Feature Flags è l’attivazione graduale.

Una nuova funzionalità può essere attivata inizialmente per il team interno. Successivamente per un numero limitato di utenti e, se tutto funziona come previsto, gradualmente per un gruppo più ampio.

Questo consente al team di osservare come si comporta la funzionalità in condizioni reali senza esporre immediatamente tutti gli utenti al cambiamento.

Invece di passare immediatamente dallo 0% al 100%, il rilascio può diventare un processo controllato.

Un problema non deve sempre significare una nuova versione

Lo stesso controllo funziona anche nella direzione opposta.

Se dopo l’attivazione emerge un problema, una funzionalità gestita tramite Feature Flags può, quando appropriato, essere disattivata senza dover attendere un nuovo ciclo di release.

Il codice rimane al suo posto, ma gli utenti non sono più esposti alla funzionalità problematica.

Questo non sostituisce i test, il rollback o le altre pratiche utilizzate per garantire l’affidabilità del software. Offre però un’ulteriore possibilità per reagire rapidamente e limitare l’impatto di un problema.

Dal rilascio delle versioni al controllo dei cambiamenti

I Feature Flags non eliminano le release né la necessità di nuove versioni. Cambiano il modo in cui una funzionalità passa dal codice all’utente.

Il team può distribuire il codice in produzione e poi controllare separatamente quando la funzionalità viene attivata, chi può utilizzarla e con quale gradualità viene resa disponibile.

Come afferma Ermal Beqiri, fondatore di ALSoft:

“Con i Feature Flags, una funzionalità può essere pronta e già integrata nel software senza dover essere attivata immediatamente per tutti. Questo offre ai team un maggiore controllo sul modo in cui vengono rilasciati i cambiamenti e la possibilità di reagire rapidamente se qualcosa non funziona come previsto.”

Il software può evolvere gradualmente, mentre il team mantiene il controllo su ogni fase del cambiamento.