8 Migliori Pratiche per le Feature Flag che Dovresti Conoscere
I flag di funzionalità sono una vera rivoluzione per i product manager. Permettono di rilasciare nuove funzionalità senza complicazioni: niente modifiche al codice, nessun rollout completo e zero rischi.
Pensali come un interruttore che puoi azionare per personalizzare il tuo prodotto o realizzare esperimenti all’istante. Che tu voglia accelerare i cicli di rilascio o testare nuove idee, i flag di funzionalità ti mettono il controllo tra le mani.
In questo articolo, condividerò le migliori pratiche per la gestione dei flag di funzionalità e ti mostrerò come ho usato queste tecniche in Guardian Soulmates, la piattaforma di incontri di The Guardian, per semplificare un importante redesign.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Definizione: Le feature flag migliorano i cicli di rilascio consentendo l’attivazione sicura e flessibile di funzionalità senza modifiche al codice.
Perché sono utili: Nomenclature chiare per le feature flag aiutano i team a comprendere facilmente il loro scopo ed evitano confusione.
Come usarle in modo efficace: Gestisci le flag in modo efficace eliminando quelle obsolete e assicurandoti che possano essere facilmente attivate o disattivate.
Inizia in piccolo: Usa le feature flag per i test iniziando con piccoli gruppi di utenti e ampliando in base al feedback per minimizzare i rischi.
Migliori pratiche per la gestione dei flag di funzionalità
Per gestire efficacemente i flag di funzionalità e garantire rilasci fluidi del prodotto, è importante seguire alcune migliori pratiche che promuovano chiarezza ed efficienza. Ecco alcune pratiche fondamentali da tenere a mente:
- Usa un sistema coerente: sia tramite uno strumento di gestione che un file di configurazione, assicurati che il sistema sia facile da comprendere e accessibile a tutti i membri del team.
- Definisci convenzioni di denominazione chiare: ogni tipo di flag (es. rilascio, permesso, kill) deve avere nomi unici e descrittivi, così da essere chiari per tutti anche a distanza di anni.
- Rendi semplice l’attivazione/disattivazione dei flag: i flag devono poter essere abilitati o disabilitati con facilità, senza bisogno di modifiche al codice o dell’intervento di sviluppatori.
- Pulisci i flag obsoleti: rimuovi quelli che non servono più per evitare disordine e ridurre il debito tecnico nel tuo sistema.
1. Utilizza un sistema coerente per la gestione dei flag di funzionalità
Non importa se usi un tool di gestione dei flag di funzionalità (come ad esempio LaunchDarkly), un file di configurazione o una tabella di database. Indipendentemente da cosa utilizzi, il sistema deve essere facile da comprendere e dotato di buone convenzioni di denominazione, in modo che ogni sviluppatore capisca cosa fa ciascun flag.
Dedica un po’ di tempo, quando introduci per la prima volta i flag di funzionalità, a discutere quale sia la soluzione migliore per te: vorrai usarla per il lungo termine.
2. Definisci convenzioni di denominazione per i diversi tipi di flag di funzionalità
Puoi implementare i flag di funzionalità per raggiungere molti obiettivi diversi:
- Flag di rilascio: facilitano il rollout di codice in produzione prima che una funzionalità sia pronta per il rilascio pubblico.
- Flag di esperimento: per creare un A/B test, il flag controlla quale gruppo di utenti riceve quale esperienza.
- Flag di permesso: permettono di controllare l’accesso a determinate funzionalità per clienti diversi
- Flag di kill: permettono di degradare il prodotto in modo controllato in caso di problemi di performance o sovraccarico.
Convenzioni di denominazione chiare per ciascun tipo di flag fanno sì che tutti sappiano cosa fa ogni flag anche dopo anni.
3. Rendi facile attivare/disattivare un flag
Il bello dei flag di funzionalità è che possono essere attivati e disattivati con facilità. Idealmente, dovresti poter impostare un flag senza alcuna modifica al codice o intervento di uno sviluppatore. Poiché possono essere ampiamente utilizzati, diversi team potrebbero volerli manipolare, ad esempio:
- QA per risolvere o replicare una particolare situazione di un cliente.
- Assistenza clienti per abilitare o disabilitare una funzionalità per un cliente.
- DevOps per interrompere (parti di) un prodotto in modo controllato in caso di sovraccarico o altri problemi.
Se disponi di una schermata online per impostare i flag, tutto questo può essere fatto senza il lavoro del tuo team di ingegneria.
4. Rendi visibili le impostazioni dei flag di funzionalità
Dovrebbe essere facilmente visibile quale combinazione di impostazioni dei flag di funzionalità è attiva per uno specifico utente. Questo dovrebbe essere memorizzato sia nel profilo utente all’interno del tuo database, sia nel tuo sistema di analytics.
Ciò può essere molto utile per l’assistenza clienti quando deve risolvere problemi segnalati. Può anche risultare utile per analizzare i diversi comportamenti degli utenti con diverse impostazioni. È essenziale quando si analizzano i risultati di un A/B test.
5. Elimina i flag obsoleti
I flag di rilascio e di esperimento, per definizione, servono solo temporaneamente. Dopo il rilascio completo di una nuova funzionalità controllata da flag o dopo il completamento di un esperimento, pianifica sempre la rimozione del flag come ultimo passaggio. In questo modo non accumulerai debito tecnico nel codice e la tua gestione dei flag di funzionalità resterà ordinata e facile da comprendere.
6. Evitare le dipendenze tra flag
Ogni flag dovrebbe avere uno scopo specifico, indipendente da qualsiasi altro flag. Per le flag di autorizzazione, ciò significa che il codice deve essere abbastanza modulare da poter attivare diverse funzionalità in qualsiasi combinazione.
Se sono necessari più flag per abilitare un determinato caso d’uso, o questi entrano in potenziale conflitto con altri flag, la configurazione delle flag può diventare confusionaria e, prima o poi, si verificheranno problemi con l’esperienza degli utenti.
7. Usa gli switch delle funzionalità per evitare rami di codice
Durante la discussione dell’implementazione di una funzionalità più ampia nel team di prodotto, si valuta come suddividere lo sviluppo software in parti più piccole. In questa fase, è fondamentale considerare anche l’utilizzo di una feature flag.
Implementando un flag e lasciandolo spento, si evita la creazione di rami funzionali a lunga durata. Invece, il codice della nuova funzionalità può essere fuso e rilasciato continuamente senza essere esposto agli utenti in una pipeline CI/CD (integrazione continua / consegna continua) o in una distribuzione Agile. Questo migliora l’integrità della base di codice poiché non si hanno processi di merge grandi e complicati e gli eventuali conflitti vengono subito identificati.
Inoltre, dissocia il rilascio del codice dalla visualizzazione delle modifiche agli utenti finali come spiegato al punto 8.
8. Usa le feature flag per piccoli rilasci di test
I rilasci di grandi nuove funzionalità tendono ad essere stressanti e rischiosi, ma è possibile affrontare la questione esponendo prima la funzionalità a un piccolo gruppo di utenti, monitorando gli effetti e tornando indietro se necessario.
Se si è utilizzata una feature flag per fondere e rilasciare costantemente il proprio codice prima di esporlo al pubblico, come raccomandato al punto 7, si ha già lo strumento per ottenere questo risultato.
Quando la nuova funzionalità è pronta, attivala nell’ambiente di produzione per mostrarla solo ai tester interni, poi a una piccola percentuale di clienti (detto canary release), poi all’intera base utenti.
Ad ogni passo, monitora le metriche chiave. Se qualcosa va storto in qualsiasi momento, puoi semplicemente disattivare il flag e indagare sul problema senza lo stress di un rollback complicato.
Il seguente caso di studio mostra un esempio di riduzione dei rischi durante una grande riprogettazione di un prodotto.
Caso di studio - Feature flag nella riprogettazione di Guardian Soulmates
Quando lavoravo come product manager per Guardian Soulmates (la piattaforma di dating in abbonamento del Guardian all’epoca), ci siamo trovati di fronte a due sfide: un sito mobile sotto la media e un’identità visiva datata. Abbiamo deciso di affrontare la transizione verso un sito reattivo e rebrandizzato in due fasi.
Diciamolo chiaramente: ai clienti generalmente non piace il cambiamento, specialmente a quelli paganti. Un rebranding è un’attività importante che può creare molte interruzioni.
Abbiamo discusso su come raggiungere al meglio i nostri obiettivi di sostituire il sito mobile e implementare il nuovo branding, minimizzando le interruzioni per i nostri abbonati. La soluzione scelta è stata un processo in due fasi che coinvolgeva due feature flag:
- Flag per il layout responsive: questa flag è stata utilizzata per permetterci di mostrare qualsiasi pagina sia in layout responsive sia nel layout desktop esistente (il sito mobile separato rimaneva invariato finché non eravamo pronti a lanciare completamente il nuovo sito mobile).
- Flag per il nuovo branding: Questa flag ci ha permesso di mostrare l’intero sito sia con la vecchia sia con la nuova identità visiva.
Flag per il sito responsive
Dopo aver creato un framework responsivo, abbiamo migrato pagina dopo pagina al nuovo layout. Se stai lavorando su qualcosa di simile, questi strumenti per il prototipaggio di design responsive possono aiutarti a testare e iterare i layout prima della pubblicazione.
Per ogni pagina migrata, il flag della funzionalità responsive veniva attivato prima per un piccolo gruppo di utenti, dando loro la possibilità di lasciare feedback.
Dopo alcuni giorni, la pagina responsive veniva resa disponibile a tutti gli utenti. Questo processo si ripeteva fino a quando l’intero sito diventava responsive.
Successivamente, il sito mobile è stato sostituito dal nuovo sito responsive. L’impatto sugli utenti desktop è stato minimo, perché le pagine erano state migrate in modo incrementale.
Le interruzioni per gli utenti mobile sono state poche, dato che in quel periodo non avevamo molti utenti da mobile (il vecchio sito mobile non era molto valido!).
Flag per il rebranding del sito responsive
Dopo il rilascio del sito responsive, la feature flag per il nuovo branding ci ha permesso di alternare l’intero sito tra il vecchio e il nuovo marchio.
Gli sviluppatori hanno implementato sul sito un pulsante per cambiare branding a livello utente, permettendo a designer, QA e anche a me come product manager di vedere i progressi.
Le pagine ridisegnate venivano rilasciate in modo continuo, ma nell’ambiente live il flag rimaneva spento cosicché nessun utente vedesse le nuove pagine brandizzate.
Quando tutte le pagine erano pronte, abbiamo inserito un pulsante sul sito per permettere agli utenti di aderire a un'anteprima pubblica del nuovo branding. Questo pulsante attivava il nuovo branding per l'utente. Gli utenti hanno potuto darci feedback e dopo una settimana abbiamo attivato il nuovo branding per tutti.
L'intero processo è stato completamente indolore sia per il team di sviluppo che per i nostri clienti. È stato un ottimo esempio di utilizzo dei feature flag per ridurre i rischi durante un importante restyling del sito.
Se sei interessato a capire più nel dettaglio quello che abbiamo fatto, puoi trovare un articolo sul progetto di restyling di Soulmates nel blog di ingegneria del Guardian.
Considerazioni finali
Imposta correttamente il framework iniziale e scoprirai che usare i feature flag può aumentare notevolmente la flessibilità e l’efficienza del tuo prodotto.
Dovresti anche considerare di usare i feature flag per iniziative più grandi al fine di ridurre al minimo i rischi, così come un piano di gestione dei rilasci per garantire un rollout senza intoppi. Puoi anche utilizzare l’intelligenza artificiale nella gestione dei rilasci per creare questo piano. L’unico limite all’uso dei feature flag è la tua immaginazione!
Raccontaci nei commenti eventuali modi ingegnosi in cui hai utilizzato i feature flag nel tuo prodotto.
Se desideri altri consigli e suggerimenti per migliorare le tue competenze di product management, iscriviti alla nostra newsletter.
Ottieni l’aiuto di un altro Product Manager nel tuo team con questa guida utile: Come creare una job description efficace per Agile Product Manager (+Esempio)
Da non perdere anche:
