Playbooks

CI/CD

Salir

Pipeline

El pipeline es el esqueleto de tu proceso de delivery. Cada stage es un guardián. Si un guardián se duerme, la porquería llega a producción.

1
📦
Install
Instalá dependencias con cache. Usá lockfile (pnpm-lock.yaml). Nada de npm install sin --frozen-lockfile.
2
🔍
Lint
Estilo y errores obvios. Debe fallar el pipeline si hay warnings. Cero tolerancia.
3
🔷
Type check
TypeScript strict mode. Si el tipo no compila, no pasás. Es tu primera línea de defensa contra bugs tontos.
4
🧪
Test crítico
Unit + integration. Paralelizá. Si tardan más de 5 minutos, algo anda mal con la suite o con la arquitectura.
5
🏗️
Build crítico
Generá el artefacto de deploy. Docker image, static bundle, o lo que uses. El artefacto debe ser inmutable.
6
🔐
Security scan
Dependency audit + SAST. No bloquees el pipeline por vulnerabilidades low, pero sí por critical/high.
7
🚀
Deploy staging crítico
Automático al mergear a main. Si falla en staging, no llega a producción.
8
💨
E2E smoke test crítico
Contra staging. Solo los flujos críticos. Si falla, bloquea el deploy a producción.
9
✅
Deploy production crítico
Manual o con approval gate. Nadie deploya a prod un viernes a las 6pm.

Entornos

Cuatro entornos, cuatro propósitos. Mezclarlos es la causa #2 de incidentes en producción (la #1 es deployar sin testear).

Local
Propósito Desarrollo individual
Datos DB local + seeds
Deploy Manual (pnpm dev)
Destruir Libre. docker compose down sin miedo.
Preview
Propósito Por PR. Efímero
Datos DB clonada de staging
Deploy Automático por PR
Destruir Al cerrar el PR. No acumules entornos muertos.
Staging
Propósito Pre-producción
Datos Anonimizada, realista
Deploy Automático al mergear a main
Destruir Nunca. Se resetea periódicamente con datos frescos.
Production
Propósito Usuarios reales
Datos Real. Backups cada hora
Deploy Manual con approval
Destruir Nunca. Solo rollback a versión anterior.
1. Cada entorno tiene sus propias credenciales. Nunca uses secrets de producción en staging o desarrollo.
2. Staging debe ser lo más parecido a producción posible. Misma versión de DB, mismos workers, mismas configs.
3. Preview environments por PR son oro puro. El reviewer puede probar el cambio sin levantarlo localmente.
4. Nadie tiene acceso directo a producción por SSH. Todo cambio pasa por CI/CD. Sin excepciones.
5. Rotá secrets periódicamente. Un secret que no rota es un secreto que ya no es secreto.

Estrategias de deploy

Cómo llega tu código a producción es tan importante como el código mismo. El deploy perfecto es el que el usuario no nota.

🔄 Rolling
Reemplazá instancias de a una. Sin downtime, pero con riesgo de inconsistencias durante el rollout.
Cuándo: APIs stateless. Backends que no dependen del estado de otras instancias.
🔵🟢 Blue-Green
Dos entornos idénticos. Deployás en green, redirigís tráfico. Rollback instantáneo: volvés a blue.
Cuándo: Sistemas críticos donde el rollback debe ser instantáneo. Cuesta el doble en infraestructura.
🐤 Canary
Deployás a un pequeño % de usuarios. Monitoreás errores. Si todo bien, aumentás gradualmente.
Cuándo: Cambios de alto riesgo. Features nuevas con incertidumbre de performance. Necesitás buen monitoreo.
🚩 Feature flags
Deployás el código "dormido". Lo activás por configuración sin redeploy. Rollback = desactivar el flag.
Cuándo: Features grandes que querés probar en producción con usuarios reales de forma controlada.

Feature flags

1. Cada flag tiene dueño y fecha de expiración. Un flag sin dueño es deuda técnica acumulándose.
2. El flag debe ser removido del código cuando la feature está estable. Flags viejos = complejidad innecesaria.
3. Naming consistente: feat-nombre-de-la-feature. Usá un servicio de feature flags, no variables de entorno.
4. Testeá con el flag ON y OFF. Los tests deben cubrir ambos caminos mientras el flag existe.

QA Gates

Cada gate es una pregunta binaria: ¿este cambio está listo para avanzar? Si la respuesta es no, el pipeline se detiene. Sin excepciones.

Lint & Format Block
Bloquea el merge si hay errores. Warnings no bloquean pero se registran.
Type check Block
TypeScript estricto. Cero any sin justificar. Si no compila, no mergea.
Unit tests Block
Cobertura mínima 80%. Si bajás coverage, el PR necesita justificación explícita.
Integration tests Block
Contra DB real. Si rompés un contrato, el test te lo grita.
Bundle size Warn
Alertas si el bundle crece más de 10%. No bloqueante pero visible.
Security audit Block
Bloquea si hay vulnerabilidades critical o high. Medium y low se registran.
Code review Block
Mínimo 1 approve. El autor no puede aprobar su propio PR.
Manual approval Block
Solo para producción. Requiere approve de lead tech o DevOps.