Once productos, un sistema de producción y el orden en que leemos las pruebas

Un estudio de este tamaño no puede sostener once productos haciendo once lanzamientos. Los sostiene porque las partes de un lanzamiento que son idénticas cada vez —material de tienda, listas de comprobación de publicación, la fontanería de las suscripciones, capturas de pantalla, documentos de privacidad, la propia tubería de publicación— se hacen una vez, en un sistema, en lugar de una vez por producto a mano.

Hasta aquí la mitad obvia, y no es la interesante. Compartir infraestructura es un intercambio bien entendido. La parte que sigue saliendo mal es saber qué es cierto de un producto que publicaste hace tres semanas.

Dos reglas que hacen que una automatización se pueda reiniciar

El trabajo en el sistema se identifica mediante un hash determinista de sus propias entradas. Un disparo duplicado, un reintento o un bloqueo con reinicio se resuelven todos a la misma identidad, así que el sistema no puede renderizar dos veces ni publicar dos veces. Esa única propiedad es lo que hace que reintentar sea seguro, y poder reintentar con seguridad es la diferencia entre una automatización que puedes dejar corriendo y una que alguien tiene que vigilar.

La segunda regla es que publicar queda detrás de una persona. No porque la automatización esté sin terminar, sino porque el coste de una publicación equivocada es asimétrico: una puerta que nunca se usa es barata, y una puerta que falta una vez no lo es. De este estudio no ha salido nada sin que alguien lo dijera.

El fallo que no es un error

El 30 de septiembre dos productos se publicaron en la App Store. Este sitio decía que uno de ellos estaba en beta y no figuraba públicamente en ninguna de las dos tiendas. Nada en este repositorio estaba mal, y ninguna revisión podría haberlo detectado, porque un lanzamiento es un suceso que ocurre fuera del repositorio: no cambia ningún archivo, así que no hay diff que leer ni test que pueda fallar.

Ese es todo el argumento a favor de una puerta previa al despliegue en lugar de una costumbre. Un script pregunta a Apple por cada identificador de paquete, lista todas las apps de la cuenta de desarrollador y pide a Google Play cada página de paquete. Se ejecuta antes de un despliegue, no cuando algo parece raro: porque cuando algo parece raro, ya ha parecido correcto durante tres días.

A qué documento creer

El mismo error se ha cometido ya siete veces en este estudio, y solo uno fue por descuido. Los otros seis tenían todos la misma forma: una afirmación tomada del documento narrativo de un proyecto mientras había pruebas legibles por máquina en la misma carpeta, más recientes, diciendo otra cosa.

Veyra es el ejemplo trabajado. Su página en este sitio decía que la generación nunca se había ejecutado y que nunca se habían cargado pesos de modelo. Eso venía de un documento de estado y de un readme, los dos fechados el 11 de septiembre, y se repitió aquí durante dos semanas. Mientras tanto, en el mismo repositorio, había un archivo extraído de un teléfono físico que registraba dos ejecuciones reales de generación: cuatro candidatos cada una, cada imagen de un tamaño distinto, etiquetadas con el modelo real, con tiempos leídos de la propia base de datos del dispositivo. La página subestimó su propio producto durante quince días, que es un fallo más amable que exagerarlo y sigue siendo una página falsa.

Así que el orden está escrito, y un rango inferior nunca prevalece sobre uno superior, por reciente que sea y por seguro que suene:

• Estado autenticado del proveedor — lo que dice la propia tienda, leído con la sesión iniciada.
• Artefactos publicados y pruebas legibles por máquina — los metadatos de una compilación de publicación, una base de datos extraída de un dispositivo, una respuesta capturada, una etiqueta.
• Código y configuración actuales — los archivos que la compilación carga de verdad.
• Documentos de aceptación fechados — prosa, pero escrita contra una ejecución que ocurrió.
• Narrativa de estado y de traspaso — un readme, un archivo de estado, un traspaso.
• Documentos de planificación y briefings — incluido el briefing que presentó un producto en este sitio.

La jerarquía no dice nada sobre quién escribe con cuidado. Dice algo sobre qué se deteriora. Una ficha de tienda cambia cuando cambia el producto; un readme cambia cuando alguien se acuerda.

Para qué sirve de verdad un sistema compartido

Todas las reglas de arriba empezaron porque algo concreto salió mal en un producto, y todas viven hoy en el sistema compartido y no en la copia que tenía ese producto. Ese es el interés compuesto real: no que el quinto lanzamiento sea más barato que el primero, aunque lo sea, sino que el quinto lanzamiento no puede repetir los errores de los cuatro anteriores, porque el error es un test que falla en un sitio que no pertenece a ninguno de los dos productos.