El problema
Construir servicios es solo una parte del trabajo. Cada proyecto también necesita una forma repetible de empaquetar cambios, ejecutar validaciones, publicar artefactos y actualizar su entorno. Implementé pipelines CI/CD en proyectos académicos usando GitLab CI y GitHub Actions.
Este caso agrupa esos flujos en una sola vista técnica, en lugar de tratarlos como una única aplicación.
Mi contribución
Diseñé los pipelines CI/CD para proyectos AYD1, AYD2, QuetzalShip y EconoMarket. Los flujos cubren despliegues con Docker Compose y despliegues en Kubernetes sobre GKE. La implementación de aplicación de EconoMarket se explica en su propio caso de estudio.
GitLab: entrega basada en Compose
El pipeline de AYD2 construye y publica imágenes de contenedor, ejecuta pruebas unitarias e integración en proceso con pytest, y conserva reportes JUnit como artefactos de job. El despliegue es un job manual que descarga imágenes y recrea servicios con Docker Compose en un shell runner.
AYD1 también usa Compose para compilar y desplegar. Su etapa de pruebas ejecuta un contenedor de base de datos junto a un contenedor de pruebas de API, propagando el código de salida del contenedor de test.
Estos flujos describen un proceso de entrega práctico e inspeccionable. Un Compose down seguido de up es un reinicio de servicios, no una estrategia de despliegue sin interrupciones.
GitHub Actions: compilación de servicios y GKE
El flujo de QuetzalShip usa tareas por servicio y una matriz de compilación, genera etiquetas de imágenes, publica contenedores y aplica recursos de Kubernetes con kubectl. También configura recursos de observabilidad, ingress, pruebas de humo, una ejecución E2E seleccionada y una tarea de Locust con artefactos de resultados.
El flujo de EconoMarket coordina validaciones para Node.js, Go y Python, construye imágenes de servicios y despliega servicios de aplicación, tareas programadas y recursos de ingress en GKE. También incluye validación y plan con Terraform; en este trabajo, infraestructura como código es soporte, mientras que la entrega de contenedores es el foco principal.
Resultados y límites
Los entregables concretos son los flujos de trabajo, sus dependencias entre tareas, definiciones de construcción de imágenes de contenedor, pasos de despliegue y archivos de prueba asociados. Aquí no se afirma ninguna métrica de frecuencia de despliegue o ahorro de tiempo.
Algunos comandos de prueba en GitHub actualmente toleran fallos con || true; esas etapas recopilan retroalimentación, pero no imponen una compuerta estricta de pruebas aprobadas. El job E2E de AYD1 está comentado. Estas distinciones importan al explicar qué garantiza realmente un pipeline.
La siguiente mejora sería explicitar compuertas de calidad intencionales y fortalecer la validación post-despliegue. Son oportunidades de mejora, no capacidades ya cerradas.
Lecciones de ingeniería
Este trabajo refleja la parte de DevOps que más disfruto: conectar código, contenedores y entornos en un proceso que otra persona pueda seguir. La arquitectura de un pipeline también es un problema de comunicación, especialmente cuando distintos proyectos tienen requisitos diferentes de prueba y despliegue.