Desplegar no puede depender de que Bing conteste

Si tu proceso de publicar avisa a servicios externos —buscadores, sistemas de seguimiento de errores, mensajes al equipo— esta nota propone una regla para no quedarte sin poder publicar el día que uno de ellos se caiga.

La escena: hay que sacar una corrección urgente. El despliegue corre, compila, cambia el tráfico, y al final avisa a un buscador de que hay contenido nuevo.

Ese buscador contesta con un error temporal. El proceso termina en rojo.

¿Se desplegó? Sí, hace treinta segundos y perfectamente. Pero tu pantalla dice que falló, y quien esté mirando no sabe si tiene que volver a intentarlo.

Un despliegue en rojo por un tercero es peor que un despliegue en rojo de verdad: no sabes cuál de las dos cosas es.

La nuestra es estrecha y se puede comprobar: desplegar tiene que poder hacerse sin red hacia fuera y sin depender de que un tercero conteste.

Todo lo que el despliegue necesita —el código, las dependencias, la compilación, el cambio de tráfico— está dentro. Lo que hable con alguien de fuera va después, como paso aparte.

La prueba mental es fácil: si te cortan internet hacia fuera pero el servidor sigue en pie, ¿puedes desplegar? Si la respuesta es no, tienes un tercero dentro del camino crítico.

No siempre es evitable —hay que traerse el código de algún sitio, hay que instalar dependencias— y por eso la regla se aplica donde sí se puede: los avisos, las notificaciones, las métricas.

Separarlo no significa que alguien tenga que acordarse de ejecutarlo. Se encadena, y la forma de encadenarlo es la que importa.

En nuestro caso, la tarea programada hace dos cosas: primero despliega, y después avisa. Lo segundo va marcado de forma que su fallo no cuenta: si el aviso falla, la tarea sigue considerándose exitosa.

Clasificar cada paso en esa columna del medio es el ejercicio completo. Casi siempre hay uno o dos pasos al final que están ahí por comodidad y que están tumbando el resultado.

Hay una segunda razón para tenerlo fuera, y es de criterio más que de robustez.

Avisar a un buscador de que hay contenido nuevo tiene sentido cuando hay contenido nuevo que anunciar. No en cada subida de un retoque de estilos.

Siendo un paso aparte, se corre cuando toca. Metido dentro del despliegue, se dispara siempre, y acabas avisando cincuenta veces al mes de que tu sitio cambió cuando lo que cambió fue un margen.

Un canal por el que avisas de todo deja de ser un canal por el que avisas de algo. Vale para los buscadores y vale para el grupo del equipo.

Falta el detalle que evita que el aviso mienta con el tiempo.

El aviso necesita la lista de direcciones del sitio. Lo natural sería escribirla en el propio guion. Sería la tercera copia de la misma verdad, y la que nadie actualizaría.

En vez de eso, el guion se descarga el mapa del sitio —que ya se genera del manifiesto— y saca de ahí las direcciones. Preguntarle al mapa es preguntarle a la única fuente que hay.

Beneficio lateral: como hay que descargarlo, de paso se comprueba que el mapa está vivo. Si el sitio no respondiera, el aviso falla ahí y lo dice, en vez de mandar una lista de direcciones sacada de un archivo viejo.

La misma lógica se aplica a la llave de acceso: se saca del manifiesto y no se copia en el guion, porque dos sitios que deben cambiar juntos acaban divergiendo — y el día que no coincidan, el aviso se rechaza entero sin decir por qué.

• Haz la prueba mental del corte. Sin red hacia fuera, ¿puedes desplegar? Lo que te lo impida es un tercero en tu camino crítico.
• Clasifica cada paso por si su fallo debe tumbar todo. Los de después de publicar casi nunca deben.
• Encadénalos, pero marca los que no cuentan. Separar no significa que alguien tenga que acordarse.
• Avisa cuando haya algo que anunciar. Un canal que avisa de todo deja de avisar de algo.
• Que las listas salgan de una sola fuente. Una copia en el guion es la que nadie actualiza.