The latest articles on DEV Community by Pedro J. Manrique (@pedrinquitico). https://dev.to/pedrinquitico https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4186642%2Fff29a6c3-7882-41cd-8754-25b2c4e4241f.png https://dev.to/pedrinquitico en Pedro J. Manrique Fri, 16 Oct 2026 10:47:04 +0000 https://dev.to/pedrinquitico/el-endpoint-devolvia-200-y-nadie-podia-terminar-la-compra-50ag https://dev.to/pedrinquitico/el-endpoint-devolvia-200-y-nadie-podia-terminar-la-compra-50ag <p>Un despliegue puede pasar todas las comprobaciones y fallar donde más importa.</p> <p>Imaginad una tienda con un checkout nuevo. El jueves a las 18:40, CI termina en verde. Los tests cubren el endpoint de pago: petición válida, respuesta 200 y registro creado. El equipo cierra la tarea.</p> <p>El viernes a las 9:12 llegan las primeras quejas. En escritorio, la compra funciona. En un móvil con pantalla pequeña, el botón final queda tapado por el aviso de cookies. Quien no había aceptado ese aviso no puede pulsar «Pagar». El servidor responde perfectamente a una petición que muchos usuarios nunca consiguen enviar.</p> <p>A las 10:05 soporte tiene siete tickets y desarrollo sigue viendo una API sana. El dato que faltaba no estaba en la monitorización del backend: era la diferencia entre «el servicio responde» y «una persona completa la operación».</p> <p>Para una función crítica, el criterio de aceptación debería incluir al menos un recorrido real desde la pantalla que usa el cliente, en los tamaños y estados más comunes. También conviene medir intentos iniciados frente a operaciones terminadas, no solo errores HTTP.</p> <p>En <a href="https://reglasnoescritas.com" rel="noopener noreferrer">reglasnoescritas.com</a> se habla mucho de estos temas, no de una forma superficial, sino en profundidad y aportando conocimiento real aplicable. Emails cortos, de un tema diferente cada día, de esos que dices -esto me suena XD-</p> <p>¿Qué comprobación os ha descubierto más fallos así: un test end to end, una sesión con usuarios o comparar el embudo antes y después del despliegue?</p> frontend mobile softwareengineering ux Pedro J. Manrique Thu, 15 Oct 2026 12:41:15 +0000 https://dev.to/pedrinquitico/el-despliegue-salio-bien-hasta-que-alguien-pidio-repetirlo-5h8o https://dev.to/pedrinquitico/el-despliegue-salio-bien-hasta-que-alguien-pidio-repetirlo-5h8o <p>Un jueves a las 18:14 el equipo publica una versión sin errores. Las pruebas pasan, la web responde y el cliente felicita a quien hizo el despliegue. El viernes hay que repetirlo en otro entorno. Esa persona no está.</p> <p>El comando está en el historial de su terminal. La variable que activó una función se añadió a mano. La cuenta que tiene permiso para publicar pertenece a alguien que ya cambió de proyecto. Nadie sabe si repetir exactamente los pasos sería seguro.</p> <p>El problema no es que falte documentación perfecta. Es que una operación crítica quedó reducida a la memoria de una persona.</p> <p>Un registro útil puede ser breve: versión exacta, requisitos previos, variables necesarias, quién autoriza, pasos para comprobar el resultado y cómo volver atrás. Si otra persona puede seguirlo sin llamar al autor, el despliegue deja de ser un truco personal y se convierte en una capacidad del equipo.</p> <p>En <a href="https://reglasnoescritas.com/" rel="noopener noreferrer">reglasnoescritas.com</a> se habla mucho de estos temas, no de una forma superficial, sino en profundidad y aportando conocimiento real aplicable. Emails cortos, de un tema diferente cada día, de esos que dices -esto me suena XD-</p> <p>¿Qué dato suele faltar en vuestros procedimientos justo cuando toca intervenir de verdad?</p> devops documentation productivity discuss