Introducción
Su servicio de tickets debe añadir un nivel de urgencia sin perder las solicitudes existentes. Un despliegue del esquema puede fallar si las filas antiguas no cumplen una regla nueva. Creará una migración ordenada, la probará localmente y aplicará el mismo archivo de forma remota, conservando las identidades y los asuntos de los tickets.
Este laboratorio comienza de forma independiente con una migración inicial proporcionada. Se supone que conoce la creación de bases de datos y el SQL básico de D01, pero no se utiliza ninguna máquina virtual ni base de datos anterior.
Utilice su propia cuenta de aprendizaje y una VM nueva. La configuración prepara Node.js 22.22.0 y después ejecuta npm install para instalar Wrangler 4.131.1 local al proyecto y cualquier dependencia de evaluación en /home/labex/project/ticket-database. Las versiones de las dependencias directas están fijadas; la instalación crea su propio archivo de bloqueo. Durante la configuración no se inicia ninguna sesión en la nube ni se realizan operaciones evaluadas en la base de datos. En una máquina personal, instale la misma versión de Wrangler con npm install --save-dev wrangler@4.131.1 en su proyecto.
Este ejercicio utiliza registros sintéticos pequeños dentro de las asignaciones gratuitas de D1. El uso existente de la cuenta cuenta para esas asignaciones. No necesita un dominio comprado. Conserve esta VM hasta comprobar tanto la eliminación de los recursos como el cierre de sesión.
Autorice esta VM y seleccione la cuenta
En este paso, conectará este terminal nuevo a su propia cuenta de aprendizaje. Iniciar sesión en el Dashboard por sí solo no autoriza la VM. El permiso de D1 permite crear bases de datos, modificar SQL y eliminar recursos. Revise la página de consentimiento real, incluido Background Access, antes de autorizar.
Abra el proyecto preparado e inspeccione la versión fijada de la CLI:
cd /home/labex/project/ticket-database
npx wrangler --version
Debe aparecer 4.131.1. Inicie la autorización mediante dispositivo; --device muestra un código para el navegador y --browser=false le permite elegir cómo abrirlo:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Abra en el navegador la URL mostrada, introduzca el código actual, confirme su cuenta de aprendizaje y los permisos, y autorice el acceso. Espere a que el terminal confirme que la operación se realizó correctamente. Nunca pegue contraseñas ni tokens en los archivos del proyecto.
npx wrangler whoami --json
Compruebe loggedIn: true y lea los valores name e id de la cuenta, incluso si solo aparece una cuenta. Copie el ID previsto en la configuración siguiente. La variable de shell siguiente utiliza 6 bytes aleatorios, es decir, 12 caracteres hexadecimales, para evitar colisiones con otros estudiantes. Un documento here-document escribe el JSON situado entre las líneas JSON; $RUN se expande dentro de ese contenido.
La barra invertida delante de $schema conserva esa clave JSON literalmente; $RUN sigue expandiéndose al nombre único de esta ejecución.
RUN=labex-c04-d03-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Sustituya YOUR_ACCOUNT_ID antes de ejecutar el bloque. Mantenga abierto este terminal para que RUN siga disponible. name identifica esta ejecución; account_id selecciona la cuenta que se utilizará para las operaciones en la nube. El archivo es JSON normal, que también es válido como JSONC. Escribir este archivo no despliega ningún Worker.
Establezca la base de datos de tickets existente
En este paso, preparará la versión existente de la base de datos de la aplicación. Una migración es un archivo SQL numerado que describe un cambio del esquema. Wrangler registra los nombres de los archivos aplicados en d1_migrations, de modo que las ejecuciones posteriores puedan distinguir entre el trabajo completado y el pendiente. La configuración proporciona 0001_initial.sql como versión antigua de la aplicación; usted creará la actualización.
Cree una base de datos temporal en la nube. --binding DB proporciona al código de la aplicación un nombre corto, --update-config registra su nombre real y su UUID en wrangler.jsonc, y --use-remote=false mantiene el desarrollo en local:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lea el nombre y el ID creados y, después, inspeccione el binding guardado:
cat wrangler.jsonc
La entrada DB debe indicar la base de datos de esta ejecución. Un binding es una conexión configurada entre el código y un recurso. Su UUID identifica la base de datos en la nube, mientras que --local utiliza una base de datos SQLite independiente en esta VM. Incluya siempre --local o --remote en los comandos SQL.
Lea el esquema antiguo antes de aplicarlo:
cat migrations/0001_initial.sql
Contiene dos tickets existentes y ninguna columna priority. Aplique la migración por separado a los destinos local y remoto, y confirme que se trata de la base de datos de este laboratorio cuando se le solicite:
npx wrangler d1 migrations apply DB --local
npx wrangler d1 migrations apply DB --remote
Inspeccione las filas y el estado de las migraciones aplicadas:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; SELECT name FROM d1_migrations ORDER BY id;"
Deben existir los dos tickets originales y la migración aplicada debe ser 0001_initial.sql. Una migración aplicada forma parte del historial: para los cambios posteriores, cree un archivo nuevo en lugar de editar ese historial.
Añada localmente una prioridad restringida
En este paso, asignará una prioridad predeterminada a los tickets existentes sin eliminar la tabla. ALTER TABLE ... ADD COLUMN modifica una tabla directamente. Una columna añadida que no admite valores nulos necesita un valor predeterminado útil para las filas antiguas. CHECK limita las prioridades a normal o urgent.
Cree la siguiente migración numerada:
npx wrangler d1 migrations create DB add_priority
En este proyecto nuevo, se crea migrations/0002_add_priority.sql. Compruebe ese nombre de archivo en la salida. Escriba el cambio en el archivo nuevo:
cat > migrations/0002_add_priority.sql <<'SQL'
ALTER TABLE tickets ADD COLUMN priority TEXT NOT NULL DEFAULT 'normal' CHECK(priority IN ('normal','urgent'));
SQL
Enumere las migraciones pendientes y, después, aplíquelas solo localmente:
npx wrangler d1 migrations list DB --local
npx wrangler d1 migrations apply DB --local
Los dos tickets existentes deben recibir normal. Añada un ticket urgente y consúltelo:
npx wrangler d1 execute DB --local --command "INSERT INTO tickets (id, subject, source, priority) VALUES (3, 'Service unavailable', 'local', 'urgent'); SELECT id, subject, priority FROM tickets ORDER BY id;"
Una prioridad fuera del rango permitido debe producir un error en lugar de introducirse silenciosamente en la tabla:
npx wrangler d1 execute DB --local --command "UPDATE tickets SET priority = 'critical' WHERE id = 3;"
Debe aparecer CHECK constraint failed; este error intencionado mantiene el ticket 3 con la prioridad urgent. Lea PRAGMA table_info(tickets) en la base de datos remota para comprobar que el esquema de la nube todavía es el antiguo:
npx wrangler d1 execute DB --remote --command "PRAGMA table_info(tickets);"
Todavía no existe priority en la base de datos remota. Que la migración local se complete correctamente no actualiza la nube.
Aplique de forma remota la migración probada
En este paso, desplegará en la base de datos remota el mismo archivo revisado. Compruebe el trabajo pendiente antes de confirmarlo:
npx wrangler d1 migrations list DB --remote
npx wrangler d1 migrations apply DB --remote
Solo 0002_add_priority.sql debe aparecer como pendiente. Las filas existentes se conservan. Añada un ticket urgente remoto y, después, inspeccione los datos y el historial de migraciones:
npx wrangler d1 execute DB --remote --command "INSERT INTO tickets (id, subject, source, priority) VALUES (3, 'Service unavailable', 'remote', 'urgent'); SELECT id, subject, priority FROM tickets ORDER BY id; SELECT name FROM d1_migrations ORDER BY id;"
Los tickets 1 y 2 deben conservar sus asuntos y tener la prioridad normal; el ticket 3 debe tener la prioridad urgent. Deben estar registrados los dos nombres de archivo numerados. Ejecute la aplicación una vez más:
npx wrangler d1 migrations apply DB --remote
Debe indicar que no hay migraciones pendientes y dejar las filas sin cambios. Por eso es importante la tabla de historial: volver a ejecutar el despliegue no vuelve a ejecutar los archivos completados. En el Dashboard, abra la base de datos D1 de esta ejecución e inspeccione la vista del esquema o de las tablas para relacionar la nueva columna con el resultado de la CLI. No edite allí el esquema.
Este ejemplo muestra los dos tickets originales con la prioridad predeterminada normal y el nuevo ticket remoto con prioridad urgent. El nombre generado de la base de datos identifica esta ejecución de ejemplo; el tuyo será distinto. Las consultas SQL, el historial de migraciones y las comprobaciones de restricciones anteriores confirman el resultado; la captura es una referencia visual.
Elimine los recursos temporales
En este paso, eliminará únicamente los recursos de este laboratorio mientras la VM todavía está autorizada. Termine primero todas las comprobaciones funcionales. Conserve la configuración hasta completar la verificación de la eliminación.
npx wrangler d1 delete DB
Inspeccione la confirmación y asegúrese de que solo se trata de la base de datos de esta ejecución. Después, enumere las bases de datos:
npx wrangler d1 list --json
El nombre y el UUID de la base de datos que registró deben estar ausentes en una respuesta correcta. Es posible que permanezcan otros recursos. Un error de autenticación o de red no permite sacar conclusiones: resuelva el problema de acceso y repita la consulta antes de continuar. Ejecute la verificación de este paso mientras todavía tenga la sesión iniciada.
Finalice la autorización de esta VM
En este paso, finalizará la autorización solo después de que la comprobación independiente de la eliminación se complete correctamente. El cierre de sesión elimina la autorización de Wrangler almacenada en esta VM; cerrar una VM por sí solo no limpia los recursos de la nube.
npx wrangler logout
npx wrangler whoami --json
Debe aparecer loggedIn: false. Esta consulta sin autenticación puede finalizar con un código distinto de cero; eso solo es correcto cuando la respuesta estructurada indica explícitamente que la sesión se cerró. Complete la verificación y, después, cierre el entorno del laboratorio.
Resumen
Practicó la migración de un esquema de tickets. Comprobó resultados observables de la base de datos, mantuvo explícitos la cuenta seleccionada y el estado local, y eliminó los recursos temporales antes de cerrar la sesión.
