Cada versión que pasa sus controles sale a producción
· 4 min de lectura
Cuando publicamos una mejora, deberías tenerla en minutos, no cuando se alineen los astros. Hoy hemos reconstruido el último tramo de nuestra cadena de publicación en torno a esa promesa. Una versión que pasa su control de salud siempre te llega, y la red de seguridad que te protege de una mala versión solo salta cuando debe.
Lo que una versión tiene que demostrar
Nuestra cadena de publicación tiene una forma conocida. Construye la nueva versión, la arranca junto a la actual, comprueba que responde con buena salud y solo entonces la deja servir. Si la nueva versión falla ese control, una red de seguridad devuelve a los visitantes a la anterior.
Son dos promesas, no una. Una versión sana debe salir, y una enferma no. Esta semana, al publicar la nueva planificación de vídeos por sitio, revisamos las dos con lupa: la segunda era sólida y la primera se apoyaba en una suposición.
Queríamos que fuera imposible que una versión sana se quedara entre bastidores. Así que repasamos cada paso que decide adónde va el tráfico.
Una red de seguridad con un disparador preciso
Una red de seguridad vale lo que su disparador. La nuestra saltaba en cuanto cualquier paso anterior había fallado, incluidos pasos que ocurren antes de que una nueva versión sirva a nadie, como la propia construcción. En esos casos no hay nada que deshacer, e intervenir hace más mal que bien.
La ceñimos al único momento para el que existe: una nueva versión salió en línea y después falló su control de salud. Si un problema anterior impidió que ese control se ejecutara, la red se queda ahora al margen.
Probar el nuevo disparador con un control que fallaba a propósito nos enseñó dos matices, y corregimos ambos:
- El paso que recuerda qué versión está sirviendo elige ahora la que realmente lleva tráfico, no simplemente la primera de la lista.
- En GitHub Actions, una condición que no nombra ningún estado queda limitada en silencio al caso en que todo salió bien. Una condición de vuelta atrás debe escribir
failure()de forma explícita, o nunca podrá saltar cuando importa.
El tráfico va a la versión más reciente, siempre
La lección más profunda tenía que ver con cómo nuestra plataforma de alojamiento, Cloud Run, reparte el tráfico. Por defecto sirve la versión sana más reciente. Pero cuando diriges todo el tráfico a una versión con nombre, como hace una vuelta atrás, la plataforma recuerda esa elección y sigue sirviendo esa versión aunque lleguen otras más nuevas.
Es un comportamiento razonable, y significaba que nuestra cadena no podía suponer sin más que la versión más reciente era la que estaba sirviendo.
Así que añadimos el paso que convierte la suposición en garantía. Al final de cada despliegue, la cadena le pide a la plataforma que sirva la última versión. Pase lo que pase antes, una vuelta atrás, una prueba, un cambio manual, una publicación correcta termina con la versión que acabamos de publicar delante de ti. El reparto del tráfico pasó de ser una esperanza a algo que cada despliegue afirma.
Construcciones limpias, siempre
Esa misma semana ajustamos otro detalle. Nuestras versiones se construyen a partir de una copia limpia del código, no desde la máquina de un desarrollador, así que un cambio tiene que estar completo en el propio commit. Una importación de tipos que se quedó en la máquina mientras su función entraba en el commit nos mostró lo fácil que es pasarlo por alto.
El arreglo fue una línea de importación, y la costumbre que reforzó vale más. Antes de que salga un commit, lo comprobamos en una copia limpia, tal como lo verá la construcción, y no en una carpeta de trabajo llena de otros cambios.
Juntos, estos cambios hacen las publicaciones más tranquilas para todos:
- una construcción que no está lista nunca te llega,
- una versión sana siempre te llega,
- y una versión que tropieza después de salir se sustituye por la anterior en unos instantes.
Lo que significa para ti
No verás nada de esto, y de eso se trata. Cuando escribimos en este blog que algo salió hoy, está en línea hoy, para cada vídeo que hagas. La planificación por sitio que dio pie a este trabajo, ideas y listas de planos para cada web que añades, llegó a todo el mundo esa misma tarde.
Para quien gestiona su propia cadena, la lección es breve. Un mecanismo de seguridad también es código y merece las mismas pruebas que lo que protege, en la situación exacta para la que se escribió. Y una cadena en verde demuestra que los pasos se ejecutaron: haz que uno de esos pasos demuestre que la nueva versión es la que está sirviendo.
Sigue cada novedad en el momento en que sale en el blog.
Míralo en tu propia web
Pega una página y obtén el vídeo narrado del que habla este blog. El primero es gratis.
Sigue leyendo
