UD4 · Conectar
Poner el backend en producción
Reutilizar el repositorio de Servidor, ejecutar su CI, publicar el backend, comprobar el contrato con la colección y preparar PostgreSQL en pruebas y producción.
Antes de empezar
- Necesitas
- Portfolio publicado con pipeline.
- Repositorio de Spring Boot creado en Servidor y su wrapper de Maven.
- Java 21 y colección de peticiones existente.
- Debes saber
- El flujo de integración completo: issue, rama, pull request, revisión, fusión y despliegue.
- De Servidor: controladores REST, DTO, validación y manejo de errores.
La API desarrollada en Servidor se ejecuta actualmente en la estación de trabajo de quien la programó. El objeto de esta unidad es su puesta en producción bajo una URL pública, sometida al mismo flujo de integración que el portfolio y consumida desde él.
Delimitación de competencias evaluativas
El código de la API corresponde al módulo de Servidor: su arquitectura por capas, sus validaciones, su tratamiento de errores y sus pruebas. Los defectos técnicos se corrigen en ese mismo repositorio y su evaluación pertenece a dicho módulo. En Proyecto Intermodular se evalúa que ese código resida en un repositorio sometido a un flujo de integración, que un pipeline lo compile y ejecute sus pruebas antes de autorizar la fusión, que se encuentre desplegado y que una colección de peticiones verifique su contrato; el cliente completo se aborda tras las unidades 33 y 34 de Servidor. Una implementación técnicamente excelente que solo se ejecute en un entorno local no supera los criterios de esta unidad.
Incorporación de la persistencia dentro del trimestre
El artefacto desplegado es el mismo CRUD seleccionado y desarrollado en Servidor. La primera publicación puede mantener el estado en memoria, con la consiguiente pérdida de los datos en cada reinicio del proceso: no constituye un defecto, pero debe documentarse en el README para conocimiento de quien consulte el proyecto. PostgreSQL se incorpora en la UD5 de Servidor, dentro todavía del primer trimestre, y a partir de ese momento la versión persistente se publica mediante este mismo workflow. En ningún caso se crea una segunda API.
Los hitos compartidos del primer trimestre
| Lo que entrega Servidor | Lo que se trabaja aquí |
|---|---|
| CRUD en memoria con DTO, validación y errores, al terminar la UD3 | Repositorio del backend, CI y primera puesta en producción |
| Capas y tests de servicio, en la UD4 | Ejecutar las pruebas en cada pull request y comprobar que un fallo bloquea la fusión |
| CRUD con PostgreSQL y tests de repositorio, en la UD5 | Configurar la base de datos del entorno desplegado, sus variables y el entorno de pruebas del CI; publicar la misma API persistente |
| Versión del primer trimestre revisada y defendida, en la UD6 | Identificar el mismo commit desplegado y conservar las evidencias del workflow, CI, revisiones y puesta en producción |
La secuencia está coordinada con Servidor: ninguna sesión exige contenidos que no se hayan impartido allí previamente, y cada una opera sobre la versión del backend disponible en esa fecha. El flujo de integración construido en estas seis sesiones permanece operativo y se aplica a cada incremento del backend hasta el cierre del trimestre. Si al llegar a la sesión 11 la UD5 de Servidor no estuviera completa, se publica el estado disponible y las mejoras posteriores se incorporan por el mismo procedimiento. La entrega del trimestre sí requiere, en todo caso, persistencia en producción.
Sesiones de la unidad
Cada sesión es una clase, con su propia página.
6 sesiones