Tres orquestadores, un sueño de operador

Un explorador encuentra trabajo ya resuelto, un proceso nocturno construye en nueve repositorios, y un pase semanal integra una porción más amplia del portafolio — acotados, registrados y revisados cada mañana.

Read this in English

Durante trece noches seguidas, una de las líneas de producto en la formación nocturna no tuvo nada elegible para trabajar: todo lo que quedaba en su backlog estaba bloqueado por una decisión que solo yo podía tomar, y la corrida lo registró vacío cada vez. Eso no es raro en sí mismo — las líneas se quedan calladas cuando su backlog se vacía. El problema más grande estaba un nivel arriba: un proceso aparte, pensado para generar ideas de producto nuevas, se había estancado en seis de veinte desde finales de junio, y aun así seguía quemando una corrida completa cada noche, para nada.

El 18 de julio, ese proceso se retiró. En su lugar: algo más chico, más temprano y más acotado — un proceso cuyo único trabajo es encontrar cosas que valga la pena hacer antes de que los constructores despierten, y que nunca origina una idea propia.

Un sistema que alimenta al sistema

Corre a la 1:15am, cuarenta y cinco minutos antes que el primer constructor, y no escribe ni una línea de código. Lee lo que ya está resuelto en otras partes — un task tracker, los restos de los logs de corridas de noches anteriores, TODOs que ya están ahí, dentro de los mismos repos — y convierte todo eso en una cola corta y priorizada para la noche que sigue.

Cada ítem que encola lleva una etiqueta que dice exactamente de dónde salió. Sin fuente rastreable, no hay lugar en la cola — o va a una lista corta para que yo decida, o se descarta.

Dos relojes, dos trabajos

Dos procesos más corren en sus propios horarios.

El primero es nocturno, empieza a las 2am. Un puñado de trabajadores en paralelo lee la cola, más cualquier cosa que yo haya agregado o reordenado a mano — el explorador trabaja alrededor de esas ediciones, nunca por encima de ellas — y toman hasta cuatro piezas de trabajo acotadas, una por repositorio, lado a lado. Va primero, a propósito: lo que sea que rompa lo atrapan el build sweep y la revisión de CI unas horas después.

El segundo corre una vez por semana, antes del amanecer del sábado, sobre un modelo más capaz — el hermano más poderoso del nocturno, capaz de desplegar, y el único de los dos con permiso de acercarse a un despliegue en vivo, y aun así solo después de una verificación completa. Antes construía productos nuevos a partir de una lista de semillas; ese modo se retiró el mismo día en que se cortó el proceso de ideas estancado. Ahora solo integra lo que ya existe en todo el portafolio, más como mucho una porción que avanza algo que ya está en marcha — nunca un producto nuevo.

Cómo es en realidad una noche

Nueve repositorios están dentro del alcance del pase nocturno; en una noche completa, hasta cuatro se tocan en paralelo, cada uno por su propio trabajador, cada uno verificado de forma independiente en vez de tomarle la palabra — el proceso vuelve a correr el build y los tests por su cuenta y lee el diff, en lugar de confiar en el resumen que el propio trabajador hace de lo que hizo.

Los números se mantienen aburridos a propósito. Un build sweep del portafolio — 32 o 33 módulos según la noche — ha vuelto limpio, cero fallas, cada noche que se ha registrado. Una suite de tests pasó de 225 a 229 en una sola corrida: cuatro tests nuevos de casos límite y una extracción pequeña, nada dramático.

Los guardrails

Los límites son simples. Nada se pushea a ningún lado, nunca, sin que yo lo revise primero — cada commit queda local. Nada toca un secreto ni un sistema de pagos en vivo. Y la regla que más importa en la práctica: si un trabajador no está seguro de si algo es seguro, lo salta y lo dice, en vez de adivinar.

Esa regla se puso a prueba directamente. Un miércoles, el pase nocturno llegó a su cuarto repositorio y lo encontró parado en un branch que no era main — un commit por delante, el branch ya pusheado bajo un pull request abierto. Hacer commit del cambio de esa noche encima de eso habría metido trabajo no relacionado dentro de un PR sin terminar. Así que saltó el repo y registró exactamente por qué, citando la regla vigente: ante la duda, saltar.

Tres cosas, nunca más

Todo lo que la flota puede decidir sola, lo decide sola. Todo lo que no puede, queda esperándome a mí — con un tope de tres ítems, siempre.

Cada una de las tres viene con un brief de una página, siempre con la misma forma: cuál es la tensión real, varias rutas reales con sus tradeoffs, y una recomendación que no es una decisión en sí misma — puedo ratificarla, nombrar una ruta distinta, o escribir otra respuesta por completo. De las que se han cerrado hasta ahora — tres de ellas — he ratificado la recomendación todas las veces.

Algunas semanas la lista está vacía; ahora mismo lo está — nada esperándome. La revisión se mantiene simple: leer los logs de las corridas, ver qué se concretó, responder la lista de tres ítems si hay algo en ella.