Un pipeline verde demuestra que una secuencia técnica terminó. No demuestra que el usuario pueda completar el flujo, que los datos sean correctos ni que el equipo detecte una degradación. Confundir despliegue con entrega traslada el riesgo a producción.
Una release seria define antes de empezar qué debe comprobarse, quién observa el cambio y qué señal obliga a detenerlo o revertirlo.
Criterios de aceptación vinculados al flujo
Las pruebas deben describir comportamiento, no solo componentes. «El endpoint responde» es insuficiente si el resultado depende de permisos, datos, colas o una integración externa. El criterio útil recorre el camino que crea valor y los fallos que más daño producirían.
Los cambios de datos necesitan comprobaciones propias: migración aplicada, conteos coherentes, restricciones válidas y consultas críticas dentro del tiempo esperado.
Desplegar no significa exponerlo todo
Separar despliegue de activación reduce presión. Feature flags, canarios o activación por grupo permiten observar antes de ampliar. El tamaño del corte debe ser proporcional a la capacidad de detectar y responder.
Un canario sin métricas ni comparación solo retrasa el riesgo; no lo controla.
Observar señales técnicas y de producto
Errores, latencia y recursos son necesarios, pero también importan resultados de negocio: operaciones completadas, abandonos, rechazos, importes o estados incoherentes. La línea base debe existir antes del cambio para saber si una variación es real.
- Salud del servicio y dependencias.
- Errores por versión, ruta y cliente.
- Latencia de los flujos críticos.
- Procesamiento asíncrono y colas pendientes.
- Métricas de resultado y calidad de datos.
- Feedback de soporte y usuarios internos.
Rollback que incluya datos y configuración
Volver al contenedor anterior no siempre revierte una release. Migraciones, eventos emitidos, configuración y acciones externas pueden haber cambiado el estado. El plan debe especificar qué es reversible, qué requiere compensación y cuánto tiempo existe para decidir.
El rollback se prueba antes de necesitarlo. Si depende de improvisar comandos bajo incidente, es una intención, no una capacidad.
Cerrar con propiedad
La entrega termina cuando existe evidencia de aceptación, observación durante una ventana acordada, documentación del cambio y un responsable para el comportamiento posterior. Los hallazgos no bloqueantes se convierten en trabajo explícito; no desaparecen al cerrar la tarjeta.
Preguntas frecuentes
¿Todas las releases necesitan canario?
No. El mecanismo debe ser proporcional al riesgo. Un cambio pequeño y reversible puede usar validación directa; uno crítico necesita exposición limitada y criterios de parada.
¿Cuánto tiempo debe observarse una release?
Depende del ciclo del flujo. Debe cubrir el tiempo necesario para que aparezcan los efectos relevantes, no un número fijo de minutos.
¿Qué ocurre si una migración no puede revertirse?
Se diseña compatibilidad hacia atrás, expansión y contracción, o una acción compensatoria. Esa limitación debe conocerse antes de activar el cambio.