Come convincere gli sviluppatori a iniziare a usare le levette flag delle caratteristiche?

Supponendo che gli interruttori flag delle funzionalità siano una buona idea e dovrebbero essere implementati nel codice che gli sviluppatori scrivono. Ad esempio, Etsy lo giura come una parte importante della loro cultura .

Qual è un buon modo per persuadere (e imporre) agli sviluppatori di iniziare a usare gli interruttori flag delle funzionalità?

Ulteriori informazioni sui toggle dei flag delle caratteristiche sono spiegate in Q: Come usare i toggle dei flag delle caratteristiche , D: Cosa sono i toggle dei flag delle caratteristiche e molto ampiamente nell'articolo di Pete Hodgson sull'argomento sul blog di Martin Fowler .

Gli interruttori funzione sono una pratica comune nello sviluppo ad alta velocità perché disaccoppiano lo sviluppo dal rilascio. I team di sviluppo possono "rilasciare" una nuova funzionalità alla produzione, in uno stato disabilitato. Ciò consente di rilasciare la funzione in qualsiasi momento. Se la funzione dipende da altri lavori o preparazioni, non è necessario attendere che una versione principale passi alla produzione.

Per quanto riguarda gli sviluppatori "convincenti" ad usarli, questo è un esercizio per difendere la libertà che offre. La mia esperienza è che non è una vendita difficile per gli sviluppatori. È la gestione che tende a essere riluttante a provare nuove cose. Prova questo:

• Trova un framework di attivazione / disattivazione delle funzionalità. Il management / l'azienda potrebbe essere più propenso a provare qualcosa supportato da un sistema comune
• Inizia in piccolo. Introdurre il sistema di commutazione su una base di prova per una funzione che dimostrerà la sua utilità.
• Dimostrare la capacità del toggle di eseguire test A / B. Abilita l'interruttore per un sottoinsieme della tua Web farm, quindi raccogli le metriche sul comportamento. Piccole differenze nel layout della pagina hanno dimostrato di avere enormi effetti sulle entrate per le applicazioni al dettaglio (ad esempio Ebay, Amazon)

In un mondo ideale penso che lanci una nuova build e sorprenda! Niente cambia. Questo perché tutte le nuove funzionalità sono dietro interruttori che si spengono con l'interruttore spento.

Dopo l'implementazione, si verifica che il servizio implementato funzioni ancora, i telefoni non squillano più (a meno che il telefono che squilla non sia lo scopo dell'utente, vale a dire), ecc. Una volta tornati a un'operazione stabile nota, si inizia ad abilitare e verificare le funzionalità appena implementate.

Ora per la tua risposta: come ti piacerebbe lavorare in un team in cui essere di guardia è praticamente un gioco da ragazzi e i nostri utenti ci adorano perché i nostri siti e servizi sono stabili?

Questa è la squadra su cui voglio lavorare.

Puoi smettere di leggere qui se vuoi.

Mettere tutto dietro un interruttore di funzionalità sembra che possa portare a spaghetti code ovunque. Se si utilizza IoC e si è in grado di selezionare tra vNow / vNext / vPrevious, si tratta di mantenere la propria configurazione. Sì, più check-in, sì più classi (componentV1, componentV2, componentV3, ecc.) Ma in realtà hai un sistema più stabile? Come? vSuccessivo è traballante? Torna a vNow con la tua torre di controllo. È stata una settimana e vNow ha un bug sottile? Stessa cosa: torna a vPrevious altrettanto facilmente.

Nessun problema, nessuna preoccupazione, nessun sonno perso, nessuno stress.

Questo non è un sogno irrealizzabile. Lavoravo là. Vorrei poterlo vendere alla mia squadra attuale.

Un ambiente di sviluppo ad alta velocità di successo si basa in genere su un sistema automatizzato piuttosto rigoroso che prevede verifiche di qualità con rilevazione e rifiuto di modifiche errate che causano regressioni.

Gli interruttori di funzionalità offrono la possibilità di eseguire il commit anche di modifiche non testate in corso di lavoro senza essere rifiutate per aver causato regressioni nel ramo di integrazione. Il che costituisce un ottimo incentivo per introdurre la funzione attiva / disattiva molto presto nella vita della funzione.

Uno degli svantaggi della deviazione dall'IC reale e dello spostamento dello sviluppo delle funzionalità sui rami delle funzionalità è la mancanza di tale incentivo. L'aggiunta della funzione di attivazione / disattivazione in un secondo momento, quando l'unione del ramo di funzionalità nel ramo di integrazione è in genere più difficile, come qualsiasi integrazione tardiva.

Gli sviluppatori (e in genere i gestori dello sviluppo) di solito cercano due risultati associati al framework: facilità di gestione e velocità di implementazione. Vuoi spedire il codice più velocemente e più facilmente.

Fornire prove che l'approccio funziona; prova a costruire un piccolo POC usando i flag delle funzionalità rispetto al vecchio modo. I case study contano meno per le persone tattiche (sviluppatori \ ingegneri) che per le persone strategiche (middle management \ progettisti di prodotti).

La logica per avere le funzioni di attivazione / disattivazione non è qualcosa che gli sviluppatori possono decidere. Questo è qualcosa che interessa ai proprietari dei prodotti. Gli sviluppatori consentono questo cambiamento nel modo più sostenibile e sicuro. Critico proprio questa domanda.