
Marketing Online
3150. Píldoras de inteligencia artificial: Bases de datos de desarrollo y producción
Hoy os cuento cómo separo las bases de datos de desarrollo y producción para probar cambios sin poner en peligro los datos reales. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores , marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Hoy finaliza el curso de storytelling en crowdfunding . Esta mañana veremos las victorias y esta tarde los aprendizajes que cierran la historia. ¡A por él! Ahora sí, vamos al lío. Hoy es viernes y durante la edición de verano dejaré la publicación en abierto, pero todos los suscriptores encontraréis una skill relacionada con la píldora de hoy en la zona de descargas del campus. Cuando desarrolláis una aplicación, los archivos resultan fáciles de entender. Tenéis una copia en el entorno de desarrollo, realizáis los cambios, los probáis y finalmente desplegáis la versión nueva en producción. La base de datos plantea una decisión más delicada. ¿Debe el entorno de desarrollo conectarse directamente a la base de datos real o debe utilizar una base separada? Durante un tiempo utilicé una única base de datos por comodidad. Así, al abrir la aplicación local veía los usuarios, contenidos y datos más recientes. No necesitaba mantener dos copias ni preparar información de prueba. El problema aparece en cuanto el desarrollo modifica la estructura o escribe datos. Imaginad que una columna llamada nombre pasa a llamarse username . El código local ya conoce el cambio, pero el código publicado todavía busca la columna anterior. Como ambos entornos comparten la base de datos, producción deja de funcionar antes de que hayáis desplegado el código nuevo . Y ese es el caso amable. Una prueba puede borrar registros, ejecutar una migración incorrecta o alterar información de clientes reales. La comodidad deja de compensar rápidamente. Por eso recomiendo tener una base de datos para desarrollo y otra para producción . Además, conviene utilizar la misma tecnología en ambos lados. Si producción trabaja con PostgreSQL o Supabase, el entorno de desarrollo debería parecerse todo lo posible. Utilizar SQLite porque resulta sencillo puede ocultar diferencias que solo aparecerán al desplegar. Para disponer de datos realistas podéis generar periódicamente una copia o dump de producción hacia desarrollo. Pero hacedlo siempre en una sola dirección, conservad una copia de seguridad y anonimizad los datos personales o sensibles cuando no sean imprescindibles para la prueba. Los cambios de estructura deberían quedar definidos mediante migraciones repetibles. Primero se prueban en desarrollo y después se aplican de manera controlada en producción. Así el código y la base de datos evolucionan juntos y podéis saber exactamente qué transformación se ha realizado. También conviene recordar que Git protege el código, no el contenido vivo de una base de datos. Para los datos necesitáis copias de seguridad, snapshots , migraciones comprobadas y un procedimiento real de recuperación. Para facilitar este proceso he preparado una skill que explica al agente cómo separar ambos entornos, utilizar la misma tecnología y actualizar la copia de desarrollo sin poner en riesgo producción. Los suscriptores podéis descargarla desde la zona de descargas . Entregad el ZIP a vuestro agente, pedidle que lo revise y aplique las instrucciones al proyecto. Antes de ejecutar nada, comprobad qué datos copiará, dónde los guardará y cómo protegerá la información sensible. Espero que os sea útil para trabajar con datos realistas sin convertir cada prueba local en una operación sobre clientes reales. Separar desarrollo y producción requiere un poco más de preparación, pero evita sustos muchísimo más caros. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify , suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Es viernes, o sea que ya sabéis lo que toca: descansad, relajaros y recargad pilas, aunque estemos en pleno agosto. Regresamos el lunes con más y mejor: la edición de verano del podcast de Marketing Online. Como siempre, a las 07:07. Hasta entonces... ¡Muy buen fin de semana!

