Operaciones y Administración → Ciclos de versiones y actualizaciones

Ciclos de lanzamiento y actualización

1) Asignación

• reduce la incertidumbre y el costo de la coordinación,
• reduce el riesgo de incidentes y retrocesos,
• sincroniza la técnica con los eventos empresariales (marketing, deportes, fin. informes),
• eleva a través de un comando sin crecimiento CFR (Change Failure Rate).

2) Modelos de lanzamiento: qué elegir

1. Tren Release (trenes) - ranuras fijas (p. ej., w/hora 10:00 EET).

Adecuado para monolitos de varios equipos y cambios de dominio «pesados».

2. Continuous Delivery (bajo petición) - Cada merge que ha pasado por las puertas de la calidad puede ir a la perfección.

Adecuado para microservicios y cultura feature-flag.

3. Híbrido - frentes de productos en los trenes, servicios de backend «bajo demanda».

Criterios de selección: madurez de las pruebas/observabilidad, dependencia de socios externos (PSP/KYC), requisitos de cumplimiento, tamaño de la organización.

3) Calendario de lanzamiento y ventanas

Calendario único (empresa-wide): ranuras de lanzamiento, migraciones de DB, campañas de marketing, grandes eventos deportivos, períodos de reportes.
Períodos libres: ventanas bien definidas cuando sólo se permite hotfix P1 (por ejemplo, final LF, viernes negro, informes fiscales).
Olas regionales: primero mercados «cálidos »/bajo tráfico, luego los principales; ventanas nocturnas de TZ locales.
Política de intersección: prohibición de cambios simultáneos en una ruta crítica (pagos, KYC, autorización).

4) Ramificación y versificación

Trunk-based + short-lived branches (características de la rama ≤ 3-5 días).
Release-ramal - sólo para trenes/verificaciones largas; duro back-merge en 'main'.
SemVer: `MAJOR. MINOR. PATCH 'para bibliotecas/SDK; etiquetas de artefactos y alrededores.
Contratos: esquemas (Avro/Protobuf) con compatibilidad back/forward; migraciones - bifásicas.

5) Canveers de calidad (gates)

1. Static + SAST/DAST + linters

2. Pruebas de Unidad/Contrato/Componente

3. E2E/Performance smoke (en el filete)

4. Controles de seguridad/cumplimiento (secretos, licencias, política de territorios)

5. Release Candidate → firma, SBOM, artefactos

6. Rollout progresivo con auto-gardrailes (ver § 7)

Todas las gaitas son código y política (Policy-as-Code), los resultados están en los artefactos de lanzamiento.

6) Miércoles y promotores

Dev → Int → Stage → Prod, para datos: Sandbox/Data-Stage.
Promociones de GitOps, imágenes immutables, prohibición de ediciones «manuales» en la venta.
Parametrización: regiones, límites, proveedores - a través de configuraciones (auditables).

7) Estrategias de laminación

Canary: 1%→5%→25%→100% (или per-region).
Azul-Verde: entornos paralelos + conmutación atómica.
Flags de función: encendedores funcionales/kill-switch; A/B и shadow.
Staged Rollout Mobile/Web: por versiones del cliente/canales de entrega (Store/OTA).

Gardrailes (auto stop): p95 latency ↑> 25%, error%> 2%, caída de autorizaciones/depósitos, crecimiento de charjbacks, burn-rate SLO por 1 hora ventana> umbral.

8) Alineación con empresas y socios

Marketing/Eventos: lanzamientos de funcionalidad a campañas con stock ≥ 48 h.
Partners (proveedores de PSP/KYC/Game): ranuras para certificaciones/actualizaciones SDK, endpoints dobles para el período de migración.
Soporte: macros/preguntas frecuentes sobre cambios de UX, páginas de estado, canales de escalamiento.

9) Actualizaciones de datos y esquemas

Additive first: primero añadir, luego cambiar de lectura/escritura, al final - quitar el antiguo.
Índices y grandes migraciones son las ventanas nocturnas, por batches, con cheques y progreso.
Versionar vitrinas y diccionarios de métricas: actualizaciones sincronizadas con la versión, migraciones de BI - separadas de las ventanas de distribución.

10) Comunicaciones y artefactos

Notas de release (qué/por qué/riesgos/rollback), ChangeLog por servicios.
Inventarios de calendario a stakeholders, plantillas de anuncios (antes/durante/después).
Canal de la sala de guerra para la hora de los trenes/grandes lanzamientos, frecuencia de los apdates: P1 - cada 15-20 min.

11) Métricas de eficacia

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate por tipo de cambio.
SLO Compliance% antes/después de los lanzamientos.
Release Debt: banderas «colgantes», migraciones inconclusas, viejas dependencias.
Business Impact: conversión, KYC TTV, éxito PSP, GGR/NGR drift en la ventana de lanzamiento.

12) Anti-patrones

Big-bang: «todo y a la vez» sin banderas/canarios.
Liberación en un pico de tráfico/eventos sin excepciones freeze.
Sin auto-gardrailes: monitoreo manual «en el ojo».
Ramas de larga vida: fusiones dolorosas y regresiones latentes.
Pasos manuales en la venta: no hay auditoría y previsibilidad.
Banderas sin TTL y propietarios: ramificaciones «eternas».

13) Hojas de cheques

Antes de la versión

• RFC/ticket, riesgo y blast-radius evaluados
• Getas CI/CD pasadas, artefactos firmados
• Plan de distribución + criterios de parada + backout listo
• Alineación con calendario, freeze y socios
• Los dashboards/alertas están enlazados a la versión, war-room creado

Durante la versión

• Los pasos canarios y la parada automática están activos
• Métricas p95/error%, señales de negocio (auth, KYC, PSP) en el monitor
• Comunicaciones programadas, la página de estado se actualiza

Después de la

• Notas de lanzamiento y ChangeLog publicadas
• Se eliminaron las banderas/excepciones temporales (TTL)
• Post mortem en las desviaciones ≤ 5 esclavos. días
• Se han actualizado los playbooks y la documentación

14) Mini plantillas

• Fecha/hora: W, 10: 00-12: 00 EET
• Distrito: EU (10%→50%→100%), seguido de LATAM (10%→100%)
• Criterios de parada: error%> 2% 10 min, p95> + 25% 10 min, éxito PSP <97%
• Backout: cambiar el tráfico a la versión anterior + reversión de banderas
• Contactos: @ RelEng, @ SRE-on-call, @ Support

• Qué es nuevo/Por qué
• Impacto en usuarios y socios
• Riesgos y limitaciones conocidas
• Plan de laminación/Criterios de parada/Backout
• Métricas para monitoreo
• Contactos y canales de soporte

15) Integraciones con disciplinas vecinas

Gestión de cambios: clasificación standard/normal/emergency, AMB, auditoría.
Reducción de las consecuencias de los incidentes: banderas de fichas listas, cuotas, shedding.
Auditoría de configuraciones: todas las promociones a través de Git, drift-detect y registro de aplicaciones.
Políticas de ejecución: límites/temporizadores/retraídos - como código, con coacción.

16) Resultado

Los ciclos de lanzamiento son un ritmo controlado entre velocidad y fiabilidad. Ranuras fijas donde se necesita coordinación; «bajo petición» donde la madurez de la automatización. En todas partes hay un solo calendario, banderas y escudos canarios, gardrailes automáticos y comunicaciones transparentes. Así es como los lanzamientos se vuelven predecibles, seguros y económicos.