Antes de empezar. En Servidor ya has conectado PostgreSQL y trabajado el acceso a los datos. Hoy prepararás una base de pruebas aislada para ejecutar esa versión en CI.
Se explica
25 minutos · explicación y demostración
En Servidor 19–20 el proyecto comienza a utilizar PostgreSQL. El código deja de bastar para arrancar: también necesita una base de datos. Si el pipeline no prepara esa dependencia, puede fallar aunque la implementación sea correcta.
Un servicio del job es un contenedor que GitHub Actions crea para esa ejecución. Tendrá una base de datos vacía, credenciales ficticias y un comprobador de disponibilidad. Al terminar el job se descarta. La base de pruebas del CI nunca es la de producción.
El trabajo de Servidor es escribir pruebas que verifiquen las reglas y, en su sesión 22, las consultas. Aquí aseguramos que se ejecutan con el entorno correcto y que un fallo impide fusionar. No cambiamos una aserción para conseguir un check verde.
Se trabaja
140 minutos · trabajo guiado sobre el producto compartido
Bloque A · Reproducir la construcción local
- Abre el repositorio de backend existente y crea una issue para preparar PostgreSQL en CI. Anota qué dependencia añadió la versión de Servidor y qué error aparece en el runner.
- Ejecuta
.\mvnw.cmd -B verifyen PowerShell, con PostgreSQL local encendido y las variables del README. En Linux/macOS utiliza./mvnw -B verify. - Separa un fallo de conexión de un fallo de test leyendo el primer mensaje causal. Guarda ese fragmento sin contraseñas.
Bloque B · Preparar PostgreSQL en el job
En .github/workflows/ci.yml, añade services y env dentro del job build, al mismo nivel que runs-on y steps. Conserva las etapas de checkout, Java y verify de la sesión 7. Declara la misma versión mayor de PostgreSQL que emplea el proyecto; 16 es el valor del ejemplo.
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: gestor_test
POSTGRES_USER: postgres
POSTGRES_PASSWORD: prueba_ci
ports:
- 5432:5432
options: >-
--health-cmd "pg_isready -U postgres -d gestor_test"
--health-interval 10s
--health-timeout 5s
--health-retries 5
env:
SPRING_PROFILES_ACTIVE: test
SPRING_DATASOURCE_URL: jdbc:postgresql://localhost:5432/gestor_test
SPRING_DATASOURCE_USERNAME: postgres
SPRING_DATASOURCE_PASSWORD: prueba_ci
TEST_DB_PASSWORD: prueba_ci
SPRING_JPA_HIBERNATE_DDL_AUTO: create-drop
SPRING_SQL_INIT_MODE: neverEl ejemplo está indentado para pegarlo dentro del job. create-drop se permite aquí porque el contenedor es exclusivo y desechable. Nunca lo copies a las variables del App Service. El perfil test de Servidor 22 reutilizará este entorno; hasta entonces verifica las pruebas ya disponibles.
Bloque C · Comprobar el aislamiento
- Sube la rama y abre la PR. En Actions localiza la creación del servicio, su comprobación de disponibilidad y la ejecución Maven.
- Revisa el informe de tests: debe indicar cuántas pruebas se ejecutaron. Un build sin pruebas no demuestra las reglas del producto.
- En una rama de prueba cambia temporalmente el nombre de la base de datos a uno inexistente. Comprueba que falla por conexión, no por compilación. Restaura el nombre antes de fusionar.
- Confirma que
Compilar y probarsigue siendo obligatorio. Al llegar los tests JPA de Servidor 22, ejecútalos en este mismo job; no abras otro proyecto de pruebas.
Bloque D · Conservar las evidencias
En las comprobaciones de la sesión enlaza la ejecución correcta y el fallo controlado. Documenta por qué la contraseña del contenedor de pruebas es ficticia y dónde se configura la de producción. La siguiente sesión prepara la base pública y comprobará que sus datos sobreviven al reinicio.
Cierre
15 minutos · comprobación del resultado
Al terminar la sesión: El CI prepara una base aislada, ejecuta las pruebas existentes y permite localizar su resultado. Explica qué recursos crea el job y cómo distingues pruebas superadas de pruebas no ejecutadas.