Entornos de desarrollo, staging y producción: por qué y cómo separarlos

Cuando un proyecto crece, trabajar directamente sobre el sitio en vivo deja de ser una opción. Un error de dedo puede tirar la tienda, perder datos o mostrar información privada. La solución estándar es tener tres entornos separados: desarrollo, staging y producción. Cada uno tiene un propósito claro y reglas propias.

¿Qué hace cada entorno?

• Desarrollo: corre en tu laptop (por ejemplo con Laragon, XAMPP o Docker). Aquí programas, experimentas y rompes cosas sin miedo. Los datos son de prueba y nadie se entera si algo explota.
• Staging: es una copia lo más parecida posible al sitio real, pero en un dominio separado como staging.tusitio.com. Sirve para probar con un equipo, mostrar avances al cliente o validar integraciones con servicios externos antes de tocar producción.
• Producción: el sitio real que usan tus clientes. Aquí solo entra código que ya pasó por los otros dos. Nunca editas archivos a mano, nunca instalas plugins directamente, nunca pruebas nada nuevo.

Por qué no basta con uno solo

Si haces cambios directo en producción, cualquier bug afecta usuarios reales. Si trabajas solo en local, no detectas problemas que aparecen únicamente en el servidor (permisos, rutas absolutas, versiones de PHP distintas). Staging es el puente: permite reproducir el entorno real con datos ficticios y validar antes del lanzamiento.

Bases de datos separadas

Cada entorno necesita su propia base de datos. Nunca conectes tu máquina local a la base de producción, aunque sea "solo para revisar". Un DELETE mal escrito puede arruinarte el día. Una configuración típica sería:

• Desarrollo: MySQL local con datos de ejemplo.
• Staging: una base en el servidor con un dump reciente de producción (anonimizando correos y datos personales).
• Producción: la base real, con acceso restringido a las personas estrictamente necesarias.

Variables de entorno con .env

La técnica más limpia para manejar credenciales distintas en cada entorno es usar un archivo .env. En lugar de escribir la contraseña de la base en el código, guardas cosas como:

APP_ENV=production
DB_HOST=localhost
DB_NAME=tienda_prod
DB_USER=tienda
DB_PASS=supersecreto
MAIL_DRIVER=smtp

Luego tu aplicación lee esas variables al arrancar. El archivo .env nunca se sube al repositorio, pero sí se incluye un .env.example con las claves pero sin valores, para que cualquiera sepa qué configurar.

Sincronizar cambios entre entornos

El código viaja siempre en una sola dirección: desarrollo → staging → producción, usando Git. La base de datos, en cambio, viaja en dirección contraria cuando necesitas datos realistas: producción → staging → desarrollo, usando dumps (mysqldump) y scripts que anonimizan datos sensibles.

Separar entornos toma un poco más de tiempo al principio, pero te ahorra semanas de apagar incendios en el futuro. Es una de esas prácticas que, una vez adoptadas, ya no querrás soltar.