Lanzamiento progresivo y filetes

(Sección: Arquitectura y Protocolos)

1) Por qué envío progresivo

El esquema clásico "dev → test → staging → prod' no garantiza la seguridad: cuanto más cerca de la producción, mayor es el riesgo de inconsistencia. El lanzamiento progresivo minimiza el blast radius, aumentando gradualmente la proporción de tráfico/audiencia y reforzando las soluciones con métricas y SLO. En conjunto con los filetes, esto da: cero downtime, retroceso rápido, repetibilidad del proceso y control de calidad medible.

2) Términos

Los steijings (entornos) son las etapas formales del ciclo de vida del artefacto: 'dev', 'ci', 'qa/test', 'staging/pre-prod',' prod', así como el entorno ephemeral/preview debajo de las ramas del fiche.
Lanzamiento progresivo (progressive delivery): inclusión por etapas de la versión/fich: canary, porcentaje rollout, ring-deploy, fichflags, dark-launch, tráfico de sombras.
Gates - Criterios de tolerancia automáticos (error rate, p95, métricas de negocio, presupuesto de error de SLO).
La promoción del artefacto es la promoción del mismo build firmado entre los steijings (artefacto immutable).

3) Mapa de los alrededores y su propósito

3. 1 Básico

Dev (local/sandbox): ciclos rápidos, enchufes de dependencia, seguridad mínima.
CI (stands de integración): pruebas de unit/integración/contratación, análisis estático, SCA/SAST.
QA/Test: e2e, carga, regresión. Los datos son sintéticos o enmascarados.
Staging/Pre-prod: lo más posible "como prod': la misma configuración, casillas de verificación, límites, procesamiento de fondo.
Prod: tráfico de combate, SLO/SLI, alertas, planes de retroceso.

3. 2 Adicionales

Ephemeral/Preview per PR: auto-creación del stand en pull-request, auto-demolición en merge/close.
UAT/Sandbox para equipos empresariales: aceptación, demostraciones, escenarios de aprendizaje.
Laboratorio de rendimiento: experimentos de carga aislados (generadores de tráfico, réplicas de datos).

4) Principios de Estaging Sostenible

Configuración como código (IaC, GitOps), la deriva del entorno se elimina mediante código y validaciones automáticas.
Artefactos idempotentes, firmados (SBOM, Provence, Attestations), un solo build → multi-stage deploy.
Paridad con la venta: versiones de rantime, límites, políticas de red, banderas incluidas. La diferencia es sólo en secretos/datos.
TDM (test data management): sintético/enmascarado, migraciones y sides como parte de una paipline.
Observabilidad por diseño: etiquetas de lanzamiento, correlación logs/tracks, dashboards unificados en todas las etapas.

5) Modelo de lanzamiento progresivo

5. 1 Instrumentos de enfoque

Fichflags: activar/desactivar la funcionalidad por segmentos (país, cliente, acount, random seed).
Canario: 1-5-10-25-50-100% de tráfico con gatitos en cada paso.
Ring-deploy: extensión por anillos (internal → employees → beta → public).
Blue-Green: flip atómico para grandes actualizaciones de plataformas.
Dark-launch: ejecución oculta sin afectar al usuario (recolección de métricas).
Shadow-traffic: replica las solicitudes a una nueva versión sin responder al usuario.

5. 2 Puertas automáticas

Techetrics: error rate, p95/p99, saturation, queue lag.
Métricas de negocio: autorizaciones, conversiones de pago, denegación de pasos de embudo.
SLO/error budget: parada rápida con un presupuesto de error de combustión acelerada.
Estado: mínimo tiempo/volumen de tráfico por paso para no tomar decisiones «sobre el ruido».

6) Cadena modelo CI/CD (referencia)

1. Commit/PR → Build: una sola imagen/paquete, firma, SBOM.
2. CI-тесты: unit/integration/contract + security (SAST/SCA/secret-scan).
3. Vista previa de Ephemeral: Soporte de elevación automática para verificación manual/UX.
4. QA/Test: e2e + carga + pruebas de caos (opcional).
5. Staging: smoke, regresión de rutas de usuario críticas, comprobación de migraciones de DB.
6. Prod canary: 1-5% del tráfico de → Gate → 10-25-50-100%.
7. Retroceso/finalización: en caso de problemas - auto-rollback; Si tiene éxito, contrae la versión anterior.

7) Gestión de datos y esquemas

Expand-migrate-contract: migraciones hacia atrás compatibles, transferencias de fondo, checkpoints, idempotencia.
Doble precisión de escritura (dual-write) con deduplicación o «outbox transaccional».
Masking/editar datos prod para staging (legal y técnicamente seguro).
Caché/sesiones: almacenamiento externo, inicio cálido, política de discapacidad en flip.

8) Seguridad y cumplimiento

Secretos: KMS/Secrets Manager, rotation, el principio de los privilegios más pequeños.
Aislamiento de staging: redes/cuentas/proyectos; prohibición de sincronización aleatoria con prod.
Auditoría/trace de lanzamiento: quién/qué/cuándo rodó, versión del artefacto, change approval.
Entregas de software: verificación de firma, política de confianza en los registros, prohibición de «latest».

