Skip to main content

Pulisci i feature flag dopo il rilascio

Pianifica una sessione Devin una tantum per rimuovere un feature flag e il relativo codice morto dopo che il tuo rilascio si è stabilizzato.
AuthorCognition
CategoryAutomazioni
FeaturesPianificazioni
1

Pianifica la pulizia quando rilasci il flag

Hai appena distribuito un nuovo flusso di checkout dietro enable_new_checkout. È abilitato in produzione, ma vuoi una settimana di monitoraggio prima di impegnarti a rimuovere il vecchio codice. Invece di creare un ticket di cui ti dimenticherai, pianifica subito una sessione Devin una tantum — mentre il contesto è ancora fresco.Apri la pagina di creazione della pianificazione e imposta il tipo su One-time. Scegli una data successiva alla finestra di monitoraggio (ad es. il prossimo venerdì alle 9:00). Seleziona un canale Slack così il tuo team viene avvisato quando la sessione viene eseguita e la PR è pronta. Poi incolla il tuo prompt:
2

Rendi il prompt dettagliato

I feature flag si nascondono in posti inaspettati — file di configurazione, fixture di test, commenti, variabili d’ambiente. Più contesto inserisci nel prompt, più pulito sarà il risultato. Includi:
  • Come funzionano i tuoi flag — dove sono definiti e come vengono verificati (ad es. useFeatureFlag('name') in React, isEnabled('name') nei servizi backend)
  • Cosa non toccare — il framework dei flag rispetto al flag specifico (ad es. “non modificare src/lib/featureFlags/ — è il framework”)
  • Dove vivono il codice vecchio e quello nuovo — ad es. “il vecchio checkout è in src/pages/checkout/legacy/, il nuovo flusso è in src/pages/checkout/v2/”
  • Ambito della pulizia — anche i commenti, la documentazione, i file .env e le configurazioni CI che fanno riferimento al flag devono essere ripuliti
Un prompt con questo livello di dettaglio permette a Devin di tracciare ogni riferimento in un’unica passata — senza bisogno di un secondo giro di pulizia.
3

Rivedi la PR quando arriva

Quando si attiva la sessione pianificata, Devin traccia ogni utilizzo del flag all’interno della tua base di codice, mantiene il percorso di codice abilitato, rimuove il percorso disabilitato e il codice morto, ripulisce i test e apre una PR. Riceverai una notifica via email quando sarà pronta.Una PR tipica è simile a questa:
Removed feature flag: enable_new_checkout

- Deleted flag from src/config/featureFlags.ts (1 file)
- Removed 12 conditional branches across 7 files
- Deleted src/pages/checkout/legacy/ (4 files, 380 lines)
- Updated 3 test files — removed flag mocking, deleted old-path tests
- All 1,204 tests passing
Prima di eseguire il merge, verifica attentamente che nessuna logica di business dal vecchio percorso dovesse essere mantenuta — la gestione degli errori, gli eventi di analytics o i fallback per casi limite a volte vivono all’interno del ramo “disabilitato”.