Cap 8: Skills de Despliegue y Operaciones

Por: Artiko
gstackdeployshipci-cdproduccion

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:

PlataformaDetección
Fly.ioPresencia de fly.toml
Renderrender.yaml
Vercelvercel.json o .vercel/
Netlifynetlify.toml
HerokuProcfile
GitHub Actions.github/workflows/

Qué configura:

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:

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:

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:

Métricas del equipo:

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