estrategias de devops - galoryzen/equipo8-pfinal GitHub Wiki

Evidencias de Estrategias de DevOps - Sprint 1

Video Evidencias Semana 1

1. Parametrización de Integración Continua / Despliegue Continuo

El proyecto cuenta con 4 workflows de GitHub Actions configurados en .github/workflows

1.1 Backend CI/CD (backend.yml)

  • Trigger: push y pull request a main, workflow dispatch manual.
  • Detección inteligente de cambios: usa dorny/paths-filter para identificar cuáles de los 5 microservicios fueron modificados (auth, catalog, booking, payment, notification). También detecta cambios en backend/libs/ (librerías compartidas).
  • Ejecución selectiva: solo ejecuta pytest sobre los servicios que realmente cambiaron, optimizando el tiempo de CI.
  • Coverage gate: cada servicio debe tener minimo 70% de cobertura de lineas (--cov=app --cov-fail-under=70), alineado con el objetivo OBJ-002.
  • Pipeline CD (solo en push a main): despliega automaticamente solo los servicios modificados:
    1. Configura credenciales AWS via OIDC (role-to-assume)
    2. Pull de imagen latest desde ECR como cache de capas Docker (inline cache con BuildKit)
    3. Build de imagen Docker con context en backend/ y Dockerfile del servicio
    4. Push a Amazon ECR (travelhub/{servicio}) con tags latest y commit SHA
    5. Actualiza task definition de ECS con la nueva imagen
    6. Despliega en cluster ECS Fargate (travelhub) con --force-new-deployment
  • Job de resultado: backend-result corre siempre (if: always()) y reporta el estado consolidado para los status checks de la rama.

1.2 Frontend CI/CD (frontend.yml)

  • Trigger: push y pull request a main, workflow dispatch manual.
  • Detección de cambios: filtra por modificaciones en frontend/**.
  • Pipeline CI:
    1. Instala dependencias con pnpm install --frozen-lockfile
    2. Ejecuta tests con cobertura (pnpm test:coverage)
    3. Build estático (pnpm build) que genera out/
    4. Sube artefacto del build
  • Pipeline CD (solo en push a main):
    1. Descarga artefacto del build
    2. Configura credenciales AWS via OIDC (role-to-assume)
    3. Sincroniza out/ a S3 (aws s3 sync --delete)
    4. Invalida caché de CloudFront
    5. Smoke test: verifica HTTP 200 en la URL de producción
  • Job de resultado: frontend-result reporta estado consolidado.

1.3 Mobile CI (mobile.yml)

  • Trigger: push y pull request a main, workflow dispatch manual.
  • Detección de cambios: filtra por mobile/**.
  • Pipeline:
    1. Instala dependencias con npm ci
    2. Verificación de tipos TypeScript (npx tsc --noEmit)
    3. Tests con cobertura (npm run test:coverage)
  • Job de resultado: mobile-result reporta estado consolidado.

1.4 Deploy Backend Manual (deploy-backend.yml)

  • Trigger: workflow_dispatch manual con input de servicios a desplegar (separados por coma).
  • Uso: si se presenta un despliegue fallido o se requiere desplegar un servicio específico fuera del flujo normal, se puede ejecutar este workflow manualmente desde la pestaña de Actions. Solo requiere ingresar los nombres de los servicios a desplegar (ej: auth,catalog).
  • Pipeline por cada servicio seleccionado:
    1. Pull de imagen latest desde ECR como cache de capas Docker
    2. Build de imagen Docker con inline cache (BuildKit)
    3. Push a Amazon ECR (travelhub/{servicio})
    4. Actualiza task definition de ECS
    5. Despliega en cluster ECS Fargate (travelhub)

1.5 Reglas de rama (Branch Rulesets)

La rama main tiene configuradas las siguientes reglas mediante GitHub Rulesets:

Regla Configuración
Protección contra eliminación Activada
Non-fast-forward Bloqueado
Pull request requerido Solo merge por squash
Dismiss stale reviews on push Activado
Status checks requeridos backend-result, frontend-result, mobile-result
Strict status checks Activado (rama debe estar al día con main)

Esto significa que ningún código llega a main sin pasar los 3 pipelines de CI.

2. Sprint Backlog y Asignación por Integrante

Sprint 1 — Resumen

Metrica Valor
Historias 20
Story Points 32 pts
Velocity real S1-W1: 19 pts, S1-W2: 13 pts (32/32 completados)
Business Value 28.5% acumulado
Foco Busqueda, detalle de propiedad, autenticacion viajero

Objetivo del Sprint

Entregar la experiencia base del viajero: buscar hospedajes con filtros, ver detalle de propiedades y autenticarse en la plataforma (web y movil).

Features entregadas en Sprint 1

Semana 1:

  • Busqueda por ubicacion, fechas, rango de precio y amenidades (web)
  • Listado de hospedajes destacados (web)
  • Autenticacion viajero con JWT (web)
  • Arquitectura hexagonal y CI/CD base

Semana 2:

  • Detalle de propiedad con resenas (#96, #100)
  • Filtros por huespedes, amenidades y precio (movil) (#97, #99, #101)
  • Home page y navbar (web) (#98)
  • Cache con Redis para busquedas (#102)
  • Calificacion promedio de propiedades (#105)
  • Consultar reservas del viajero (#106)

Asignacion por Integrante

Integrante Historias Pts Foco
Isaac Blanco SCRUM-170, 173, 78-81 8 Auth + detalle de propiedad y resenas (web)
Raul Lopez SCRUM-110, 113, 115-119 8 Busqueda y detalle (movil)
Jose Manuel Garcia SCRUM-75, 76, 77 8 Filtros de precio, amenidades y combinados (web)
Nicolas Calero SCRUM-73, 74, 82, 87 8 Busqueda ubicacion/fechas, calificacion, reservas (web)

3. Commits y Pull Requests

Convenciones de commits

El equipo utiliza commits convencionales con prefijos semanticos:

  • feat: / feature: para nuevas funcionalidades
  • fix: para correcciones
  • refactor: para reestructuracion de codigo
  • ci: para cambios en pipelines de CI/CD
  • docs: para documentacion
  • tests: para pruebas

Ramas

Cada historia de usuario o tarea se desarrolla en una rama dedicada que sigue una convencion de nombres:

  • feature/{id-o-descripcion} — funcionalidades nuevas
  • fix/descripcion — correcciones de bugs
  • refactor/descripcion — cambios de refactorizacion
  • PRs se mergean a main via squash merge, manteniendo un historial limpio

4. Flujo de Trabajo y Estrategia de Versionamiento

Estrategia de branching: GitHub Flow

El equipo sigue GitHub Flow, una estrategia simple y efectiva:

Flujo de trabajo

  1. Crear rama desde main con nombre descriptivo basado en la historia de usuario
  2. Desarrollar la funcionalidad con commits frecuentes y descriptivos
  3. Abrir Pull Request hacia main
  4. CI automatico ejecuta los 3 pipelines (backend, frontend, mobile) segun los archivos modificados
  5. Los 3 status checks deben pasar (backend-result, frontend-result, mobile-result) — es un requisito obligatorio configurado en las reglas de rama
  6. Squash merge a main — consolida todos los commits de la rama en uno solo, manteniendo un historial limpio
  7. CD automatico — si hay cambios en frontend, se despliega automaticamente a S3 + CloudFront; si hay cambios en backend, se despliegan solo los microservicios modificados a ECS Fargate

Protecciones

  • No se puede hacer push directo a main — siempre via PR
  • Status checks estrictos — la rama debe estar actualizada con main antes de mergear
  • Squash-only — unica estrategia de merge permitida
  • Dismiss stale reviews — si se pushean cambios nuevos, las revisiones anteriores se invalidan

5. Ejecucion de Pruebas

Estrategia de pruebas

Basada en el documento formal de estrategia (docs/DocumentoEstrategiaPruebas.pdf), con objetivo de minimo 70% de cobertura automatizada (OBJ-002).

Backend — Pytest

  • Framework: pytest con soporte asyncio (asyncio_mode = "auto")
  • Arquitectura hexagonal: las pruebas usan mocks de puertos (CachePort, database session) permitiendo testing aislado de la logica de negocio
  • Ejecucion en CI: pytest tests/ -v --cov=app --cov-fail-under=70 por cada servicio modificado
  • Ejecucion local: make test s=catalog o make coverage s=catalog

Frontend — Vitest

  • Framework: Vitest v4.1 + React Testing Library v16 + jsdom
  • Cobertura: proveedor v8, reportes en texto y lcov
  • Alcance: archivos en app/**/*.{ts,tsx,js,jsx}
  • Ejecucion en CI: pnpm test:coverage
  • Ejecucion local: pnpm test o pnpm test:coverage

