Saltar a contenido

Mapa de repositorios

El grupo público tiene como nombre visible Cloud Delivery Lab y mantiene el namespace gabriel-canals-tfm. Contiene seis proyectos; todos exponían main como rama predeterminada y protegida en la consulta pública del 26 de octubre de 2026.

Repositorio Responsabilidad Commit revisado Archivos
cicd-templates Plantillas compartidas para build, análisis y despliegue. 642a84669137 3
terraform-modules Ocho módulos raíz, pipeline de infraestructura y configuración de agentes. ae1502b0f4bd 69
web-application/apps/backend API Java, configuración de base de datos, Dockerfile y composición CI. 2c8e6ef861de 31
web-application/apps/frontend Interfaz Java/FreeMarker/Vue, Dockerfile y composición CI. 1e56e856d4cf 183
web-application/deployments/backend Deployment, Service y ServiceAccount del servicio rest. 82148d6303d0 3
web-application/deployments/frontend Manifiestos de web y el Ingress específico de AWS. 38ef821c0b9d 4

El número de archivos corresponde a git ls-files en el commit indicado. Incluye recursos estáticos del frontend; no mide complejidad ni porcentaje de cobertura de pruebas.

Fronteras de responsabilidad

Los repositorios de aplicación conocen cómo construir una imagen y qué repositorio contiene sus manifiestos. Importan tres archivos de cicd-templates mediante include:project, actualmente con ref: main.

Los repositorios de despliegue mantienen el estado deseado de cada servicio. No contienen .gitlab-ci.yml en el snapshot. El pipeline que modifica y aplica los manifiestos sigue perteneciendo al repositorio de aplicación. No hay un trigger de pipeline multiproyecto ni un reconciliador Argo CD/Flux declarado.

El repositorio de infraestructura aprovisiona red, Kubernetes, base de datos y recursos de plataforma. No contiene el código de la aplicación ni aplica sus dos Deployments. La separación evita que una entrega normal tenga que reprovisionar toda la infraestructura.

Este repositorio documental es una incorporación nueva. Compila Markdown a HTML y publica GitLab Pages; no accede a AWS, Google Cloud ni a los estados de infraestructura.

Relaciones

flowchart TD
  T["Plantillas CI/CD"] --> A["Repositorios de aplicación"]
  A --> R["Container Registry"]
  A --> D["Repositorios de manifiestos"]
  I["Infraestructura y agentes"] --> K["EKS o GKE"]
  D --> J["Job deploy de aplicación"]
  J --> K
  R --> K

La flecha desde los manifiestos representa su lectura por el job de aplicación. Los proyectos de manifiestos no ejecutan ese job por sí mismos.

Trazabilidad que sí existe

La imagen se etiqueta con el SHA completo de la aplicación. El job de actualización escribe esa referencia en deployment.yaml y utiliza el mismo SHA como mensaje del commit del repositorio de despliegue. En el snapshot, las dos referencias de imagen coinciden con los HEAD revisados de sus aplicaciones.

La referencia main de las plantillas puede cambiar entre ejecuciones. Para reconstruir un pipeline histórico hay que conservar además su configuración expandida o las revisiones de todas las plantillas; el SHA de la aplicación por sí solo no fija esas dependencias.

Clonar o renombrar el grupo

Al trasladar los proyectos, revisar include:project, CD_PROJECT_PATH, contextos del agente, autorizaciones ci_access, referencias de imágenes y URLs de estados remotos. Cambiar el nombre visible del grupo no actualiza esas cadenas; cambiar su ruta requiere planificar la migración. Los identificadores numéricos de proyecto y las credenciales tampoco deben copiarse sin comprobar su alcance.

El archivo source-manifest.json en la raíz de este repositorio conserva los IDs, las URLs y los SHA completos usados para esta edición. Fuentes explica cómo actualizar la revisión.

Fuentes y trazabilidad