Saltar al contenido principal

Despliegue

Cada repositorio trae su script en deploy/deploy.ps1:

.\deploy\deploy.ps1 -Ambiente prod

El orden importa: los módulos primero, el portal al final​

El portal resuelve en caliente la URL de su API y la del remoteEntry.js de cada módulo consultando Cloud Run, y las hornea dentro de su bundle. Si el módulo no está desplegado no hay URL que resolver y el script aborta antes de construir nada.

Esa resolución es el motivo de que el script exista. A mano es facilísimo publicar un portal de producción que carga el módulo de pruebas con un build que salió verde.

Antes de construir, el script comprueba que el remoteEntry.js del módulo responda de verdad. Un front servido sin la cabecera CORS, o construido sin el plugin de federación, devuelve 200 en la raíz y 404 ahí: el portal entonces carga bien y el módulo queda en blanco, que es el fallo más caro de diagnosticar de esta arquitectura.

El acento mata las variables de entorno​

Lo más caro que hemos aprendido

En Windows, ^ es el carácter de escape de cmd.exe. El delimitador personalizado de gcloud (--set-env-vars "^@^VAR=valor@OTRA=...") se lo come el intérprete antes de que gcloud lo vea.

El resultado: gcloud recibe una sola variable llamada @APP_ENV con todo lo demás pegado dentro. Cloud Run lo acepta, el despliegue sale verde, y el servicio queda enteramente sin configurar.

La solución es --env-vars-file con un YAML.

Ese modo de fallo —verde y roto— es el que conviene tener presente al revisar cualquier despliegue: que termine bien no prueba nada.

Y el archivo reemplaza TODO​

--env-vars-file sustituye el conjunto completo de variables, no agrega. Por eso, para cambiar una sola —el CORS, por ejemplo— hay que leer las actuales, modificar la que toca y volver a escribirlas todas. Los secretos se montan aparte y no traen valor: copiarlos en ese archivo los convertiría en variables vacías y el servicio perdería sus credenciales.

Lo que se comprueba después de desplegar​

Que el despliegue termine en verde no prueba que funcione. Lo mínimo:

# El API responde y llegó a la base
curl https://nx-api.ucic.pe/api/v1/salud

# Un login falso debe dar 422, no 500: prueba que consultó la base
curl -X POST https://nx-api.ucic.pe/api/v1/auth/ingresar \
  -H "Content-Type: application/json" \
  -d '{"usuario":"noexiste","clave":"xxxxxxxxxx"}'

# El remoteEntry del módulo responde Y trae la cabecera CORS
curl -I https://nexo-ti-frontend-7gdt5wryca-uc.a.run.app/remoteEntry.js

Y para el portal, comprobar contra el CSS y el JS que sirve producción —no contra lo compilado en disco— que las URLs horneadas son las correctas y que no quedan referencias a servicios viejos.

Tailwind falla en silencio

Tailwind genera solo las clases que encuentra escritas literalmente en el código. Una clase armada en tiempo de ejecución (`bg-${color}-100`) compila, despliega y sale sin color, sin un solo error en ningún lado.