Staging pipelines y lanzamientos

1) ¿Por qué necesitas un staging-pipeline?

• reproducibilidad del ensamblaje y la versión;
• fidbeck rápido y predecible;
• minimización del riesgo (descomposición progresiva, flagelación, retroceso);
• cumplimiento y control de cambios.

2) Flujo de referencia de suministro (alto nivel)

1. PR → revisiones automáticas (lint, unit, SAST, licencias).
2. Build → una imagen/paquete determinista, firma y SBOM.
3. Test on Ephemeral → previsualización per-PR.

• el deploy de la imagen;
• pruebas contractuales, de integración, e2e;
• DAST/IAST, retrocesos, smoke de carga;
• UAT/QA manuales si es necesario.
• 5. Release Candidate (RC) → freeze window → Prod (canary/blue-green).
• 6. Comprobación post-deploy y autocontrol por SLO/error budget.
• 7. Runbook/Changelog → cierre de lanzamiento y retrospectiva.

3) Plantilla de paipline YAML estándar (extracto)

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4) Gates y criterios de preparación (Quality Gates)

Código y seguridad: lentes, cobertura, SAST/SCA, política de dependencia, sin «critical/high».
Contratos: Compatibilidad de esquemas (API/eventos), Comprobación Nat/Buf.
Pruebas: unit/integration/e2e p-umbral de paso, estabilidad (flake-rate).
Smoke de carga: p95/p99 dentro del presupuesto, no hay degradación.
DAST/IAST: no hay findings críticos, scripts de prueba de espuma para rutas sensibles.
Observabilidad: dashboards/alertas «as code» actualizados, runbooks adjuntos.
AMB/UAT: confirmación en las ventanas de lanzamiento (si la regulación/negocio lo requiere).

5) Estrategias de lanzamiento

Canary - aumento gradual de la proporción de tráfico (5% → 25% → 50% → 100%), roll-forward/rollback automático por SLO y anomalías.
Blue-Green - ambientes paralelos; interruptor instantáneo, simple retroceso.
Feature Flags es la inclusión lógica de un fich sin redeploy; posibilidad de «dark launch» y A/B.
Shadow/Traffic Mirroring es una ejecución pasiva del tráfico a la nueva versión sin afectar a los usuarios.
Ring Deployments - Ondas por regiones/tenantes.

6) Políticas de reversión y seguridad de lanzamientos

Activación automática: aumento de la tasa de error, p95/TTFB por encima del umbral, crecimiento de 5xx/timeout, aumento de DLQ.
Retroceso manual: comando '/rollback <service> <sha> 'en el chatbot, un botón en la consola de lanzamiento.
Windows Freeze: se prohíbe la liberación en eventos críticos (torneos/partidos de máxima audiencia).
Changelog & Release Notes: generación a partir de PR, etiquetas SemVer, componentes, migraciones.

7) Migración e interoperabilidad de la DB

1. agregar campos/índices compatibles;

2. deploy de la aplicación (lee/escribe en ambos esquemas);

3. migración de datos por parte de los jobs de fondo;

4. eliminar el antiguo.

Esquemas versionados, migraciones idempotent, dry-run a staging.

Nat destructive SQL: require flag/approval, backups automáticos y plan-check.

8) Fichflags y activación progresiva

Separe las marcas ops (para una operación segura) y las banderas product.
Inclusión por audiencia: porcentaje, geo, tenant, rol.
Métricas de bandera: impacto en la conversión, latencia, errores.
En caso de problemas, la convolución de la bandera es más rápida que la reversión.

9) Observabilidad como parte del lanzamiento

Tracks: end-to-end 'trace _ id' desde gateway hasta DB/colas; comparación de versiones anteriores/nuevas.
Métricas: p50/p95/p99, error-rate, RPS, saturación, DLQ, retrae, Time-to-Wallet/Business KPI.
Logs: estructurado, enmascarado PII, correlación 'request _ id'.
Alertas: Presupuesto SLO, páginas de emergencia on-call, auto-convolución de lanzamiento.

10) Seguridad de la cadena de suministro (cadena de suministro)

SBOM para cada build, almacenamiento y enlace a la etiqueta de versión.
Firmas de imagen (cosign), validación en el clúster (policy admission).
Certificación SLSA: origen probado del artefacto.
Policy-as-Code (OPA/Conftest): deny-by-default para PR de infraestructura.
Secretos: sólo de KMS, fichas de vida corta, rotaciones en pipelines.

11) Control de cambios y procesos

RFC → CRQ → CAF: el cambio documentado de comportamiento/contratos se acuerda de antemano.
Release Calendar: ventanas visibles por producto/región/comando.
Runbooks: para cada componente: procedimientos de activación/reversión/diagnóstico.
Postmortem/Retro: después de lanzamientos significativos - análisis y acciones.

12) Perfiles de pruebas de staging

Contrato (API/Eventos): bloquea los cambios incompatibles.
Integración/e2e: escenarios de extremo a extremo «depósito», «KYC», «retiro».
Smoke de carga: picos representativos; vigilamos los límites de recursos.
Escenarios de caos: desconexión del proveedor, aumento de la latencia, flappings de red.
Monitoreo sintético: transacciones de «prueba» programadas.

13) Ejemplo Makefile de objetivos de lanzamiento (fragmento)

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14) Funciones y responsabilidades

Dev/Team: calidad del código, pruebas, migraciones, runbooks.
QA: escenarios UAT/regeneración, control de calidad en gates.
SRE/Plataforma: fiabilidad de pipelines, observabilidad, políticas.
Release Manager: calendario, ventanas, AMB, solución final.
Seguridad: SAST/DAST/SCA, cadena de suministro, política de secretos.

15) Modelo de madurez de lanzamientos

1. Básico - comprobaciones manuales, lanzamientos raros, retrocesos son difíciles.
2. Avanzado - CI/CD estandarizado, contorno staging, canario/azul-verde, lanzamientos frecuentes.
3. Experto - envío progresivo por tenantes/regiones, feature flags-first, policy-as-code, autocontrol por SLO, trazabilidad completa y SLSA.

16) Hoja de ruta para la implementación

M0-M1 (MVP): plantilla de paipline, build + sign + SBOM, staging deploy, pruebas básicas y gates.
M2-M3: canary/blue-green, previsualización per-PR, pruebas de contrato, DAST, cheques synthetic.
M4-M6: feature flags plataforma, shadow traffic, policy-as-code, autotchat, release calendar + AMB-workflow.
M6 +: ring-deployments por región, certificación SLSA y estricta admision, automatización completa de runbooks.

17) Lista de comprobación antes del lanzamiento

• La imagen está firmada, el SBOM está cargado y enlazado a la versión.
• Los contratos son compatibles, las pruebas son verdes, e2e han pasado en staging.
• Las migraciones son validadas (dry-run), el respaldo está listo, se describe el plan de reversión.
• Los dashboards/alertas están actualizados, las gatitas SLO están activas.
• Runbook y Changelog se publican, las ventanas de lanzamiento son coherentes.
• Feature flags están configurados para la activación progresiva.
• Freeze-restricciones cumplidas, on-call listo.

Salida breve

Un staging-pipeline bien diseñado convierte los lanzamientos en una rutina manejable: plantillas únicas, gates de calidad clara, cadena de suministro segura, alineación progresiva y observabilidad reducen el riesgo y reducen el tiempo de salida de los cambios en la producción, manteniendo el control de la calidad y las métricas de negocio.