Cicd

---
name: cicd
description: "Trigger: ci/cd, pipeline, ci-cd.yaml, GitHub Actions, deploy automático, workflow, staging, canary, rollback. Genera y audita pipelines de CI/CD para los repos de Koder."
license: MIT
metadata:
  author: "Koder-SpA"
  version: "1.0"
---

# CI/CD

Un pipeline convierte el despliegue en un procedimiento repetible: los mismos
pasos, en el mismo orden, cada vez. CI responde *¿este código se puede mergear?*
y CD responde *¿se puede publicar?*

## Activation Contract

Cárgala cuando haya que crear, migrar o auditar un pipeline: no existe
`.github/workflows/`, el despliegue se hace a mano, un workflow falla, o se pide
staging, canary o rollback.

## Hard Rules

- **Nunca escribas un secreto en el YAML.** Van en `secrets.*` o en variables de
  entorno del proveedor. Si encuentras uno en el repo, detente y repórtalo: hay
  que rotarlo antes de seguir.
- **CI corre en cada push y en cada PR; CD solo desde la rama de release.** Un
  workflow de despliegue con `on: push` sin filtro de rama publica cualquier cosa.
- **Un paso que no puede fallar no es una verificación.** Nada de
  `continue-on-error` en lint, tipos o tests.
- **El health check prueba la aplicación, no el proceso.** Un 200 de la raíz
  miente cuando hay catch-all; verifica una ruta real y su contenido.
- **Fija versiones.** `actions/checkout@v4`, no `@main`; la versión de Node y el
  gestor de paquetes salen del repo, no de tu memoria.
- **Un pipeline nuevo arranca en `workflow_dispatch` o en una rama de prueba.**
  No lo conectes a producción sin una corrida en verde.

## Decision Gates

| Situación | Qué generar |
|---|---|
| Repo sin workflows | Solo CI primero: lint, tipos, tests, build |
| CI en verde y despliegue manual | CD con aprobación (*environment* protegido) |
| Equipo con CD estable y buena cobertura | Despliegue continuo, sin aprobación |
| Frontend en Vercel | CI en GitHub Actions; el deploy lo hace Vercel |
| Backend en contenedor | Build de imagen, push al registry, deploy, health check |
| App móvil | `eas build` y `eas submit`, nunca en el mismo job que la web |
| Se pide reducir el riesgo del release | Lee `references/strategies.md` |

## Execution Steps

1. Detecta stack, gestor de paquetes y scripts reales (`package.json`), y qué
   ramas existen. No asumas `npm` ni `main`.
2. Confirma dónde se despliega hoy y quién tiene acceso al proveedor.
3. Copia la plantilla de `assets/` que corresponda y ajústala a esos scripts.
4. Deja los secretos como `secrets.NOMBRE` y entrega la lista de los que hay que
   cargar.
5. Corre el workflow una vez a mano y pega el resultado.
6. Si el repo es de un cliente, abre la issue de Jira antes de commitear.

## Output Contract

Devuelve: archivos creados, secretos pendientes de cargar, qué verifica cada job,
qué dispara el despliegue y cómo se revierte.

## References

- `assets/ci-node.yml` — CI: lint, tipos, tests y build.
- `assets/cd-docker.yml` — imagen, registry, deploy y health check.
- `assets/cd-expo.yml` — build y envío de la app móvil.
- `references/strategies.md` — rolling, blue-green, canary y rollback.
- `references/gotchas.md` — fallas reales ya vistas en los repos de Koder.