Proceso de aprobación de versiones
1) Objetivo y zona de responsabilidad
El proceso de aprobación de lanzamientos proporciona cambios predecibles y seguros en la plataforma sin violar el SLO, los ingresos y el cumplimiento. Abarca todo el camino: desde el pull request hasta la promoción completa en prod y post-monitoreo.
2) Principios
1. SLO-first: sólo se permite la liberación con SLI verde/sin burn-rate.
2. Lotes pequeños y reversibilidad: envío canario/progresivo, rollback rápido.
3. Policy-as-Code: gates, SoD, ventanas libres y clases de riesgo - se verifican automáticamente.
4. Una única fuente de verdad: artefactos/confecciones/banderas - en Git, el entorno es dado por GitOps-reconsailer.
5. Auditoría y probabilidad: registros WORM, huella de toma de decisiones, propietarios claros.
6. Seguridad predeterminada: secretos por separado, privilegios mínimos, geo-gates.
7. Comunicaciones sin sorpresas: plantillas preparadas para actualizaciones internas/externas.
3) Roles y RACI
Release Manager (RM) - propietario de la línea de montaje, calendario, puertas. A/R
Service Owner (SO): el propietario del dominio, acepta el riesgo, prepara los artefactos. A/R
SRE/Platform - SLO-gates, ranuras, auto-patines. R
QA Lead - estrategia de verificación, resultados de pruebas. R
Seguridad/Compliance - escaneos, SoD, regulación. C/A
AMB (Change Advisory Board) es una solución de clase Normal. A
In-call IC/CL - Preparación para incidentes y comunicaciones. R/C
Stakeholders (Biz/Support/Partners) - Información. I
4) Clases de cambio y rutas de negociación
Aumento de grado - al cruzar los límites de riesgo (pagos, RG, PII, límites).
5) Transportador de lanzamiento y puerta (flujo de extremo a extremo)
Etapa 0. Planificación y calendario
Ventanas libres (vacaciones/partidos), elefante on-colla y CL, preparación de plantillas de estado.
la Etapa 1. PR → Build
Linters/licencias, SBOM, pruebas de unidad/contrato, secreto-escaneo.
Etapa de 2 Integración/Seguridad
E2E (proveedores virtualizados de PSP/KYC), SAST/DAST, revisión de la dependencia.
la Etapa 3. Staging/Ensayo
Paridad con la venta, migraciones con reversibilidad, flejes de 5-25%, lista de comprobación «release drill».
Puerta A - Calidad y seguridad (obligatoria)
+ todas las pruebas/escaneos verdes
+ circuitos/confiscaciones son válidos, no hay «rojo» SLI staging
+ SoD/4-eyes para cambios de alto riesgo
Etapa de 4 Preprodo (entrega en Canarias)
1-5% de tráfico por segmentos (tenant/geo/banco), validadores runtime, guardrails.
Gate B - SLO/Business Gate
+ no hay degradación de SLO/KRI (latencia/error/pago)
+ no hay SRM/anomalías en las métricas de experimentación
+ Comms listo: borrador de estado/socios
la Etapa 5. Ramp-up → 25% → 100% (región/tenant)
Promoción paso a paso con temporizadores post-monitoreo.
Etapa 6. Seguimiento posterior (30-60 minutos)
Dashboard lanzamiento, burn-rate, quejas/tickets, auto-cierre/rollback en caso de irregularidades.
6) Soluciones automatizadas (policy-engine)
Pseudo-reglas:- SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
- PII-export: `require dual_control if config. affects == "PII_EXPORT"`
- Freeze: `deny deploy if calendar. freeze && not emergency`
- Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`
7) Artefactos de lanzamiento
Release Manifeste (obligatorio): objetivo, clase de riesgo, áreas (tenant/region), banderas, migraciones, plan de laminación, plan de reversión, propietario, contactos on-call.
Evidence Pack: resultados de pruebas/escáneres, capturas de pantalla staging dashboard, migraciones dry-run.
Kit Comms: plantillas de estado (interno/externo/socios), ETA/ETR.
Plan de retroceso: pasos de retroceso precisos y criterios en los que se activa.
yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"8) Canarian/Blue-Green/Feature-Flag laminado
Canary es un default seguro: cobertura pequeña, segmentación por GEO/tenant/BIN.
Blue-Green - para cambios duros: cambiar de ruta, retroceso rápido.
Las banderas son para fiches de comportamiento: TTL, kill-switch, guardrails, SoD.
9) Gestión de confecciones y secretos
Las confecciones como datos, esquemas y validadores; GitOps se promociona con un detector drift.
Secretos: en KMS/Secret Manager, acceso JIT, auditoría y enmascaramiento.
10) Comunicaciones y estado de las páginas
Interno: war room/chat, alerta on-coll, plantillas de apdate.
Externo: publicaciones sólo a través de CL, borradores preconstruidos.
Partners (PSP/KYC/Studio): notificaciones targeted cuando las integraciones se ven afectadas.
Estado: la liberación no es un incidente, pero tiene una ventana de observación con métricas.
11) Lanzamientos de emergencia (Emergencia)
Desencadenantes: P1-degradación, vulnerabilidad, riesgos PII/RG.
Camino: solución IC + RM → conjunto mínimo de puertas (linter/ensamblaje) → canario 1-2% → monitoreo → promoción.
Obligatoriamente: post-factum AMB, post-mortem ≤ D + 5, documentación de compromisos.
12) Auditoría, SoD y cumplimiento
SoD/4-eyes: cambios de routing PSP, límites de bonificaciones, exportaciones de datos.
WORM-journal: quién/qué/cuándo/por qué; versiones de directivas; diff de lanzamiento/banderas/configuraciones.
Geo/Privacidad: datos y registros en la jurisdicción correcta; ausencia de PII en los artefactos.
13) Vigilancia y post-control
Lanzamiento de Dashboard: SLI (Auth-success, bet→settle p99), error-rate, quejas, conversiones, lotes de colas.
Alertas: burn-rate, SRM, crecimiento 5xx, degradación PSP por banco/GEO.
Informes: CFR, incidentes de liberación MTTR, tiempo promedio de post-monitoreo, tasa auto-rollback.
14) Proceso KPI/KRI
Lead Time for Change (PR→prod), Change Failure Rate, incidentes de lanzamiento MTTR.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Coverage of Release Drill (ensayos de estaging), SoD violaciones (el objetivo es 0).
Comms SLA (disponibilidad de borradores, cumplimiento de temporizaciones).
15) Hoja de ruta para la implementación (6-10 semanas)
Ned. 1-2: determinar las clases de cambio, las gates y los artefactos; habilitar los linters, SBOM, secreto-escáner; calendario de lanzamientos y freeze.
Ned. 3-4: GitOps para confecciones, canary/blue-green, SLO-gates, patrones Comms y war room.
Ned. 5-6: policy-engine (SoD/4-eyes, risk-rules), auto-rollback por métricas; dashboard de lanzamientos.
Ned. 7-8: ensayos (staging drills), integración con fichflags/incidente-bot, informes KPI/KRI.
Ned. 9-10: auditoría de WORM, ejercicios de DR de lanzamientos, optimización de CFR, aprendizaje de roles (RM/SO/CL/IC).
16) Antipattern
Lanzamientos sin reversibilidad y canarios → incidentes masivos.
Ignora las puertas de SLO «por el bien de la línea de salida».
Confecciones/banderas sin circuitos y TTL → estados «congelados».
Clics manuales en venta sin Git/auditoría.
Apdates públicos sin rol de CL y plantillas.
Secretos en el repositorio; accesos sin JIT y registro.
AMB como freno sin datos: las soluciones deben estar respaldadas por métricas de lanzamiento.
Resultado
El proceso de aprobación de lanzamientos es un marco de ingeniería y gestión que conecta calidad, seguridad y velocidad: políticas como código, SLOs, entrega progresiva, comunicaciones transparentes y auditoría probada. Este enfoque reduce el CFR y el MTTR, protege los ingresos y el cumplimiento y permite a los equipos producir valor de forma frecuente y segura.