Cap 8: Skills de Despliegue y Operaciones
Pipeline de release
flowchart LR
QA[QA aprobado] --> SHIP[/ship/]
SHIP --> PR[PR abierto]
PR --> LAND[/land-and-deploy/]
LAND --> PROD[Producción]
PROD --> CANARY[/canary/]
CANARY --> DOC[/document-release/]
DOC --> RETRO[/retro/]
/setup-deploy
Configuración única del pipeline de despliegue para el proyecto.
Auto-detección de plataforma:
| Plataforma | Detección |
|---|---|
| Fly.io | Presencia de fly.toml |
| Render | render.yaml |
| Vercel | vercel.json o .vercel/ |
| Netlify | netlify.toml |
| Heroku | Procfile |
| GitHub Actions | .github/workflows/ |
Qué configura:
- URL de producción
- Health check endpoint
- Comandos de deploy
- Variables de entorno requeridas
Ejecutar una vez por proyecto. Los skills subsiguientes usan esta configuración automáticamente.
/ship
La máquina de release completa. Un comando para ir de código limpio a PR abierto.
Secuencia de pasos:
sequenceDiagram
participant S as /ship/
participant Git as Git
participant CI as CI/CD
participant GH as GitHub
S->>Git: Sync con main (rebase)
S->>CI: Ejecutar tests locales
CI-->>S: Tests: 42 → 47 (+5 nuevos)
S->>S: Auditar cobertura
S->>Git: Push al remote
S->>GH: Abrir PR con resumen
GH-->>S: PR #123 creado
PR body generado automáticamente:
## Changes
[resumen del diff]
## Tests
Tests: 42 → 47 (+5 nuevos)
Coverage: 78% → 82%
## Screenshots
[before/after si hubo cambios visuales]
Bootstrap de tests:
Si el proyecto no tiene framework de tests configurado, /ship lo inicializa automáticamente antes de proceder.
/land-and-deploy
Completa el pipeline desde PR aprobado hasta producción verificada.
Proceso:
sequenceDiagram
participant L as /land-and-deploy/
participant GH as GitHub
participant CI as CI/CD
participant PROD as Producción
L->>GH: Merge PR (squash o merge commit)
L->>CI: Monitorear CI pipeline
CI-->>L: CI passed ✅
L->>PROD: Ejecutar deploy command
PROD-->>L: Deploy completado
L->>PROD: Health check GET /health
PROD-->>L: HTTP 200 ✅
L->>L: Verificar páginas críticas
L-->>User: Producción verificada ✅
Si el health check falla: El skill alerta inmediatamente con el error y no procede — no hace rollback automático (requiere decisión humana).
/canary
Monitoreo post-deploy continuo durante la ventana de canary.
Qué monitorea:
- Errores de consola del browser en páginas críticas
- Regresiones de performance vs. baseline pre-deploy
- Fallos de carga de página (4xx, 5xx)
- Cambios inesperados en network requests
Flujo:
/canary --duration 30m --pages "/,/dashboard,/checkout"
# Monitorea las 3 páginas durante 30 minutos
# Alerta inmediata si detecta regresión
# Reporte final al completar el período
Output al finalizar:
Canary report (30m):
Pages monitored: 3
Console errors: 0
Performance regressions: 0
Failed requests: 0
Status: ✅ CLEAN
/document-release
Actualiza toda la documentación del proyecto para que coincida con el código desplegado.
Qué revisa y actualiza:
README.md— comandos desactualizados, pasos de instalaciónCHANGELOG.md— agrega entry del release- Docs de API — endpoints nuevos o modificados
- Docs de configuración — variables de entorno agregadas
Por qué automatizar esto:
La documentación obsoleta tiene costo real: developers que siguen pasos incorrectos, onboarding roto, issues de soporte innecesarios. Automatizar la actualización al momento del deploy elimina el decay gradual.
/retro
Retrospectiva semanal con métricas del equipo.
Métricas por persona:
- Líneas de código desplegadas
- PRs mergeados
- Bugs encontrados vs. introducidos
- Test coverage delta
Métricas del equipo:
- Shipping streak (días consecutivos con deploys)
- Ships más grandes del período
- Tendencia de test health
- Tiempo promedio PR → producción
Output:
Retrospectiva — semana 2026-W13
Top ships:
1. Sistema de notificaciones — 2,400 LOC
2. Migración de auth a OAuth — 890 LOC
Métricas:
PRs mergeados: 12
Tests: 234 → 267 (+33)
Shipping streak: 5 días 🔥
Tendencia: Coverage subiendo, tiempo de deploy bajando ✅
Flujo completo de un release
# 1. Setup inicial (solo una vez)
/setup-deploy
# 2. Durante el sprint — después de QA
/ship
# 3. Cuando el PR esté aprobado
/land-and-deploy
# 4. Los primeros 30 minutos post-deploy
/canary --duration 30m
# 5. Actualizar docs
/document-release
# 6. Al final de la semana
/retro