Estado: borrador. Esta página recoge el esqueleto de entregables de la semana 1 del Proyecto Final 2 según la rúbrica. Cada sección se completa a medida que el equipo avanza en la construcción.

• Hoja de trabajo semana 1 — Proyecto Final 2
  • Índice
  • 1. Configuración del ambiente de trabajo DevOps
    • 1.1 Parametrización de integración continua / despliegue continuo
      • 1.1.1 Herramienta y alcance
      • 1.1.2 Pipelines por componente
      • 1.1.3 Etapas del pipeline
      • 1.1.4 Parámetros de configuración
      • 1.1.5 Puertas de calidad
      • 1.1.6 Infraestructura como código (Terraform)
      • 1.1.7 Contenedores (Docker) y registro de imágenes (ECR)
      • 1.1.8 Despliegue continuo: estado y plan
      • 1.1.9 Manejo de secretos
    • 1.2 Sprint Backlog y asignación por integrante (10 puntos)
    • 1.3 Commits / pull requests (15 puntos)
    • 1.4 Flujo de trabajo y estrategia de versionamiento (10 puntos)
      • 1.4.1 Estrategia: GitFlow
      • 1.4.2 Ramas y su propósito
      • 1.4.3 Política de nombres de rama
      • 1.4.4 Flujo de trabajo paso a paso
      • 1.4.5 Estrategia de versionamiento
      • 1.4.6 Relación entre ramas, pipeline y ambientes
      • 1.4.7 Reglas de protección de ramas
      • 1.4.8 Buenas prácticas acordadas
    • 1.6 Peer review (opcional)
    • 1.7 Revisión automática de código (opcional)
  • 2. Evidencias de avance semanal (15 puntos)
    • 2.1 Burndown chart (5 puntos)
    • 2.2 Velocity chart (5 puntos)
    • 2.3 Value chart (5 puntos)
  • 3. Tablero del Proyecto (15 puntos)
  • 4. Video con evidencias (15 puntos)
  • Control de versiones

Descripción general del ambiente DevOps montado para el Sprint 1 del PF2: repositorios, pipelines, ramas y responsables.

El equipo usa GitHub Actions como motor de integración continua y Codecov como servicio de cobertura. Se eligió GitHub Actions porque el código, los Pull Requests y las reglas de rama ya viven en GitHub, lo que permite que el resultado del pipeline sea una condición de fusión sin integrar otra herramienta.

Todo el código está en un monorepo (MISO-PROYECTO-FINAL-SOLVENTA) con tres componentes: apps/web (Angular), apps/mobile/Solventa (Android) y apps/backend (microservicios y BFF en FastAPI). Cada componente tiene su propio pipeline y cada pipeline se dispara solo cuando cambian archivos de su carpeta (filtro paths), de modo que un cambio en web no ejecuta las pruebas de móvil ni de backend.

Los siete workflows se agrupan por propósito: políticas del repositorio, pruebas y empaquetado.

Workflows de políticas

Workflows de pruebas

Workflows de empaquetado

flowchart LR
    PR[Pull Request] --> POL[Política de ramas]
    PR --> BE[Backend: selección de servicios]
    PR --> WEB[Web: pruebas unitarias]
    PR --> MOB[Móvil: pruebas unitarias]
    BE --> BET[PyTest + cobertura]
    BET --> COV[Codecov ≥ 80 %]
    WEB --> WEBE[Imagen nginx + E2E]
    WEB --> COV
    MOB --> COV
    POL --> GATE{Checks requeridos + 1 aprobación}
    COV --> GATE
    GATE --> DEV[Fusión en develop]
    DEV --> APK[APK de depuración]
    DEV --> ME2E[E2E móvil en emulador]

El resultado del pipeline condiciona la fusión mediante rulesets del repositorio:

