estrategias de devops sprint2 - galoryzen/equipo8-pfinal GitHub Wiki

Evidencias de Estrategias de DevOps - Sprint 2

Video Evidencias Sprint 1

Dejamos este video pues no ha cambiado mucho el flujo

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. Formato: pnpm format:check (Prettier) — falla si hay archivos sin formatear
    3. Lint estricto: pnpm lint:precommit (ESLint, --max-warnings 5)
    4. i18n parity gate: __tests__/i18n-keys-parity.test.ts — bloquea literales UI en codigo y verifica que las claves de es/ e en/ esten alineadas (SCRUM-272)
    5. Accesibilidad (axe) + cobertura: pnpm test:coverage corre los tests de componentes + auditoria axe en jsdom (SCRUM-273)
    6. Build estatico (pnpm build) que genera out/
    7. 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 Enforcement pre-commit (Husky)

Desde Sprint 2 (PR #113) el frontend ejecuta un hook pre-commit gestionado por Husky (frontend/travel-hub/.husky/pre-commit) que corre localmente los mismos gates del CI:

pnpm format:check
pnpm lint:precommit

Objetivo: atajar errores de formato, lint, i18n y a11y antes de que el commit llegue a CI. Cubre las historias SCRUM-272 (i18n) y SCRUM-273 (a11y).

1.6 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 2 — Resumen (en curso)

Metrica Valor
Historias 19 (incluye 2 tecnicas: SCRUM-272 i18n y SCRUM-273 a11y)
Story Points 34 pts
Velocity parcial S2-W1: 15 pts completados (9 historias)
Work in Progress SCRUM-199 (In Review, 2 pts), SCRUM-200 (In Progress, 2 pts)
Business Value 46% acumulado (+17.5% vs cierre de S1)
Foco Reservas, carrito, pagos, registro hotel/agencia, a11y + i18n, dashboard hoteles

Objetivo del Sprint: habilitar el flujo completo reserva → pago → confirmacion (web y movil) + iniciar el portal de gestion para hoteles, soportado por una arquitectura de eventos (saga por coreografia: EventBridge+SQS en AWS, RabbitMQ en local).

Asignacion por Integrante — Sprint 2

Integrante Historias Pts Foco
Isaac Blanco SCRUM-83, 84, 272, 273 10 Carrito + pago web, i18n, a11y (pre-commit + CI axe)
Raul Lopez SCRUM-122, 123, 124, 125, 127, 128 8 Flujo completo de reserva y pago en movil
Jose Manuel Garcia SCRUM-160, 185, 199, 200 8 Portal de gestion hotel: confirmar/rechazar reserva, promos, email
Nicolas Calero SCRUM-86, 107, 172, 188, 190 8 Pago seguro, refunds, registro hotel/agencia, dashboard, reportes

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}
  • Accesibilidad: suite de auditoria con jest-axe sobre componentes clave (SCRUM-273)
  • i18n parity: test dedicado (__tests__/i18n-keys-parity.test.ts) que falla si hay literales UI en codigo o si las claves de locales divergen (SCRUM-272)
  • 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 — Prettier + ESLint

  • Formato: pnpm format:check / pnpm format (Prettier) — bloqueante en CI y pre-commit
  • Linting: pnpm lint:precommit (ESLint con --max-warnings 5) — bloqueante en CI y pre-commit
  • Configurado con reglas de Next.js + plugin jsx-a11y
  • Husky pre-commit corre format + lint antes de permitir el commit local

Frontend — Accesibilidad (a11y)

  • axe-linter activo en el IDE (VS Code)
  • Tests automatizados con jest-axe corren en CI como parte de pnpm test:coverage
  • GitHub Action bloquea merge de PRs con errores de a11y (SCRUM-273)

Frontend — i18n

  • Test __tests__/i18n-keys-parity.test.ts bloquea merges con literales UI o con claves desbalanceadas entre locales/es/ y locales/en/ (SCRUM-272)

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 (incluyendo auditoria axe de a11y)
  3. Cumple con las verificaciones de tipos (mobile)
  4. Respeta el formato Prettier y el lint estricto (frontend)
  5. No introduce literales UI ni rompe la paridad de locales i18n (frontend)