Mobile — Jest

  • Framework: Jest v29 + jest-expo v55 + Testing Library React Native v13
  • Soporte ESM: node --experimental-vm-modules
  • Ejecucion en CI: npm run test:coverage
  • Ademas incluye verificacion de tipos con npx tsc --noEmit

Ejecucion en CI

Las pruebas se ejecutan automaticamente en cada PR y push a main. Evidencia de ejecuciones recientes:

Últimos actions

Las pruebas son un requisito bloqueante para mergear: si alguno de los 3 pipelines falla, el PR no puede ser mergeado.

Coverage gate en los 3 layers

A partir de semana 2, los 3 layers tienen coverage gate >= 70% enforceado en CI:

Layer Mecanismo Cobertura actual
Backend pytest --cov-fail-under=70 (por servicio) 82.8%
Frontend Vitest thresholds: { lines: 70 } 78.2%
Mobile Jest coverageThreshold: 70% 91.2%

Si cualquier layer baja de 70%, el CI falla y el PR no puede ser mergeado.

6. Peer Review (Opcional)

El flujo de trabajo del equipo incluye pull requests como mecanismo de peer review:

  • Todos los cambios pasan por PR antes de llegar a main
  • Las reglas de rama tienen configurado dismiss stale reviews on push, lo que invalida revisiones previas cuando se agregan nuevos commits
  • Se han hecho algunas reviews entre compañeros, aunque no es un requisito formal ni obligatorio. El enfoque principal ha sido asegurar que los pipelines de CI pasen correctamente.

7. Revision Automatica de Codigo (Opcional)

Linting y formateo

El proyecto utiliza herramientas de revision automatica de codigo:

Backend — Ruff

  • Linting: make lint s={servicio} (ruff check)
  • Formateo: make format s={servicio} (ruff format)

Frontend — ESLint

  • Linting: pnpm lint
  • Configurado con reglas de Next.js

Mobile — TypeScript

  • Verificacion de tipos: npx tsc --noEmit (ejecutado en CI)

Status checks como puerta de calidad

Los 3 status checks requeridos (backend-result, frontend-result, mobile-result) actuan como revision automatica: si las pruebas o el build fallan, el codigo no puede entrar a main. Esto garantiza que todo codigo mergeado:

  1. Compila correctamente
  2. Pasa las pruebas automatizadas
  3. Cumple con las verificaciones de tipos (mobile)