Construcción, imágenes y release¶
El proyecto materializa una versión entregable publicando una imagen por servicio en GitLab Container Registry. Aunque la memoria distingue conceptualmente Build y Release, el YAML realiza ambas operaciones en la etapa build; no contiene un job de GitLab Releases ni una promoción separada entre entornos.
Del código al JAR¶
generate-maven-jar usa maven:3.8.8-eclipse-temurin-17 y ejecuta mvn clean package -DskipTests. Maven genera target/app.jar, de acuerdo con finalName en ambos POM. El job conserva target/*.jar como artefacto y generate-image lo recibe mediante needs con artifacts: true.
El YAML compartido no declara caché Maven ni invoca ci_settings.xml con -s. La presencia de ese archivo no prueba que se esté utilizando el registro Maven de GitLab. Tampoco se publica el JAR en un Package Registry: el artefacto de job se usa como entrada de Docker.
Del JAR a la imagen¶
generate-image usa Docker 29.2.1 y un servicio Docker-in-Docker de la misma versión. Inicia sesión con las variables de registro suministradas por GitLab, construye el Dockerfile del proyecto y publica la imagen con esta convención:
Ejemplo de estructura, sin credenciales:
El SHA permite relacionar imagen y código. La etiqueta de registro sigue siendo una etiqueta: no se ha verificado una política de inmutabilidad ni una referencia por digest en los manifiestos. Los Dockerfiles tampoco fijan la imagen base por digest y actualizan paquetes Alpine en cada build. Recompilar el mismo commit puede producir una imagen distinta.
Requisitos del runner¶
El runner debe poder ejecutar Docker-in-Docker y acceder a Maven Central, el registro de imágenes base y GitLab Container Registry. La configuración del runner, sus permisos y las variables de conexión/TLS de Docker no están versionadas en este grupo. Se debe validar esa conexión en el runner elegido, en lugar de asumir que declarar el servicio Docker la completa.
Como mejora, usar credenciales por stdin para docker login, fijar imágenes de herramientas y base por digest, y conservar metadatos de imagen. Son cambios propuestos, no características del snapshot.
Qué contiene una entrega¶
| Evidencia | Dónde localizarla |
|---|---|
| Revisión de aplicación | Commit y pipeline del repositorio de código |
| JAR | Artefacto de generate-maven-jar mientras siga retenido |
| Imagen | Container Registry y etiqueta del SHA |
| Revisión de manifiestos | Commit creado por update-k8s-manifests |
| Resultado de aplicación | Job deploy; completar con comprobación de rollout |
| Base de datos | Estado/backup propios; no queda encapsulada en la imagen |
La promoción entre AWS y GKE selecciona otro contexto, pero no existe un mecanismo versionado que garantice promover el mismo digest a ambos destinos o coordinar versiones entre frontend y backend. Cada aplicación puede ejecutar su pipeline de forma independiente.
Comprobaciones tras una construcción¶
Comprobar que el JAR tiene el nombre esperado; que el job de imagen ha descargado ese artefacto; que el análisis de contenedor apunta a la misma ruta y SHA; y que el manifiesto actualizado contiene esa imagen. Si el artefacto ha caducado, reconstruir la etapa necesaria antes de reintentar un job dependiente.
Para una recuperación completa, conservar imágenes anteriores y revisar la guía de rollback, especialmente la compatibilidad del esquema de datos.