Cómo añadí un modo nuevo a un publicador compartido sin cambiar nada a los demás sitios: claves opt-in, una foto de producción y una prueba golden byte a byte.
El punto de partida: un publicador, varios sitios
El blog de esta web lo publica un motor que escribe, revisa y sube los posts solo. Ese motor no es exclusivo de esta web: el mismo código de publicación sirve también a otros sitios míos, hoy en pausa. Hasta hace poco, todos funcionaban igual: el post entero se inyectaba como un bloque dentro de una única página de blog, con un ancla por artículo.
Para el SEO de esta web eso tenía un techo: veintiocho posts dentro de una sola URL compiten entre sí y ninguno tiene su propia página que posicionar. Quería "una URL por post". Los demás sitios no lo necesitaban, y ninguno debía cambiar por lo que necesitaba este.
Por qué opt-in y no un fork
Hay tres formas de meter un comportamiento nuevo en un código compartido, y solo una encaja cuando los demás no deben notar nada:
- Un fork del publicador. Es rápido el primer día y caro para siempre: cada arreglo futuro hay que llevarlo a dos copias, y acaban divergiendo sin que nadie lo decida.
- Cambiar el comportamiento para todos. Obliga a migrar sitios que no lo necesitan, con el riesgo de romper algo que no había que tocar.
- Un modo opt-in por cliente. El mismo código, con un comportamiento nuevo que solo se activa si la configuración de ese cliente lo pide. Sin las claves nuevas, todo sigue exactamente igual.
Por eso el modo nuevo es opt-in. La condición era dura: para los sitios que no activan nada, la salida tenía que ser idéntica byte a byte, no "equivalente".
Cómo quedó el opt-in
- Dos claves, las dos o ninguna. El modo página necesita dónde guardar los posts y qué plantilla usar. Si solo está configurada una de las dos, el publicador ignora el modo nuevo, avisa en el registro y publica como siempre. Prefiero un post publicado a la antigua que uno a medias.
- La plantilla vive en el repositorio del sitio, no en el bot. La cabecera, el pie y el diseño son del sitio. El bot solo rellena huecos: título, descripción, canonical, datos estructurados y artículo.
- El orden de escritura importa. Primero la página del post, luego el teaser en el índice del blog, luego el sitemap. Si falla la página, no se toca nada más. Si falla solo el sitemap, el post queda publicado y el fallo se registra.
- Un mapa de servicios relacionados. También en la configuración: según la categoría o el título, cada post enlaza al servicio que le corresponde.
Cómo demostré que los demás no cambiaban
Antes de tocar una línea, hice un commit con el estado exacto que había en producción. Esa foto era la referencia.
Encima monté una prueba golden: el mismo post de prueba pasa, en cada escenario, por el publicador viejo (sacado de esa foto) y por el nuevo, contra un GitHub simulado que registra cada escritura. Se comparan todas: qué fichero, con qué mensaje, contra qué versión y con qué contenido. Cuatro escenarios, que cubren los tipos de sitio que existen: uno con datos estructurados en el índice, uno antiguo sin ellos, uno multidioma con el blog en una subcarpeta, y esta misma web antes de activar nada. Los cuatro dieron idéntico.
Sin las claves, el código nuevo se comporta igual que el viejo: eso es lo que prueba el golden. El cambio real llegó al añadir las claves en la configuración cifrada de este cliente y reiniciar el servicio, y la vuelta atrás era restaurar la configuración anterior.
La segunda vez, con lo aprendido
Poco después volví a tocar el mismo publicador: datos estructurados más completos en cada post (autor, editor, imagen y las preguntas frecuentes como FAQPage). El mismo patrón: tres claves opt-in, valores por defecto que reproducen lo de antes, y el golden de los cuatro escenarios otra vez idéntico.
Esa segunda vez encontré un hueco en mi propia red: el golden no cubría el modo página, porque cuando lo escribí ese modo no existía. Hice una comprobación puntual del modo página sin las claves nuevas, contra el código anterior, antes de dar el cambio por bueno; meterla en el golden como escenario fijo sigue pendiente. La suite del módulo pasó de 445 a 451 tests en verde.
Lo que cuesta este enfoque
- Las ramas se acumulan. Cada opt-in es un "si está configurado, haz esto". Con dos o tres es manejable; con quince, el publicador sería un laberinto. Toca revisarlos y, cuando todos los clientes usan un modo, convertirlo en el comportamiento por defecto.
- La configuración pasa a ser código. Una clave mal escrita cambia el comportamiento en producción. Por eso las claves inválidas se ignoran con aviso en vez de romper, y por eso añadir una clave sigue un procedimiento con copia de seguridad previa.
- Más trabajo antes de empezar. La foto de producción y el golden llevan tiempo. Es el precio de poder decir "a los demás no les ha cambiado nada" con una prueba en la mano, y no con un "no debería".
Este es el tipo de sistema que construyo: piezas compartidas que sirven a varios casos sin copiarse, y cambios que se pueden activar y deshacer sin miedo. Si tienes un proceso así, lo vemos en sistemas personalizados.
Daniel · Arquitecto Digital. Los sistemas los diseño y dirijo yo; la implementación la hago con asistentes de IA de programación.