9) Observabilidad y explotación

Formato único de etiquetas: '{service, version, commit, stage, region, ring}'.
Comparación con baseline: canario vs versión estable en los mismos gráficos.
Alertas por SLO: productos y técnicos, diferentes umbrales para Canarias.
Seguimiento post-lanzamiento: no menos de N horas/día para los efectos detenidos.

10) Revisiones y planes de accidentes

Botón/comando de retroceso: parte de la pipeline (no kraft manual).
La promoción inversa de la bandera es más rápida que la depla (kill-switch).
Contramedidas de datos: repeticiones idempotentes que compensan transacciones, deduplicación.
Incidencias de playbooks: quién toma la decisión, canales de comunicación, plantillas de mensajes.

11) Costo y rendimiento

Los entornos efímeros ahorran dinero si se eliminan de forma agresiva.
Blue-Green es un múltiplo más caro durante el tiempo de lanzamiento; canario más barato, pero requiere métricas maduras.
Auto Skaling por carga y por ventana de lanzamiento; cuotas de pre-stands.

12) Anti-patrones frecuentes

La deriva de los alrededores: revisiones manuales en los stands, «es algo pequeño».
Un build por entorno: rebuild per stage → bugs prod «no reproducibles».
Pruebas de datos irrelevantes: pruebas «verdes» cayendo en venta.
Falta de gates: lanzamientos de sensaciones en lugar de SLO.
TTL de larga duración en DNS bajo Blue-Green; sin stickiness en el tráfico parcial.
Mezcla de esquemas de DB incompatibles con canary/stable.

13) Hojas de cheques

Antes de la promoción en staging

• La imagen está firmada, el SBOM está recogido, las vulnerabilidades de nivel de creta están cerradas.
• Las migraciones de DB son reversiblemente compatibles (expand).
• Los datos de las pruebas están enmascarados/sintéticos.
• Los dashboards/alertas para la nueva versión están listos.

Antes de salir en prod

• Plan canario con pasos y umbrales aprobados.
• Kill-switch y el plan de reversión se verifican en staging.
• Traffic shadow o dark-launch se ejecutan (si es posible).
• On-call notificado, hora de la ventana acordada.

Después de la versión

• El monitoreo por SLO es estable N horas.
• Se han aplicado limpiezas/migraciones de «contrato».
• Retrospectiva y apdate de playbacks.

14) Opciones de implementación por arquitecturas

Monolito: preview stands + Blue-Green, y fiches a través de banderas; canario limitado por URL/cookies.
Microservicios: canary/ring son naturales; gestión estricta de contratos (CDC), versionamiento de API.
Servicios Stateful: Blue-Green con calefacción y un plan de migración claro; colas individuales/topics per version.

15) Pipeline de referencia c GitOps (boceto)

El repositorio app (código) libera el artefacto → pone el manifiesto en el repositorio env.
El agente GitOps (Argo CD/Flux) sincroniza 'env/dev', 'env/qa', 'env/staging', 'env/prod'.
Promoción - a través de pull-request al directorio del stage deseado; Merge desencadenará el rodillo y las puertas.

16) Gestión de hiches y audiencias

Segmentación por: tipo de cliente, país, dispositivo, versión de la aplicación, coort AB, hora del día.
Expansión gradual: 1% → interno 5% beta → 25% clientes tempranos → 100% todos.
Experimentos A/B y multivariantes para hipótesis de productos sobre el mismo mecanismo de banderas.

17) Escenarios prácticos

Escenario 1: nueva integración de pagos

1. Soporte Ephemeral per PR, retroceso QA. 2) Staging smoke + proveedor de sandbox.
2. Prod canary 1% por encabezado 'X-Cohort = internal'. 4) Gates: error rate de pago, p95 callback, fracción de transacciones exitosas.
3. 1→5→25→50→100%; en degradación - kill-switch.

Escenario 2: actualización de rantime (JDK/Node/OS)

Blue-Green a nivel de clúster: Green se calienta, migraciones «expand», flip, observación, flip back cuando hay problemas.

Escenario 3: UI-fich de alto riesgo

Dark-launch + fichflag sólo para usuarios beta, recolección de métricas UX, expansión gradual de la audiencia.

18) Conjunto mínimo de herramientas

CI: build, pruebas, firma, SBOM.
CD/GitOps: Argo CD/Flux/Spinnaker o herramientas nativas en la nube.
Routing: Ingress/Service Mesh (weighted, header/cookie based).
Fichflags: LaunchDarkly/Unleash/OpenFeature/servicio de autocopiado.
Observabilidad: métricas, registros, trazados, alertas; dashboards unificados per stage.
TDM: enmascaramiento, siding, generadores sintéticos.
Seguridad: secretos, KMS, política de registro, validación de dependencias.

19) Breve resumen

El lanzamiento progresivo es una combinación de inclusión por etapas y una estricta disciplina de estaging. El éxito se mantiene en cuatro pilares: artefactos immutables, autogates SLO, esquema de datos reversible y retroceso rápido. Agregue previsualizaciones, GitOps y fichflags, y su lanzamiento será predecible, seguro y rápido.