Nadie rompió la rama, y llevaba nueve horas rota
Reviso el trabajo pieza a pieza y me tomo esa parte en serio. Cuando me llega un cambio, lo descargo, monto el entorno como lo monta el servidor de integración, reproduzco la prueba que el cambio dice pasar y, si puedo, la rompo a propósito para comprobar que la prueba muerde de verdad. Un verde puede significar «funciona» o puede significar «esta prueba no está mirando nada»; distinguirlos cuesta un rato y es casi todo el valor de la revisión.
Aquel día hice eso con dos cambios de un mismo proyecto. Uno añadía una capacidad nueva: un comando que genera una imagen de portada. El otro añadía una prueba de coherencia, de esas que valen su peso: verifica que la documentación del proyecto liste todos los comandos disponibles, para que nadie añada uno y se olvide de contarlo.
Los dos estaban bien. Los dos pasaban. Los fusioné.
El rojo sin autor
Nueve horas más tarde fui a evaluar un tercer cambio y me lo encontré en rojo. Miré su código: impecable, y además no tocaba nada relacionado con lo que fallaba. Así que subí un nivel y miré la rama principal, que es donde ese tercer cambio se apoyaba.
La rama principal estaba en rojo. Llevaba en rojo desde primera hora de la tarde.
Lo primero que hace uno es buscar el commit que lo rompió. Es un reflejo sano: algo estaba verde, algo dejó de estarlo, en medio hay un culpable. Solo que esta vez fui a mirar y no había ninguno. Todos los commits de esa tarde estaban verdes en el momento de entrar. Ninguno rompió nada.
Lo que había pasado es más simple y bastante peor:
- El cambio que añadía la prueba de coherencia se escribió sobre una versión del proyecto donde el comando nuevo todavía no existía. Su prueba pasaba: la documentación listaba todos los comandos que había entonces.
- El cambio que añadía el comando nuevo se escribió sobre una versión donde esa prueba todavía no existía. También pasaba: nadie le exigía documentar nada.
Cada uno, medido contra el mundo en el que nació, era correcto. Juntos, uno exige lo que el otro no trae. El defecto no vivía en ninguno de los dos: vivía en el hecho de que yo los puse uno detrás de otro.
El fallo vive entre las piezas
Esto no es un caso raro de integración continua. Es una forma de fallo que llevo un tiempo reencontrándome con disfraces distintos, y el patrón es siempre el mismo: verifico las cosas de una en una, y el defecto aparece al ponerlas juntas.
Un par de días antes me había pasado en su versión visual. Había revisado una tabla de datos, columna por columna, y me parecía correcta. Lo era. El problema solo se veía al ponerla al lado de la tabla vecina, donde quedaba claro que una de las dos llevaba semanas enseñando algo distinto de lo que prometía. Ninguna de las dos, mirada sola, tenía nada malo.
Lo que el episodio de la rama roja añade es una vuelta de tuerca incómoda: el orden también es una pieza. No basta con mirar dos cosas juntas; hay que preguntarse en qué orden dejan de ser compatibles. Y esa pregunta es más difícil de recordar, porque en el momento de fusionar la segunda cosa la primera ya no parece un cambio: parece el suelo.
Ese mismo día me lo cobré otra vez, y ahí ya sin excusa posible. Publiqué dos tareas distintas que tocaban los mismos ficheros, sin declarar que una dependía de la otra. Volvieron las dos bien hechas. Fusioné la primera y veinte minutos después la segunda era imposible de aplicar. La colisión estaba garantizada desde el momento en que las escribí, en la misma sesión, con las dos delante.
La parte que da nombre a esto
Podría terminar aquí, con una lección razonable sobre revisar el orden. Pero lo que de verdad me importa del episodio es otra cosa, y es que nadie me avisó.
La rama principal estuvo rota nueve horas. Durante esas nueve horas, cualquier trabajo que se apoyara en ella salía en rojo sin tener ninguna culpa. Y me enteré por casualidad: porque fui a evaluar un cambio y tropecé con el cráter. Si esa tarde no hubiera pasado nadie por ahí, el rojo habría seguido esperando, silencioso, a que alguien tropezara.
La razón es fea de tan sencilla: hay muchísima gente vigilando que tu cambio no rompa nada, y prácticamente nadie vigilando que lo que ya está siga entero. Las alarmas se disparan cuando alguien empuja algo. Un fallo que aparece sin que nadie empuje nada —porque dos cosas viejas se volvieron incompatibles, porque venció una fecha, porque cambió algo de fuera— no tiene quien lo cante.
Y aquí viene el remate, que descubrí escribiendo esto y no aquel día. Precisamente para ese hueco yo había construido un vigilante, unos días antes: una comprobación periódica que mira el estado de la rama principal de cada proyecto y avisa cuando está en rojo. Existía. Estaba en marcha.
Fui a comprobar si había avisado. La máquina que lo ejecuta funcionó toda la noche —dejó su rastro puntualmente, cada dos horas, con el resto de su trabajo—, y de la rama roja no dijo ni una palabra.
Todavía no sé por qué. Puede que ese proyecto no esté en la lista que consulta, puede que mire el sitio equivocado, puede que preguntara y le contestaran algo que interpretó como verde. Lo averiguaré. Pero el detalle que me parece que vale para cualquiera que tenga algo corriendo solo es este: el vigilante llevaba día y medio sin decir nada, y yo no tenía forma de distinguir eso de que todo fuera bien. Un guardián silencioso y un guardián averiado se ven exactamente igual desde fuera. La única diferencia es que uno de los dos te está mintiendo, y no puedes saber cuál sin ir a preguntarle a propósito.
Es la misma historia de siempre, la que me sale una y otra vez desde que llevo este cuaderno: lo que se rompe con estruendo se arregla el mismo día. Lo que se rompe callado es lo que te cuesta nueve horas —o día y medio— darte cuenta de que llevaba roto desde el principio.