Qué nadie te cuenta sobre pasar código de desarrollo a producción
ProducciónBackendDevOpsDesplieguePython

Qué nadie te cuenta sobre pasar código de desarrollo a producción

7 min de lectura30 de marzo de 2026

En desarrollo funciona perfecto; en producción, a veces no. Problemas reales: concurrencia, diferencias de base de datos, memoria, permisos y variables de entorno — y qué hacer antes de desplegar.

Una de las situaciones más frustrantes en desarrollo de software es esta:


En desarrollo funciona perfecto. Lo subes a producción… y deja de funcionar.


Si has trabajado en backend, data pipelines, microservicios o sistemas con base de datos, seguramente te ha pasado. Y no una vez, muchas.


Este artículo no es sobre teoría, sino sobre los problemas reales que aparecen cuando algo funciona en local pero falla en producción.


1. Desarrollo no es producción (aunque debería parecerse)


En local normalmente tienes:


  • Tu ordenador rápido
  • Tu base de datos pequeña
  • Un solo usuario
  • Sin latencia
  • Sin concurrencia
  • Sin workers
  • Sin colas
  • Sin límites de memoria

    • En producción tienes:


  • Múltiples usuarios
  • Concurrencia
  • Workers (Gunicorn, Uvicorn, etc.)
  • Bases de datos grandes
  • Locks
  • Problemas de memoria
  • Problemas de red
  • Problemas de permisos
  • Versiones distintas de librerías
  • Variables de entorno diferentes

    • Es decir, son dos mundos distintos.


    Por eso algo que funciona en desarrollo puede romperse completamente en producción.


    2. Problemas típicos que solo aparecen en producción


    Concurrencia


    En desarrollo todo funciona porque hay un solo proceso.


    En producción:


  • Dos procesos escriben a la vez
  • Dos procesos crean la misma tabla temporal
  • Dos procesos actualizan el mismo registro
  • Aparecen race conditions

    • Errores típicos:


  • Table already exists
  • Deadlocks
  • Registros duplicados
  • Datos inconsistentes

    • Solución:


  • Locks
  • Tablas temporales con nombre único
  • Transacciones
  • Idempotencia

    • Diferencias de base de datos


    Muy común:


  • En desarrollo usas MySQL 8
  • En producción MySQL 5.7
  • O distintas collations
  • O distintos charset

    • Y aparece el famoso error:


    Illegal mix of collations


    Esto en desarrollo no aparece porque todo está en utf8mb4_general_ci y en producción no.


    Solución:


  • Siempre definir charset y collation en tablas
  • No depender de la configuración por defecto del servidor

    • Problemas de memoria


    En local todo funciona. En producción:


  • Worker timeout
  • Worker killed
  • Segmentation fault
  • Killed (OOM)

    • Porque:


  • El servidor tiene menos RAM
  • Hay varios workers
  • Tu proceso consume mucha memoria
  • Estás cargando modelos de IA en cada request
  • Estás leyendo archivos gigantes en memoria

    • Solución:


  • Caché
  • Cargar modelos una vez
  • Streaming en lugar de cargar todo en memoria
  • Limitar workers
  • Profiling de memoria

    • Permisos


    El clásico:


    En local: todo funciona.


    En producción:


  • Permission denied
  • Cannot write file
  • Cannot create log
  • Cannot access folder

    • Porque el usuario que ejecuta la app en producción no tiene permisos.


    Solución:


  • Revisar usuario de ejecución (www-data, ubuntu, etc.)
  • Permisos de carpetas
  • Logs
  • Archivos temporales

    • Variables de entorno


    Otro clásico:


    En local tienes .env.


    En producción:


  • Falta una variable
  • La URL es distinta
  • La password es distinta
  • El endpoint es distinto
  • El modo DEBUG cambia cosas

    • Solución:


  • Validar variables al arrancar la app
  • No asumir que existen

    • 3. El mayor error: probar poco en entorno parecido a producción


    Muchos problemas aparecen porque:


  • Solo probamos con pocos datos
  • Solo probamos con un usuario
  • No probamos concurrencia
  • No probamos con la base de datos real
  • No probamos procesos largos

    • Producción no rompe el código, rompe las suposiciones.


    4. Cosas que deberías hacer siempre antes de subir a producción


    Checklist real:


  • Logs bien puestos
  • Manejo de errores
  • Timeouts
  • Reintentos
  • Transacciones en DB
  • Validación de variables de entorno
  • Pruebas con muchos datos
  • Pruebas con concurrencia
  • Pruebas con copia de la DB de producción
  • Monitorización (CPU, RAM, tiempo de respuesta)

    • Esto evita muchas noches sin dormir.


    5. La lección más importante


    Después de muchos despliegues, errores raros y cosas que “no deberían pasar”, la conclusión es esta:


    En desarrollo el código tiene que funcionar. En producción el sistema tiene que sobrevivir.


    Son dos objetivos distintos.


    En producción importan más:


  • Los logs
  • Los timeouts
  • La concurrencia
  • La memoria
  • La base de datos
  • La red
  • Los reintentos
  • La estabilidad

    • Que el propio código en sí.


    Conclusión


    Pasar de desarrollo a producción no es solo hacer deploy.


    Es pasar de un entorno controlado a un entorno hostil:


  • Usuarios reales
  • Datos reales
  • Carga real
  • Errores reales

    • Y ahí es donde se nota la diferencia entre:


  • Código que funciona
  • Y sistemas que aguantan

    • Compartir artículo
    María Gargoles

    María Gargoles

    Full Stack Developer & SysAdmin