La base de datos en producción

Antes de empezar. La API ya trabaja con PostgreSQL y relaciones entre entidades; su entorno de pruebas está preparado en CI. Hoy conectarás la versión publicada a una base de datos persistente.

---

Se explica

25 minutos · explicación y demostración

Publicar el estado persistente

Servidor 19–22 ya ha preparado JPA, PostgreSQL y pruebas de repositorio. Hoy cambia su entorno: utilizamos el mismo backend y publicamos la base de datos que necesita. No reescribimos entidades ni consultas para Intermodular.

Distinguimos desarrollo, prueba/CI y producción. Cada uno tiene su propia base y configuración. La de CI se destruye al terminar; la pública conserva los datos de demostración. Un cambio de esquema debe quedar identificado y comprobado antes de aplicarlo sobre datos que queremos mantener.

Comprobar la oferta antes de crear

La oferta de Azure for Students establece requisitos de elegibilidad y límites por servicio. La documentación oficial contempla una cantidad gratuita de PostgreSQL durante un periodo limitado para las cuentas elegibles, sin garantizar que toda cuenta del alumnado tenga esa oferta activada. Debe verificarse la suscripción, la región, el tamaño, el almacenamiento y el coste estimado. Si la configuración no encaja, se emplea el recurso de aula acordado: la superación de la sesión no requiere la contratación de ningún plan. Condiciones y servicios de Azure for Students.

Configuración y esquema

Las credenciales reales se configuran en el proveedor; los nombres de variables y el procedimiento se guardan en el repositorio. Para producción seguimos la decisión de Servidor: esquema preparado y ddl-auto=validate. La creación automática update de desarrollo no se convierte en el procedimiento de actualización de producción.

Se trabaja

140 minutos · trabajo guiado sobre el producto compartido

Bloque A · Crear el servidor

Todos a la vez, a la misma pantalla

En portal.azure.com, localiza Azure Database for PostgreSQL y selecciona Servidor flexible (Flexible server) → Crear.

Configuración de red. En la pestaña de conectividad, selecciona acceso público y autoriza las direcciones de salida del App Service y la dirección IP del aula que requiera acceso. Revisa la conectividad configurada: habilitar el acceso a todos los servicios de Azure no restringe las conexiones a la propia suscripción.

Creación de la base de datos. Una vez aprovisionado el servidor, crea en él una base de datos con el nombre del proyecto. Una instancia de servidor puede alojar varias bases de datos; la aplicación establece la conexión con una de ellas.

Bloque B · La cadena de conexión como configuración externa

Trabajo individual, sin incorporar ningún valor al código fuente

En el App Service: Configuración → Variables de entorno. Declara tres variables nuevas:

Por qué sslmode=require no es opcional

El servidor rechaza las conexiones no cifradas. Si el parámetro se omite, el mensaje de error no identifica la ausencia de TLS como causa: informa únicamente de que la conexión no ha podido establecerse, lo que orienta el diagnóstico hacia la configuración del cortafuegos. Conviene retener este caso, porque el síntoma no señala la causa.

Contenido versionable. Ninguno de los valores anteriores se incorpora al repositorio. Sí se incorpora un archivo de ejemplo con los nombres de las variables y valores ficticios, de modo que quien clone el proyecto conozca qué configuración debe aportar. Esa distinción separa un proyecto reproducible por terceros de uno que solo se ejecuta en el entorno de su autor.

Bloque C · Creación controlada del esquema

1. En la base local de ensayo, comprueba que el esquema coincide con las entidades y que los tests de Servidor 22 pasan. Genera un script de esquema a partir de esa versión, por ejemplo con pg_dump, instalado con las herramientas de PostgreSQL. En PowerShell ajusta usuario, base y ruta del ejecutable a tu instalación:

pg_dump --host=localhost --port=5432 --username=postgres --schema-only --no-owner --no-privileges --file=docs/esquema-inicial.sql gestor_db

El comando pide la contraseña si la conexión lo necesita; no la escribas en el script. El archivo contiene estructura, no una copia de tus registros. Revisa nombres y restricciones en una PR y enlaza el commit que lo produjo.

2. Prueba el script en una base vacía de ensayo. No lo ejecutes sobre la base pública si ya contiene tablas. Para la primera instalación pública, comprueba que el destino esté vacío y aplica el script mediante el cliente PostgreSQL conectado con TLS.
3. En las variables del App Service configura SPRING_JPA_HIBERNATE_DDL_AUTO=validate y SPRING_SQL_INIT_MODE=never. Conserva URL, usuario y contraseña de su propio entorno. No copies create-drop de CI.
4. Arranca el backend y comprueba que valida el esquema. Si falta una columna, revisa la versión de script y JAR; no cambies validate por update para ocultar la discrepancia.
5. Carga datos ficticios mediante la colección. En las siguientes semanas los cambios de relaciones de Servidor 23–26 requieren scripts incrementales revisados y una prueba sobre copia de datos; no se vuelve a aplicar el esquema completo.

Bloque D · Verificación de la persistencia

Trabajo individual · comprobación determinante de la sesión

1. Crea un elemento mediante la colección de peticiones contra la URL pública.
2. En el portal, reinicia el App Service.
3. Espera a que el proceso arranque y consulta el mismo identificador desde la colección.
4. El elemento debe persistir.

La comprobación acredita que el registro sobrevive al reinicio del proceso, esto es, que el estado reside en el sistema gestor de base de datos y no en la memoria de la aplicación. Complétala verificando que el dato consta en la base pública y bajo la versión identificada.

Si la persistencia no está terminada todavía en Servidor

Los bloques A y B se realizan igualmente: el aprovisionamiento del servidor y la configuración de las variables corresponden a este módulo y no dependen de que la aplicación las consuma todavía. Cuando la versión con persistencia esté disponible, se incorpora por el flujo de integración habitual y el bloque D se ejecuta en ese momento. Lo que no resulta admisible es alcanzar la entrega del trimestre sin haber verificado nunca la persistencia.

El servicio PostgreSQL del CI se configuró en Intermodular 11. Reutiliza ese job y verifica que ejecuta las pruebas de repositorio de Servidor 22.

---

Cierre

15 minutos · comprobación del resultado

Ver respuestas

1 · Porque el repositorio es público y porque la dirección cambia entre entornos. Va en el entorno, y en el repositorio solo un ejemplo con valores falsos.

2 · No. Sigue en el historial. Lo único que lo resuelve es cambiar la contraseña en el servidor.

3 · Con validate, el arranque comprueba el esquema y no lo modifica. Un cambio se prepara mediante un script incremental revisado y ensayado.

4 · Porque solo acepta conexiones cifradas, y el error que da no menciona el cifrado: parece un problema de red.

5 · Que los datos viven fuera de la aplicación. Es la única comprobación que distingue persistencia de casualidad.