La política de ramas rechaza automáticamente un PR cuya rama origen no corresponda: develop solo recibe feature/*, release/* y hotfix/*; main solo recibe release/* y hotfix/*; release/* solo recibe bugfix/*.

La infraestructura de AWS sobre la que se desplegará Solventa está definida con Terraform en infra/terraform, alineada con la vista de despliegue del documento de arquitectura. Cubre el ambiente mínimo de producto: un ambiente que se levanta, se usa para evidenciar y se destruye, de modo que siempre se parte de una infraestructura idéntica y reproducible.

Estructura

infra/terraform/
├── README.md                # uso, costo y verificación
├── PLAN.md                  # decisiones y trazabilidad contra el diagrama de despliegue
├── environments/
│   └── minimo/              # ambiente mínimo: composición de los módulos
│       ├── main.tf          # instancia y conecta los módulos
│       ├── variables.tf     # 61 variables (región, tamaños, banderas de costo)
│       ├── outputs.tf       # 21 salidas (endpoints, ARN, nombres)
│       ├── providers.tf     # AWS (región principal y us-east-1) y Helm
│       ├── versions.tf      # versiones de Terraform y de los providers
│       ├── backend.tf.example
│       └── terraform.tfvars.example
└── modules/                 # un módulo por servicio de la arquitectura

Los 17 módulos se agrupan por capa:

Configuración

Frontera con Kubernetes. Terraform crea la plataforma: red, clúster, complementos, repositorios de imágenes, bases de datos, caché, bus de eventos y borde. Los despliegues de los microservicios no están en Terraform: viven en infra/k8s como un chart de Helm genérico con un archivo de valores por componente. Así, publicar una nueva versión de un microservicio no exige reaplicar la infraestructura, y el autoescalado se ajusta en Kubernetes.

Uso

cd infra/terraform/environments/minimo

cp terraform.tfvars.example terraform.tfvars   # ajustar valores
terraform init
terraform plan
terraform apply

terraform destroy                              # deja la cuenta limpia

Verificación. El código se valida con terraform fmt -check -recursive y terraform validate. Hoy Terraform se ejecuta de forma manual; su integración al pipeline está en el plan de 1.1.8.

Cada componente desplegable se empaqueta como una imagen Docker. La imagen es la unidad que viaja por el pipeline: se construye y se prueba en integración continua, se almacena en Amazon ECR y es lo que el clúster EKS ejecuta.

Patrón de imagen del backend

Los microservicios y los BFF comparten un mismo Dockerfile de tres etapas, definido en los arquetipos (ms-arquetipo y bff-arquetipo) y copiado por cada servicio nuevo:

docker build --target test -t ms-cotizacion:test apps/backend/ms-cotizacion
docker run --rm ms-cotizacion:test                    # ejecuta las pruebas

docker build --target runtime -t ms-cotizacion:runtime apps/backend/ms-cotizacion

Decisiones del patrón:

• Versión fija de la imagen base (3.12.7-slim-bookworm), para que la construcción sea reproducible.
• Dependencias fijadas con requirements.lock en los arquetipos.
• Usuario sin privilegios en la etapa runtime; el chart de Helm exige además runAsNonRoot y sistema de archivos de solo lectura.
• .dockerignore que excluye entornos virtuales, cachés, reportes y archivos .env.
• Los BFF se construyen desde apps/backend como contexto (-f <servicio>/Dockerfile), porque su Dockerfile copia rutas relativas a esa carpeta.

Estado por componente

La imagen del portal web tiene dos etapas: node:22.22.3-bookworm compila la aplicación Angular y nginx:1.27-alpine sirve el resultado. Es la misma imagen contra la que el pipeline ejecuta las pruebas E2E.

Entorno local. Cada servicio con Dockerfile trae un docker-compose.yml que levanta la etapa runtime junto con sus dependencias. La base de datos se inicializa con los scripts de la carpeta db/ del servicio y la aplicación espera a que PostgreSQL esté saludable antes de arrancar:

cd apps/backend/ms-cotizacion
docker compose up --build

Docker en el pipeline. El workflow docker-images.yml construye la etapa test de los arquetipos, ejecuta las pruebas dentro del contenedor, construye la etapa runtime y registra las versiones de Python y de las dependencias instaladas. El workflow web-pr.yml construye la imagen del portal y la usa como ambiente de las pruebas E2E.

Configuración de ECR

Los repositorios de imágenes se crean con el módulo ecr de Terraform (1.1.6):

Cada archivo de valores de Helm en infra/k8s/values/ ya apunta a su repositorio (<cuenta>.dkr.ecr.us-east-1.amazonaws.com/solventa-minimo-<componente>) y deja la etiqueta de la imagen vacía, porque la fija el pipeline en cada despliegue.

Publicación de una imagen. Con el ambiente creado, una imagen se publica con las etiquetas definidas en la estrategia de versionamiento:

REGISTRO=<cuenta>.dkr.ecr.us-east-1.amazonaws.com
REPO=$REGISTRO/solventa-minimo-ms-cotizacion
SHA=$(git rev-parse --short HEAD)

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $REGISTRO

docker build --target runtime -t $REPO:develop -t $REPO:sha-$SHA apps/backend/ms-cotizacion
docker push --all-tags $REPO

Automatizar esta publicación desde GitHub Actions es el siguiente paso del pipeline y está en el plan de 1.1.8. Requiere un rol de IAM que GitHub Actions asuma por OIDC, sin llaves de AWS guardadas en el repositorio.

En la semana 1 el pipeline cubre la integración continua y la entrega de artefactos (APK e imágenes construidas y probadas). El despliegue automático a un ambiente se esta trabajando sobre ECR. La infraestructura ya está descrita como código (infra/terraform para AWS e infra/k8s con el chart de Helm de los microservicios).

Estrategia de entrega y despliegue

El despliegue se hace desde GitHub Actions hacia el clúster de EKS, con las imágenes en ECR y el chart de Helm de infra/k8s. La estrategia se apoya en cuatro reglas:

• La imagen se construye una sola vez. La misma imagen que pasó las pruebas es la que se despliega; entre ambientes se promueve la imagen, no se reconstruye.
• Cada despliegue referencia el SHA del commit. La etiqueta sha-<commit> identifica una imagen única; develop y el número de versión son etiquetas de lectura que se mueven.
• Sin llaves de AWS en el repositorio. GitHub Actions asume un rol de IAM por OIDC, con credenciales temporales y permisos limitados a publicar en ECR y desplegar en el namespace solventa.
• Solo se despliega lo que cambió. El pipeline reutiliza la selección de servicios de backend-unit-tests.yml para construir y desplegar únicamente los componentes modificados.

flowchart LR
  MERGE["Merge a develop"] --> CI["Pruebas unitarias y cobertura"]
  CI --> BUILD["Construir imagen runtime"]
  BUILD --> PUSH["Publicar en ECR: develop + sha"]
  PUSH --> SCAN["Análisis de vulnerabilidades de ECR"]
  SCAN --> DEPLOY["helm upgrade --install con el sha"]
  DEPLOY --> CHECK["Verificar rollout y salud"]
  CHECK -->|falla| ROLLBACK["Rollback automático de Helm"]
  TAG["Tag vX.Y.Z en main"] --> PROMO["Etiquetar la misma imagen con la versión"]
  PROMO --> APROB["Aprobación manual"]
  APROB --> DEPLOY

Despliegue de un componente. El pipeline ejecuta por cada servicio modificado el mismo comando que hoy se usa a mano, agregando la etiqueta de la imagen:

aws eks update-kubeconfig --name <cluster> --region us-east-1

helm upgrade --install ms-cotizacion infra/k8s/charts/microservicio \
  --namespace solventa \
  --values infra/k8s/values/ms-cotizacion.yaml \
  --set imagen.tag=sha-$SHA \
  --atomic --timeout 5m

Actualización sin interrupción. El chart despliega cada componente como un Deployment con actualización gradual (rolling update): Kubernetes crea los pods nuevos, espera a que respondan la sonda de disponibilidad y solo entonces retira los anteriores. El PodDisruptionBudget del chart mantiene un mínimo de réplicas atendiendo durante el cambio.

Disparadores por rama

El despliegue desde develop es automático (despliegue continuo) y el de una versión requiere aprobación (entrega continua), de modo que lo que se muestra en la revisión del sprint siempre es una versión decidida por el equipo.

Reversión manual. Como cada despliegue queda asociado a un SHA, volver a una versión anterior es ejecutar el mismo workflow con el SHA anterior, o helm rollback <componente> sobre el clúster.

Qué falta para ponerla en marcha

Ninguna credencial vive en el código ni en los manifiestos. Cada secreto se guarda en el servicio propio del nivel donde se usa, y los componentes lo reciben en tiempo de ejecución:

Secretos en AWS

Del secreto al contenedor

flowchart LR
  TF["Terraform: genera la contraseña"] --> SM["AWS Secrets Manager, cifrado con KMS"]
  SM --> ESO["External Secrets Operator"]
  ESO --> KS["Secret de Kubernetes"]
  KS --> POD["Pod: variables de entorno"]
  IRSA["Rol de IAM de la cuenta de servicio"] -.-> ESO

1. Terraform crea el secreto en Secrets Manager al aprovisionar la base de datos.

2. El ClusterSecretStore (infra/k8s/platform/clustersecretstore.yaml) conecta el clúster con Secrets Manager. El operador se autentica con el rol de IAM de su cuenta de servicio (IRSA), sin llaves de acceso.

3. Cada componente declara en su archivo de valores qué secretos necesita, y el chart genera un ExternalSecret por cada uno:

   externalSecrets:
     habilitado: true
     secretStoreRef: solventa-secretstore
     remoteSecrets:
       - nombreRemoto: solventa-minimo-open_finance-credentials
         nombreLocal: ms-cotizacion-open-finance
         claves:
           - clientId
           - clientSecret

4. El operador copia el valor a un Secret de Kubernetes y lo vuelve a sincronizar cada hora.

5. El chart inyecta ese Secret al contenedor como variables de entorno. Cuando cambia la lista de secretos de un componente, el chart reinicia sus pods para que tomen el cambio.

Acceso a servicios de AWS sin secretos. Los componentes que usan S3 o MSK (ms-siniestros, ms-parametrico, ms-pagos, analitica y notificaciones) no reciben llaves: cada uno tiene un rol de IAM propio, con permisos mínimos, ligado a su cuenta de servicio de Kubernetes. Los nodos descargan las imágenes de ECR con el rol del nodo. El despliegue desde GitHub Actions seguirá el mismo criterio con OIDC (1.1.8).

Protección en el repositorio. El .gitignore excluye los archivos .env*, el estado de Terraform (*.tfstate) y los almacenes de llaves de Android (*.keystore). Los archivos de valores de Helm solo contienen el nombre del secreto, nunca su valor.

Pendientes

Historias del Sprint 1 cargadas en el tablero https://uniandes-team-proyecto.atlassian.net/jira/software/projects/SOLV/boards/1?filter=&groupBy=none

• Convención de mensajes de commit https://github.com/martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA/commits/develop

• Plantilla y checklist de Pull Request https://github.com/martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA/pulls?q=is%3Apr+state%3Aclosed

El equipo trabaja con GitFlow, como fija el acuerdo de gestión de código y ramas de la página de inicio: todo desarrollo nuevo sale de develop y vuelve a develop por Pull Request. La misma estrategia aplica a todos los repositorios del equipo (web, móvil y backend).

Las reglas que gobiernan todo lo demás:

1. main solo contiene versiones liberadas. Cada commit en main corresponde a un tag vX.Y.Z y es lo que se presenta en la revisión de sprint.
2. develop es la rama de integración. Refleja lo último terminado del sprint en curso y siempre debe compilar y pasar las pruebas.
3. Nadie hace push directo a main ni a develop. Todo cambio entra por Pull Request con CI en verde y al menos una aprobación (acuerdo de revisión por pares).

Por qué GitFlow y no GitHub Flow. El PF2 se entrega en tres sprints con una revisión al cierre de cada uno. GitFlow separa lo que se está integrando (develop) de lo que ya se mostró y aceptó (main), y la rama release/* da un espacio para estabilizar el incremento antes de la demo sin congelar el trabajo del siguiente sprint. Con un equipo pequeño y CI automatizado, el costo extra de mantener develop es bajo.

gitGraph
   commit id: "init"
   branch develop
   checkout develop
   commit id: "ci: pipeline base"
   branch feature/HU-123-descripcion
   checkout feature/HU-123-descripcion
   commit id: "feat: cambio A"
   commit id: "test: pruebas A"
   checkout develop
   merge feature/HU-123-descripcion
   branch feature/HU-124-descripcion
   checkout feature/HU-124-descripcion
   commit id: "feat: cambio B"
   checkout develop
   merge feature/HU-124-descripcion
   branch release/0.1.0
   checkout release/0.1.0
   commit id: "fix: estabilizacion"
   checkout main
   merge release/0.1.0 tag: "v0.1.0"
   checkout develop
   merge release/0.1.0
   checkout main
   branch hotfix/0.1.1
   checkout hotfix/0.1.1
   commit id: "fix: correccion urgente"
   checkout main
   merge hotfix/0.1.1 tag: "v0.1.1"
   checkout develop
   merge hotfix/0.1.1

Formato: <tipo>/<clave-HU>-<descripcion-corta>

Desarrollo de una historia (feature/* / bugfix/*)

1. Mover la historia a En curso en Jira (sistema pull, ver metodología).
2. Actualizar develop y crear la rama:

   git checkout develop
   git pull origin develop
   git checkout -b feature/HU-123-descripcion-corta

3. Hacer commits pequeños con la convención de mensajes de la §1.3 (Conventional Commits con la clave HU).
4. Mantener la rama al día con develop (git pull --rebase origin develop o merge de develop) al menos una vez al día para evitar conflictos grandes.
5. Abrir Pull Request hacia develop con la plantilla del repositorio. El PR dispara el pipeline de la §1.1: build, pruebas unitarias, cobertura y análisis estático.
6. Revisión por al menos un integrante distinto al autor (CODEOWNERS sugiere el revisor).
7. Con CI en verde y aprobación: squash and merge a develop y borrar la rama.
8. Mover la historia a Hecho solo si cumple la DoD.

Cierre de sprint (release/*)

1. Al terminar el desarrollo del sprint se crea release/X.Y.0 desde develop.
2. En la rama de release solo se permiten correcciones, ajuste del número de versión (package.json, build.gradle, pyproject.toml) y actualización del CHANGELOG.md.
3. Se abre PR de release/X.Y.0 hacia main. Al aprobarse se fusiona con merge commit (--no-ff) para que la liberación quede visible en el historial.
4. Se crea el tag anotado vX.Y.0 sobre main y la GitHub Release con las notas.
5. Se fusiona release/X.Y.0 de vuelta en develop para no perder las correcciones, y se borra la rama.

Corrección urgente (hotfix/*)

1. Se crea hotfix/X.Y.Z desde main (Z = parche siguiente).
2. Se corrige, se sube el número de versión y se abre PR hacia main.
3. Al fusionar se etiqueta vX.Y.Z y se fusiona también en develop (o en la release/* abierta, si existe).

Se usa versionamiento semántico (SemVer 2.0.0) con formato MAJOR.MINOR.PATCH:

Hoja de ruta de versiones del PF2. Mientras el producto sea un MVP en construcción se mantiene MAJOR = 0, lo que en SemVer indica que la API todavía puede cambiar:

Reglas de etiquetado

• Cada repositorio (web, móvil, backend) se versiona de forma independiente, pero al cierre de sprint los tres liberan el mismo MINOR para que la demo sea trazable (v0.1.0 web + v0.1.0 móvil + v0.1.0 backend).
• Los tags son anotados y llevan el prefijo v: git tag -a v0.1.0 -m "Release Sprint 1".
• Solo se crean tags sobre commits de main. Un tag publicado no se mueve ni se borra.
• Versiones previas para validación desde release/* usan sufijo de pre-release: v0.2.0-rc.1.
• Imágenes Docker: se publican con el tag de la versión (0.1.0) y con el SHA corto del commit (sha-1a2b3c4); las construidas desde develop se etiquetan develop + SHA, nunca con número de versión.
• App Android: versionName = versión SemVer; versionCode = entero creciente calculado como MAJOR*10000 + MINOR*100 + PATCH (ej. 0.2.1 → 201).
• Cada liberación actualiza CHANGELOG.md agrupando los cambios por tipo (Added, Changed, Fixed), alimentado por los mensajes de commit de la §1.3.

El detalle de cada workflow de GitHub Actions se documenta en la §1.1.

Configuradas en Settings → Branches (branch protection rules / rulesets) de cada repositorio:

Adicionalmente, en cada repositorio se habilita el borrado automático de ramas tras el merge y se mantienen una plantilla de PR y un archivo CODEOWNERS.

• Ramas cortas: una feature/* no debería vivir más de tres días; si la historia es más grande, se parte en sub-tareas con su propia rama.
• Un propósito por rama: no se mezclan funcionalidades con refactors ni con cambios de infraestructura.
• develop siempre en verde: si el pipeline falla en develop, arreglarlo es la prioridad del equipo antes de fusionar nada más.
• Sin secretos en el repositorio: credenciales en GitHub Secrets o AWS SSM Parameter Store; nunca en código ni en .env versionados.
• El PR describe el porqué: enlace a la historia (HU) y a su tarjeta de Jira, qué cambia, cómo se probó y capturas cuando hay cambios de UI.

Integración y liberación. Con GitFlow, una historia se considera integrada cuando llega a develop por PR revisado; llega a main al cierre del sprint con la release/*.

El acuerdo del equipo, publicado en Home, exige que todo cambio entre por Pull Request y que lo apruebe al menos un integrante distinto del autor. La definición de hecho repite la misma condición: una historia pasa a Hecho cuando el código fue revisado por otro compañero, las pruebas pasaron y la documentación quedó actualizada. Nadie hace push directo a develop ni a main.

La revisión ocurre en GitHub, sobre el Pull Request hacia develop. El autor describe el cambio, enlaza la historia de Jira, indica cómo se probó y adjunta capturas cuando hay interfaz. Solicita revisión a un compañero que no escribió el cambio. El revisor comprueba que el diff cumple la historia, que los checks del pipeline están en verde y que la rama mantiene un solo propósito. Con al menos una aprobación y los status checks en verde, el Pull Request se fusiona con squash and merge y se borra la rama. Si el revisor pide cambios, el autor corrige y sube commits nuevos; una aprobación previa se descarta y la revisión vuelve a empezar.

flowchart TD
  A["Autor toma la historia en Jira<br/>y crea feature/* desde develop"] --> B["Abre Pull Request hacia develop<br/>con historia, pruebas y capturas"]
  B --> C["Solicita revisión<br/>a un compañero distinto del autor"]
  B --> D["GitHub Actions ejecuta<br/>pruebas, Codecov y política de ramas"]
  C --> E{"¿El revisor aprueba?"}
  D --> F{"¿Los checks están en verde?"}
  E -->|Pide cambios| G["El autor corrige y sube commits.<br/>La aprobación anterior se descarta"]
  G --> C
  G --> D
  F -->|No| G
  E -->|Aprueba| H{"¿Hay al menos una aprobación<br/>y los checks en verde?"}
  F -->|Sí| H
  H -->|No| E
  H -->|Sí| I["Squash and merge a develop<br/>y se borra la rama"]
  I --> J["La historia pasa a Hecho<br/>cuando cumple la definición de hecho"]

El autor toma la historia en Jira y abre la rama feature/* desde develop. Al abrir el Pull Request quedan en paralelo la solicitud de revisión y GitHub Actions: pruebas, Codecov y la política de ramas de la §1.7. Si el revisor pide cambios o algún check falla, el autor corrige y los dos caminos se vuelven a ejecutar. El merge ocurre cuando hay al menos una aprobación y los checks están en verde. La historia pasa a Hecho cuando, además, cumple la definición de hecho.

La lectura del diff queda en el compañero. El pipeline informa el resultado de las pruebas y de la cobertura.

La revisión automática de cobertura corre en GitHub Actions y se publica en Codecov. La política está en codecov.yml del repositorio MISO-PROYECTO-FINAL-SOLVENTA. El umbral es 80 % para el proyecto y para el patch (el código nuevo o modificado del Pull Request), con un objetivo por plataforma mediante flags: backend, web y mobile. carryforward: true conserva la cobertura de las plataformas que el Pull Request no toca, de modo que un cambio de una sola plataforma mantiene el indicador de las demás.

flowchart TD
  PR["Pull Request hacia develop, main, release/* o hotfix/*"] --> RUTAS{"Carpetas que cambian"}

  RUTAS -->|apps/mobile| MUT["mobile-pr.yml<br/>JUnit: createDebugUnitTestCoverageReport"]
  RUTAS -->|apps/web| WUT["web-pr.yml<br/>unitarias: pnpm test"]
  RUTAS -->|apps/backend| BUT["backend-unit-tests.yml<br/>pytest unitario, sin integration ni contract"]

  MUT --> MUP["JaCoCo report.xml<br/>flag mobile"]
  WUT --> WUP["lcov.info<br/>flag web"]
  WUT --> WE2E["E2E en el mismo PR<br/>Cucumber y Playwright contra la imagen nginx"]
  BUT --> BUP["coverage.xml<br/>flag backend"]

  MUP --> COV["Codecov<br/>codecov.yml"]
  WUP --> COV
  BUP --> COV

  COV --> UMBRAL{"Patch y cobertura del flag<br/>en 80 % o más"}
  COV -.-> CF["carryforward conserva<br/>la cobertura de las plataformas que el PR no toca"]

  UMBRAL -->|Por debajo| ROJO["Check en rojo en el PR"]
  UMBRAL -->|Cumple| VERDE["Check en verde en el PR"]

  VERDE --> REV["Se espera la aprobación de un compañero"]
  WE2E --> REV
  REV --> MERGE["Squash and merge a develop"]
  MERGE --> ME2E["mobile-e2e.yml<br/>emulador API 34, connectedDebugAndroidTest"]

Al abrirse o actualizarse un Pull Request hacia develop, main, release/* o hotfix/*, GitHub Actions mira qué carpetas cambiaron y dispara el pipeline de esa plataforma.

En móvil, las unitarias generan el informe JaCoCo y lo suben con el flag mobile. En web, las unitarias suben lcov.info con el flag web y, si quedan en verde, Cucumber corre en el mismo Pull Request contra la imagen nginx. En backend, pytest ejecuta las pruebas unitarias y sube coverage.xml con el flag backend.

Codecov aplica el 80 % al código nuevo del Pull Request y a la cobertura del flag de esa plataforma. Con carryforward, la cobertura de las plataformas que el cambio no toca se conserva. Por debajo del umbral el check queda en rojo. Si lo cumple, queda en verde y el Pull Request espera la aprobación de un compañero (§1.6). Después del merge a develop, el móvil ejecuta las pruebas instrumentadas en el emulador.

codecov.yml excluye del cálculo móvil las pantallas Compose que cubren las pruebas en dispositivo: MainActivity.kt, CustomerShell.kt, SplashScreen.kt, IdiomaRegionScreen.kt, IdiomaRegionSheet.kt y PerfilScreen.kt.

Codecov marca en el Pull Request las líneas del diff que quedan por debajo del umbral. La lectura del cambio sigue en la revisión por pares de la §1.6.