Skip to main content

Limpiar feature flags después del lanzamiento

Programa una sesión única con Devin para eliminar una feature flag y su código muerto después de que tu versión se estabilice.
AuthorCognition
CategoryAutomations
FeaturesSchedules
1

Programa la limpieza cuando publiques la flag

Acabas de desplegar un nuevo flujo de checkout detrás de enable_new_checkout. Está habilitado en producción, pero quieres una semana de monitoreo antes de comprometerte a eliminar el código antiguo. En lugar de crear un ticket que olvidarás, programa ahora una sesión única de Devin, mientras el contexto está fresco.Abre la página de creación de programación y configura el tipo como One-time. Elige una fecha posterior a tu ventana de monitoreo (por ejemplo, el próximo viernes a las 9 a. m.). Selecciona un canal de Slack para que tu equipo reciba una notificación cuando se ejecute la sesión y el PR esté listo. Luego pega tu prompt:
2

Haz que el prompt sea exhaustivo

Las feature flags se esconden en lugares inesperados: archivos de configuración, fixtures de pruebas, comentarios y variables de entorno. Cuanto más contexto incluyas en el prompt, más limpio será el resultado. Incluye:
  • Cómo funcionan tus flags: dónde se definen y cómo se verifican (por ejemplo, useFeatureFlag('name') en React, isEnabled('name') en servicios de backend)
  • Qué no se debe tocar: el framework de flags en sí frente a la flag específica (por ejemplo, “no modifiques src/lib/featureFlags/ — ese es el framework”)
  • Dónde viven el código antiguo y el nuevo: por ejemplo, “el checkout antiguo está en src/pages/checkout/legacy/, el flujo nuevo está en src/pages/checkout/v2/”
  • Alcance de la limpieza: comentarios, documentación, archivos .env y configuraciones de CI que hagan referencia a la flag también deben limpiarse
Un prompt con este nivel de detalle permite que Devin rastree todas las referencias en una sola pasada, sin necesidad de una barrida posterior.
3

Revisa el PR cuando llegue

Cuando se ejecute la sesión programada, Devin rastreará todos los usos de la flag en tu base de código, conservará la ruta de código habilitada, eliminará la ruta deshabilitada y el código muerto, limpiará las pruebas y abrirá un PR. Recibirás una notificación por correo electrónico cuando esté listo.Un PR típico se ve así:
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
Antes de hacer merge, verifica que ninguna lógica de negocio de la ruta antigua debería haberse conservado; a veces el manejo de errores, los eventos de analítica o las rutas de fallback para casos extremos viven dentro de la rama “disabled”.