Versiones que se comprueban solas antes de llegar a ti

Desde el primer commit, PageToVid tuvo una cadena que comprueba los tipos del código, construye un contenedor con todo lo que necesita un vídeo, del navegador al motor de vídeo, y lo despliega en Google Cloud Run. Esa velocidad es la que permite que una corrección encontrada un lunes por la mañana llegue a tu siguiente vídeo esa misma tarde.

A principios de julio la cadena hacía más. Cada versión arranca limpia, soltando todo lo que la anterior tenía conectado, para que nada viejo se quede en la nueva. Y la tarea que renderiza los vídeos se despliega desde la misma imagen con la que se construyó la web, así que el sitio y los renders siempre ejecutan el mismo código.

Cuando el último paso de una publicación salía bien, la tarea se ponía en verde. Pero el verde solo significaba que la plataforma había aceptado la nueva versión. No decía nada de tres cosas que de verdad nos importaban:

• si las visitas llegaban al código nuevo, y no a una copia guardada por una caché delante del sitio
• si la nueva versión podía hablar con su base de datos
• qué commit, exactamente, estaba respondiendo en ese momento

Una versión que no puede verse a sí misma es una suposición. Queríamos que cada publicación demostrara, desde fuera, que de verdad estaba sirviendo y de verdad estaba sana.

El primer paso fue la trazabilidad. Cada versión incorpora ahora su commit, su rama, su ejecución de la cadena y su hora de construcción en el servicio en marcha. Se ven en dos sitios:

• un punto de salud que informa del estado, el commit, una comprobación en directo de la base de datos y el tiempo en marcha, y que nunca se guarda en caché
• una cabecera de versión en cada respuesta del sitio

Cada versión en servicio lleva además el nombre de su ejecución y la etiqueta de su commit, así que cada versión corresponde a un único commit. Cuando un vídeo o una página se ve raro, la primera pregunta, qué código es este, tiene ahora respuesta en un segundo.

Tras el despliegue, la cadena consulta ahora ese punto de salud a través del borde de la red pública, el mismo camino que sigue una visita, saltándose la caché. Sigue preguntando hasta que la respuesta nombra el commit exacto que se acaba de desplegar y una base de datos que funciona. Si eso no ocurre a tiempo, la publicación falla.

Ir por el borde de la red y no por la dirección propia del servicio importa. Pone a prueba lo que tú alcanzas de verdad, incluido todo lo que hay delante de la aplicación. Una publicación solo está terminada cuando el mundo exterior la ve.

La comprobación de la base de datos importa por lo mismo. Una versión que arranca pero no llega a sus datos respondería a un simple ping y aun así fallaría en cada petición real. El punto de salud habla él mismo con la base de datos e informa del resultado, así que la comprobación lo detecta mucho antes que tú.

Cuando la comprobación falla, la cadena devuelve el tráfico de inmediato a la versión que estaba sirviendo antes. Nadie tiene que darse cuenta, despertarse ni escribir un comando: una versión que no puede demostrar que funciona, sencillamente no se queda. Cada ejecución termina con un breve resumen de lo que se desplegó, lo que vio la comprobación y lo que pasó después.

También conservamos la caché de construcción entre ejecuciones, lo que hace cada build nuevo mucho más rápido. Importa más de lo que parece. Cuanto antes se construye una corrección, menos cuesta volver atrás y reintentar, y antes llega la mejora a tus vídeos.

No ves nada de esto, y de eso se trata. Pegas un enlace y la página que responde es la versión que acaba de pasar su comprobación, conectada a sus datos y con el mismo código que el motor que grabará tu sitio. Cuando algo nuevo no está listo, la versión anterior sigue atendiéndote, sin pausa.

También nos permite mejorar PageToVid varias veces al día sin pedirte que esperes a una ventana de mantenimiento. Si construyes sobre PageToVid, la página para desarrolladores explica la API que funciona sobre esta cadena, o puedes simplemente crear un vídeo.