Quiz: Preguntas sobre Migraciones y Producción

Concepto clave

Las migraciones en Prisma ORM son el mecanismo para gestionar cambios en el esquema de tu base de datos de manera controlada y reproducible. Piensa en ellas como un sistema de control de versiones especifico para tu estructura de datos, similar a Git para tu codigo, pero aplicado al esquema de la base de datos. Cada migracion representa un cambio incremental (como agregar una tabla, modificar una columna o crear un indice) y se almacena como un archivo SQL que Prisma puede aplicar o revertir.

En produccion, este control es crucial porque evita que los cambios se realicen de forma manual y potencialmente erronea. Una migracion bien gestionada te permite desplegar cambios con confianza, saber exactamente en que estado esta la base de datos en cada entorno (desarrollo, staging, produccion) y tener la capacidad de rollback si algo sale mal. Sin migraciones, estarias en riesgo de drift de esquema, donde los entornos se desincronizan y causan fallos inesperados.

Como funciona en la practica

El flujo de trabajo tipico con migraciones de Prisma en un proyecto real sigue estos pasos:

1. Modificas tu archivo schema.prisma para reflejar el cambio deseado (ej., agregar un nuevo campo emailVerified a la tabla User).
2. Ejecutas npx prisma migrate dev --name add_email_verified en tu entorno local. Esto genera un nuevo directorio con un archivo SQL que contiene las instrucciones para aplicar ese cambio (ej., ALTER TABLE User ADD COLUMN emailVerified BOOLEAN DEFAULT false).
3. Prisma aplica la migracion a tu base de datos local automaticamente y actualiza el archivo _prisma_migrations que lleva el registro de las migraciones aplicadas.
4. Para llevar el cambio a produccion, incluyes los archivos de migracion generados en tu sistema de control de versiones (como Git). Durante el despliegue, ejecutas npx prisma migrate deploy en el servidor de produccion, que aplicara solo las migraciones pendientes de forma segura.

Este proceso asegura que el cambio se pruebe primero localmente y luego se propague de manera identica a produccion, minimizando riesgos.

Codigo en accion

Imagina que necesitas agregar un campo para rastrear la ultima vez que un usuario inicio sesion. Asi se ve el proceso en codigo:

Antes: El esquema original en schema.prisma:

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
}

Despues: Modificas el esquema para agregar el nuevo campo:

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
  lastLogin DateTime? // Nuevo campo opcional
}

Luego, ejecutas el comando de migracion. Prisma generara un archivo SQL como este:

-- Migration SQL
ALTER TABLE "User" ADD COLUMN "lastLogin" TIMESTAMP(3);

Este archivo se aplica a la base de datos, y ahora tu modelo y la base de datos estan sincronizados.

Errores comunes

• Modificar manualmente la base de datos en produccion: Esto rompe la sincronia con el esquema de Prisma y puede causar errores en futuras migraciones. Siempre usa migraciones para cualquier cambio.
• No probar migraciones en un entorno similar a produccion: Aplicar una migracion directamente en produccion sin probarla en staging puede llevar a tiempos de inactividad o perdida de datos. Configura un entorno de staging que refleje produccion.
• Olvidar incluir los archivos de migracion en el control de versiones: Si no los subes a Git, otros desarrolladores o el servidor de produccion no tendran los cambios, causando inconsistencias.
• Usar prisma db push en produccion: Este comando sincroniza el esquema directamente sin crear migraciones, lo que es peligroso porque no deja un registro para rollback. Reservalo solo para desarrollo temprano.
• Ignorar el manejo de datos existentes en migraciones: Al agregar un campo con un valor por defecto, considera como afectara a las filas existentes. Por ejemplo, si agregas un campo isActive con valor por defecto true, asegurate de que sea apropiado para todos los usuarios existentes.

Checklist de dominio

1. Puedo explicar que es una migracion en Prisma y por que es esencial en produccion.
2. Se ejecutar prisma migrate dev para crear migraciones locales y prisma migrate deploy para aplicarlas en produccion.
3. Entiendo la diferencia entre prisma migrate y prisma db push, y se cuando usar cada uno.
4. Puedo recuperarme de un error en una migracion usando prisma migrate resolve o revertiendo a una version anterior.
5. Se como estructurar migraciones que incluyan cambios de esquema y actualizaciones de datos (ej., usar SQL crudo en la migracion para poblar nuevos campos).
6. Puedo verificar el estado de las migraciones en produccion usando prisma migrate status.
7. Entiendo la importancia de probar migraciones en un entorno de staging antes de produccion.

Implementa y Despliega una Migracion Segura

En este ejercicio, practicaras el ciclo completo de una migracion en un entorno simulado de produccion. Sigue estos pasos:

1. Preparacion: Clona un repositorio de ejemplo (o usa tu propio proyecto) que tenga un esquema Prisma basico con una tabla Product. Asegurate de tener una base de datos local corriendo (ej., con Docker).
2. Cambio de esquema: Modifica el archivo schema.prisma para agregar un nuevo campo price de tipo Decimal a la tabla Product. Este campo debe ser obligatorio (? para opcional no se usa aqui) y tener un valor por defecto de 0.0.
3. Creacion de migracion: Ejecuta el comando para generar una migracion con un nombre descriptivo como add_price_to_product. Verifica que se cree un nuevo directorio con el archivo SQL.
4. Prueba local: Aplica la migracion a tu base de datos local usando el comando adecuado. Luego, escribe un script simple en Node.js que inserte un nuevo producto con un precio y lo lea para confirmar que el cambio funciona.
5. Simulacion de produccion: Crea una nueva base de datos (puede ser otra instancia local) para simular produccion. Ejecuta el comando para aplicar las migraciones pendientes a esta base de datos, imitando un despliegue real.
6. Verificacion: Usa prisma migrate status en ambas bases de datos (local y simulada produccion) para asegurarte de que estan en el mismo estado de migracion.

Entrega: Un breve informe con los comandos usados, capturas de pantalla del estado de las migraciones, y el codigo del script de prueba.

• Recuerda que para campos Decimal en Prisma, debes configurar el tipo de base de datos adecuado en tu esquema (ej., usar `Decimal` de Prisma se mapea a tipos como `DECIMAL` en SQL).
• Si encuentras errores al aplicar la migracion en la base de datos simulada de produccion, verifica que no haya migraciones aplicadas previamente que causen conflictos.
• Usa `npx prisma migrate dev --create-only` si quieres generar el archivo SQL sin aplicarlo inmediatamente, para revisarlo antes.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.