Un martes por la mañana desplegamos un cambio pequeño en nuestra API. Renombramos un campo que nos parecía mal puesto. Técnicamente, una mejora. Media hora después, el equipo de facturación estaba en llamas: su integración con nosotros se había roto en producción y ni siquiera sabían que dependían de ese campo con ese nombre exacto.
Nadie actuó de mala fe. Ese es el punto. Hicimos un cambio razonable sin darnos cuenta de que al otro lado del contrato había personas que confiaban en nuestra palabra sin que nosotros supiéramos que la habían dado.
Una API es una promesa entre equipos. Y las promesas rotas, aunque sean por descuido, cuestan confianza, que es mucho más cara de reconstruir que cualquier campo.
Lo que cambiamos no fue solo técnico. Sí, empezamos a versionar en serio, a nunca romper hacia atrás sin un camino de migración, a tratar cada campo público como algo que alguien, en algún lado, ya está usando. Pero lo más importante fue empezar a hablar con quienes consumían nuestra API antes de tocarla.
Montamos algo sencillo: un canal donde anunciábamos cambios con antelación y un contrato escrito que ambas partes revisaban. La primera vez que el equipo de facturación pudo comentar sobre un cambio propuesto antes de que existiera, en vez de sufrirlo después, la relación entre los dos equipos cambió por completo. Dejamos de ser proveedores anónimos para ser compañeros.
También aprendimos a poner pruebas de contrato en el pipeline. No para blindarnos legalmente, sino para que la máquina nos avisara, con cariño y a tiempo, cuando estábamos a punto de romper una promesa. Un test que falla en el build duele infinitamente menos que un equipo entero parado en producción.
La integración entre sistemas es, en el fondo, integración entre personas. Los sistemas solo hacen lo que les decimos. Somos nosotros quienes decidimos si avisamos antes de cambiar las reglas, o si dejamos que el otro equipo se entere por el fuego.
– Sergey Shinder
Top comments (0)