Blog
El fin de «en mi máquina funciona»: DevOps hasta producción
«En mi máquina funciona» suele ser verdad. El desarrollador ha ejecutado la aplicación, ha probado la parte modificada y no ha visto ningún error. El problema es que su portátil no es producción. Utiliza otro entorno de ejecución, una base de datos local con pocos registros, configuración propia, acceso rápido a las dependencias y ningún tráfico real de usuarios.
Cuando un despliegue depende de la memoria del equipo y de pasos manuales, la distancia entre esos dos mundos aumenta con cada versión. Llega un momento en que nadie puede asegurar qué llegó exactamente al servidor, en qué se diferencia producción de las pruebas ni si el cambio se puede revertir sin riesgo.
DevOps organiza precisamente este espacio. No es el nombre del puesto de quien administra servidores ni una colección de herramientas de moda. Es una forma de trabajar en la que desarrollo, infraestructura y operaciones forman un único proceso de entrega. El resultado esperado es sencillo: un cambio sigue un recorrido previsible desde el repositorio hasta el usuario y el equipo puede observar su comportamiento después de publicarlo.
Por qué un portátil y producción se comportan de forma distinta
Un fallo posterior al despliegue rara vez se debe únicamente al código. Lo habitual es que el código encuentre en producción condiciones que no se habían probado:
- otra versión del runtime, de una librería o de un paquete del sistema,
- una variable de entorno ausente o un secreto desactualizado,
- una base de datos mucho mayor y consultas más lentas,
- peticiones simultáneas, colas y tareas en segundo plano,
- límites de memoria, CPU, disco o conexiones a la base de datos,
- otra configuración de red, proxy, DNS o certificados,
- una API externa con límites o tiempos de respuesta distintos,
- una versión anterior de la aplicación que sigue activa durante un despliegue gradual.
Todas estas diferencias son normales. El riesgo aparece cuando permanecen ocultas y nadie se hace responsable de ellas. Un proceso maduro no intenta que el portátil imite producción hasta el último detalle. Crea mecanismos que detectan pronto las diferencias relevantes.
Un proceso definido en lugar de instrucciones recordadas
Un despliegue manual suele empezar de forma inocente: entrar en el servidor, descargar el código, cambiar la configuración, ejecutar una migración y reiniciar el servicio. Al cabo de unos meses aparecen excepciones, comandos adicionales y conocimiento crítico que solo conserva una persona.
Un pipeline de CI/CD registra ese proceso de forma repetible y versionada. Después de un cambio, el sistema ejecuta los pasos acordados: compila la aplicación, comprueba formato y tipos, ejecuta pruebas, analiza dependencias, crea un artefacto y lo despliega en el entorno adecuado cuando se cumplen las condiciones de aceptación.
La automatización no elimina las decisiones. Elimina la variación accidental. Si una publicación requiere aprobación humana, esa aprobación es una parte visible del proceso. Si una corrección urgente puede saltarse una parte del recorrido habitual, queda claro quién puede autorizarlo y qué controles habrá que completar después.
El mismo artefacto en todos los entornos
Una de las reglas más útiles consiste en construir la aplicación una sola vez. El artefacto —por ejemplo, una imagen de contenedor o un paquete firmado— se crea en un proceso controlado, supera las pruebas y llega exactamente igual a staging y a producción.
Volver a construir para cada entorno introduce una incógnita innecesaria. El registro de paquetes puede devolver una dependencia más reciente, puede cambiar la imagen base o la herramienta de compilación puede usar otra configuración. El equipo termina probando un conjunto de archivos y desplegando otro.
Los entornos pueden diferir en escala y configuración, pero el código debe tener el mismo origen. Un identificador de versión presente en logs y monitorización permite saber qué commit atendió una petición y qué pipeline lo produjo.
Infraestructura descrita como código
Si un servidor se configuró manualmente hace dos años, su estado real suele diferir de la documentación. Alguien añadió una regla de red durante un incidente, otra persona cambió un parámetro de la base de datos y el entorno de pruebas nunca recibió esos cambios.
Infrastructure as Code permite describir redes, servicios, permisos y parámetros de infraestructura en un repositorio. Cada modificación puede revisarse, conserva su historial y se comprueba antes de aplicarla. Un entorno nuevo se crea a partir de la misma definición en lugar de reconstruirlo con instrucciones incompletas.
No es necesario convertir todo a código desde el primer día. El mayor beneficio inicial suele estar en los elementos críticos y los que cambian con frecuencia: configuración del despliegue, recursos de cómputo, red, bases de datos, políticas de acceso y monitorización.
Configuración y secretos sin copiar archivos
El código debe ser común; la configuración depende del entorno. Las direcciones de bases de datos, claves de integraciones, límites y opciones funcionales no deberían estar incrustados en la aplicación ni guardados en un archivo privado del portátil de quien despliega.
En la práctica separamos tres elementos:
- código y valores predeterminados no secretos en el repositorio,
- configuración versionada para cada entorno,
- contraseñas, tokens y claves en un sistema de gestión de secretos.
El acceso a un secreto debe limitarse a un servicio y un entorno concretos, quedar auditado y poder rotarse sin reconstruir la aplicación. Un desarrollador no necesita credenciales de producción para su trabajo local habitual.
Las pruebas deben proteger los recorridos importantes
Tener muchas pruebas no garantiza una publicación segura. Importa más saber si los controles cubren los lugares donde un fallo tendría mayor coste para el negocio.
Un recorrido razonable antes del despliegue comprueba varias capas:
- pruebas unitarias para la lógica de negocio,
- pruebas de integración para bases de datos, colas y servicios externos,
- pruebas de contrato entre API,
- una comprobación breve de un recorrido crítico, como iniciar sesión, comprar o enviar un formulario,
- análisis de dependencias y controles básicos de seguridad,
- prueba de arranque del artefacto en un entorno próximo al destino.
También conviene vigilar la duración del pipeline. Si el resultado tarda una hora, el equipo empieza a evitar el proceso o acumula demasiados cambios en una sola versión. Recibir información pronto forma parte de la calidad.
La migración de la base de datos forma parte del despliegue
Revertir el código suele ser relativamente sencillo. Deshacer un cambio incompatible en los datos puede ser mucho más difícil. Por eso, una migración no debería consistir en un comando manual ejecutado después del despliegue.
Un patrón seguro mantiene la compatibilidad entre versiones consecutivas. Primero se añade la nueva estructura sin eliminar la anterior. Después se publica código capaz de trabajar durante la transición, se mueven los datos y solo tras confirmar la estabilidad se retiran los campos antiguos. En tablas grandes hay que comprobar cuánto duran los bloqueos y qué impacto tendrá la migración sobre el tráfico real.
Cada migración necesita una persona responsable, un plan de observación y una respuesta prevista si se interrumpe. Un archivo down por sí solo no es una estrategia de rollback, especialmente si la nueva versión ya ha escrito datos con un formato diferente.
El despliegue no termina cuando el pipeline aparece en verde
Un pipeline en verde confirma que sus comprobaciones han terminado correctamente. No demuestra que los usuarios puedan completar lo que necesitan.
Después de publicar observamos, como mínimo:
- porcentaje de errores y tiempos de respuesta,
- consumo de recursos y estado de las dependencias,
- resultado de las operaciones de negocio clave,
- colas, tareas en segundo plano e integraciones,
- diferencias respecto a la versión anterior.
Logs, métricas y trazas deben relacionar un evento con una versión de la aplicación y una petición concreta. Una alerta debería avisar de un síntoma importante para el servicio, no de cualquier oscilación técnica. De lo contrario, el equipo deja pronto de confiar en las notificaciones.
Versiones más pequeñas reducen el área de búsqueda
Desplegar decenas de cambios a la vez dificulta las pruebas, la revisión y el diagnóstico. Cuando algo falla, el equipo primero debe averiguar qué parte del paquete causó el problema.
Las publicaciones pequeñas y frecuentes reducen ese espacio. Los feature flags permiten entregar código sin activar de inmediato una función para todos. Un canary release o un rollout gradual dirige inicialmente una pequeña parte del tráfico hacia la nueva versión. Si los indicadores empeoran, el proceso puede detenerse antes de afectar a toda producción.
El rollback también debe ser una operación habitual y ensayada. No representa un fracaso del equipo. Es un mecanismo de seguridad que permite recuperar el servicio rápido y analizar la causa sin la presión de una incidencia abierta.
La responsabilidad continúa después del desarrollo
El caos entre desarrollo y producción suele tener una raíz organizativa. El equipo que crea una función optimiza la velocidad de entrega, mientras operaciones asume el coste de logs poco claros, límites ausentes y procedimientos de emergencia difíciles.
Una buena definición de terminado incluye el comportamiento en producción. Un servicio nuevo dispone de monitorización, dashboard, alertas, dependencias documentadas y un runbook básico. También se sabe quién responde ante un problema y quién puede decidir un rollback.
Esto mejora la conversación operativa. En lugar de pasar una incidencia entre equipos, todos trabajan con la misma imagen del estado del servicio. El incidente termina con un análisis del proceso y de los controles, no con la búsqueda de quien hizo el último commit.
Por dónde empezar a ordenar el delivery
No hace falta implantar una plataforma DevOps completa en un trimestre. En una aplicación existente conviene comenzar por reconstruir el proceso real de publicación e identificar dónde depende de trabajo manual.
Un buen plan inicial incluye:
- documentar cada paso desde el merge hasta una versión operativa,
- señalar las diferencias entre desarrollo, staging y producción,
- automatizar la construcción y las pruebas esenciales,
- introducir un artefacto versionado e inmutable,
- ordenar configuración, secretos y accesos,
- añadir observabilidad y verificación posterior al despliegue,
- preparar y ensayar el rollback.
El progreso puede medirse con el lead time de un cambio, la frecuencia de despliegue, el change failure rate y el tiempo necesario para recuperar el servicio. Las cifras no son un objetivo por sí mismas, pero muestran pronto si el proceso se vuelve más ágil y seguro.
«En mi máquina funciona» puede iniciar el diagnóstico
La diferencia entre un portátil y producción nunca desaparecerá por completo. Sí puede estar controlada, documentada y visible. Un DevOps maduro aporta un proceso común, evidencias de controles automáticos y datos sobre el comportamiento de la aplicación después del despliegue.
El resultado no es solo publicar más veces. La empresa espera menos por cada cambio, sufre menos regresiones y recupera antes el servicio cuando aun así surge un problema.
Si los despliegues dependen de una persona, no cuentan con un rollback fiable o terminan con comprobaciones manuales en producción, conviene empezar por revisar el proceso de delivery. Con nuestro servicio de Socio IT ayudamos a ordenar CI/CD, entornos, monitorización y responsabilidad operativa sobre las aplicaciones.