Contratos y versionado

Cuando dos equipos despliegan por separado, ninguno ve el código del otro. El contrato (una descripción de la interfaz, por ejemplo OpenAPI) es lo que ambos acuerdan. Comparar la versión nueva con la anterior en cada cambio detecta qué rompe a los consumidores, y las pruebas de contrato con los consumidores reales comprueban que lo que esperan sigue cumpliéndose.

Un cambio puede romper por razones de compatibilidad (quitar un campo) o por razones de seguridad (devolver de más). Los dos tipos necesitan revisión.

Las herramientas de comparación de contratos clasifican cada diferencia como compatible o incompatible. Un cambio incompatible rompe a quien lo consume sin avisar: se añade un campo obligatorio a la petición, se cambia un tipo, se elimina una operación. Contar cuántos hay decide si basta con una versión menor o hace falta una versión mayor con migración.

Abre contratos/comparacion-pagos-v2-v3.txt. La salida está escrita a mano para este laboratorio.

Un cambio que añade un campo a la respuesta es compatible: ningún consumidor deja de funcionar. Pero si el campo es un dato personal, la respuesta empieza a entregar más de lo que antes entregaba a todos los consumidores, incluidos los que no lo necesitan. La herramienta lo clasifica por compatibilidad y no por sensibilidad: la lectura de seguridad la hace una persona.

Retirar una versión es seguro cuando nadie la usa. La política de Tienda Yopo es que cada consumidor migra por su cuenta y el equipo de pagos avisa al responsable registrado. Eso falla justo con quien no está en el registro: nadie lo avisa y su tráfico sigue ahí.

Abre trafico/consumidores-pagos.csv y la política de versiones.

El retiro de la v2 está fijado a fin de año. El consumidor con más tráfico en v2 no tiene equipo registrado, así que ni siquiera recibió el aviso. Apagar la v2 ese día interrumpiría un sistema que alguien usa; aplazar sin fecha convierte la v2 en una API que nunca se retira.