Notas de versión de feature flags: qué decir, y cuándo
6 min de lectura
Cerrar el ciclo de una solicitud de función asume un momento limpio en el que la cosa se lanzó. Un feature flag elimina ese momento, y por eso las notas de versión de feature flags son tan difíciles de sincronizar. El código se fusiona, el flag existe, y durante días o semanas después la función está a la vez viva en producción e invisible para casi todos los que podrían querer usarla, incluyendo, a menudo, a la persona que la pidió originalmente. Avisar demasiado pronto la lleva a toparse con una función que todavía no está ahí. Avisar demasiado tarde hace que el ciclo que se suponía iba a generar confianza se lea, en cambio, como olvidado.
¿Por qué un flag rompe la secuencia habitual de “lanzarlo, avisar”?
Porque divide un evento en al menos dos: el código volviéndose vivo, y el flag activándose para una cuenta concreta. Todo proceso para cerrar un ciclo de feedback asume que esas dos cosas pasan juntas, lo cual es cierto para la mayoría de los lanzamientos y falso para cualquier cosa controlada por un flag usado para despliegue escalonado, segmentación o como interruptor de emergencia. Cerrar el ciclo de feedback del cliente describe avisarle a quien pidió la función justo en el momento en que se aprueba y publica una entrada de changelog; ese paso está escrito para el caso en que publicar la entrada y que la función sea usable son el mismo momento, y un flag es exactamente el caso en que no lo son.
| Momento | Qué es cierto | ¿Debería avisarse ya a quien lo pidió? |
|---|---|---|
| Código fusionado, flag apagado en todas partes | La función existe, nadie puede usarla | No |
| Flag activado para la cuenta de quien lo pidió | La función existe, esa persona específica puede usarla | Sí |
| Flag activado para un porcentaje de despliegue que la excluye | La función existe, esa persona todavía no puede usarla | No |
| Flag eliminado por completo, la función simplemente está activa | La función existe para todos | Sí, si aún no se avisó |
¿Cuál es la regla real para saber cuándo avisar a alguien?
Avisar cuando el flag está activado para su cuenta, no cuando el código se fusiona ni cuando se crea el flag. Esa única regla cubre cada fila de la tabla de arriba, porque ata el aviso al único hecho que realmente le importa a quien lo pidió: si puede, en este momento, ir a usar la cosa. Un aviso atado a la fusión o a la creación del flag es en realidad un reporte de avance de ingeniería, y quien pidió una función no quiere un reporte de avance, quiere saber cuándo ir a mirar.
¿Eso significa que quien lo pidió necesita acceso anticipado o especial?
No necesariamente, y forzarlo crea su propio problema. Si el flag se está desplegando gradualmente por razones de carga o estabilidad, mover una cuenta al frente de la cola solo para cerrar un ciclo más rápido socava la razón por la que el despliegue está escalonado en primer lugar. Las opciones honestas son: esperar a que la cuenta de quien lo pidió llegue al despliegue de forma natural y avisarle entonces, o, si la urgencia lo justifica, activarle el flag antes de forma deliberada, como una decisión real de quien sea dueño del despliegue, no como efecto secundario de querer mandar un aviso.
¿Y si el flag es un interruptor de emergencia, no un mecanismo de despliegue?
Entonces la suposición segura se invierte. Un flag pensado para poder desactivar rápidamente una función, en vez de escalonar su lanzamiento, suele significar que la función está pensada para estar completamente activa en cuanto se crea, y el flag existe por seguridad, no por secuencia. En ese caso, avisar a quien lo pidió en el momento del despliegue es correcto, igual que en cualquier lanzamiento sin flag; la existencia del flag es un detalle operativo que no debería cambiar cuándo se cierra el ciclo. La distinción que importa es para qué está el flag, no si existe uno.
¿El flag cambia lo que deberían decir las notas de versión de feature flags?
Cambia cuándo se publica, no lo que contiene. Una entrada publicada en el momento en que el flag está activo para el 100 % de las cuentas se lee exactamente como una entrada de changelog normal, y así debe ser; quien la encuentre después no tiene motivo para saber que alguna vez hubo un flag de por medio. Lo que no debería hacer es publicarse mientras el flag solo está activo para un pequeño porcentaje de despliegue, porque una entrada pública de changelog manda a todo el que la lea, incluyendo cuentas sin el flag, a buscar una función que no van a encontrar, lo cual es una versión peor del mismo problema, a escala de todo el producto en vez de a escala de quien lo pidió. Esa regla de tiempos es toda la diferencia entre las notas de versión de feature flags y una entrada normal: el contenido es el mismo, solo cambia la fecha de publicación. Cómo escribir notas de versión cubre la disciplina de “no se necesita ninguna acción” que también aplica aquí: hay que decirle a quien lee si esto le aplica a ella, no solo que existe en algún lugar.
¿Los emails de novedades del producto deberían tratar distinto a una función con flag?
Sí, sobre todo retrasándola en vez de reescribirla. La plantilla de email de novedades del producto cubre las notificaciones dirigidas frente a los resúmenes amplios; una función con flag es un caso en el que el momento de una notificación dirigida hay que verificarlo contra el propio estado del flag de quien la recibe antes de enviarla, algo que un resumen amplio no puede hacer fácilmente en absoluto, lo cual es una razón más por la que un resumen es el canal equivocado para cualquier cosa que sigue a mitad de despliegue.
FAQ
¿Debería decirle a quien lo pidió que su función “está por llegar” en cuanto el flag existe pero no está activo para ella? Solo si hay una fecha real y cercana adjunta, y aun así con moderación. Un “está por llegar” sin fecha se lee, pasado suficiente tiempo, igual que el silencio, y crea una segunda promesa que también hay que rastrear y cumplir.
¿Quién decide cuándo un flag está lo bastante avanzado como para cerrar el ciclo? Quien sea dueño del despliegue, no quien sea dueño de la notificación. Quien tiene el despliegue sabe si el “100 % de las cuentas” está a punto de llegar o todavía a semanas; atar el paso de cerrar el ciclo a su estado, en vez de a una fecha fija de calendario, mantiene honesto el aviso.
¿Una función tras un flag permanente (que nunca se elimina del todo) llega a tener una entrada pública de changelog? Sí, en cuanto alcanza lo que sea que “disponibilidad general” signifique para ese producto, aunque el flag en sí se quede en el código para siempre por razones operativas. La entrada de changelog trata sobre la disponibilidad para quien lee, no sobre el detalle de implementación de cómo se logra esa disponibilidad.
¿Y si el flag se elimina y la función se mata en lugar de lanzarse? Eso es un rechazo, no un aviso de lanzamiento, y merece el mismo cuidado que cualquier otro rechazo. Cómo rechazar una solicitud de función cubre qué debe decir ese mensaje; cerrar el ciclo con honestidad a veces significa cerrarlo con un no.
¿Las notas de versión de feature flags necesitan una plantilla distinta de una entrada normal? Ningún cambio de plantilla, solo un paso de verificación antes de publicar: comprobar el estado del flag para la cuenta que preguntó, no solo que el código se fusionó, y retener la entrada hasta que esa comprobación pase. Todo lo demás sobre la entrada, la redacción, la longitud, la disciplina de FAQ, sigue igual que en cualquier otra nota de versión.
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.