GH GambleHub

Prácticas de DevOps y CI/CD

1) Objetivos y principios

Rápido y seguro: ciclos cortos, pequeños lotes de cambios, comprobaciones automáticas.
Repetibilidad: infraestructura como código (IaC), entorno = código + política.
Observabilidad: métricas/tracks/logs fuera de caja, SLO como contrato.
Cumplimiento: auditoría, control de cambios, aislamiento regional de datos.

Regla de oro: «Primero la calidad, luego la velocidad - de lo contrario la velocidad nunca aparecerá».

2) Ramificaciones y alrededores

Trunk-based + feature flags es una opción básica.

Cortas ramas de fiche (≤ 2-5 días), merge diario en trunk.
Indicadores (lado del servidor) para envíos incrementales y revisiones seguras.
Entorno git: 'dev' → 'stage' → 'prod' (+ regional' prod-eu ',' prod-latam ').
Promoción de artefactos: una imagen recogida se promociona a través de los ambientes (tag immutable by digest).

Cuando GitFlow: lanzamientos raros de ensambles regulatorios/SDK - entonces liberación-rama + «hardening».

3) Pirámide de calidad y «línea roja»

1. Análisis estático (SAST, linters, licencias).
2. Pruebas Unit/Property-based (segundos).
3. Pruebas de contrato (CDC) para API y eventos (OpenAPI/AsyncAPI, Registro de Schema).
4. Integración (Testcontainers, corredores locales).
5. E2E maneras críticas: registro de → KYC → depósito → lanzamiento del juego → retiro.
6. Pruebas de carga/caos para pagos/billetera/proveedores de juegos.

La calidad no pasa → la deba está bloqueada. No hay «excepciones manuales» sin change-record.

4) Cadena de suministro de software (cadena de suministro)

SBOM para cada imagen/paquete (CycloneDX/SPDX).
Firmas de artefactos (cosign), política «sólo firmada» en admission.
SCA/Dependabot: vulnerabilidades y licencias.
Provenance/SLSA: conjuntos reproducibles, agente de código cerrado, attestations.
Secretos: en el gestor (KMS/Secrets Exteriores), ningún secreto en los repos/logs.

5) GitOps и IaC

Infra as Code: Terraform/Pulumi para la nube; Helm/Kustomize para k8s.
Controlador GitOps (ArgoCD/Flux): manifiestos declarativos, rugido PR, audit trail.
Ventanas/heladas: semanas de torneo/horas punta - auto-pausa de lanzamientos prod.
OPA/Kyverno: no ': latest', no root, read-only FS, prohibición de hostPath.

6) Envío progresivo

Canario: 1→5→10→25→50→100% por métricas guardrail (p95 latency, 5xx, error budget burn).
Azul-Verde: interruptor rápido + plan de retroceso.
Shadow/Mirroring: copiar solicitudes sin afectar la respuesta (para nuevos adaptadores PSP).
Flags de función: activación por segmento (región/rol/socio/canal) + kill-switch.

7) Migración de la DB (expand-and-contract)

Paso 1: ampliar el esquema (nuevas columnas/índices) - compatible con el código antiguo.
Paso 2: Un deplom de código que escribe en ambas versiones/campos.
Paso 3: migración de datos con joba de fondo, métricas de progreso.
Paso 4: Cambiar la lectura a nuevos campos.
Paso 5: eliminar el antiguo - versión separada.
Prohibición de bloquear DDL en prime time; para tablas altas - migración en línea.

8) Observabilidad y SLO

Métricas: RPS, p50/95/99, 4xx/5xx, saturation (CPU/nat/queue), DLQ/cortesía de corredores.
Métricas de negocio: TTP (time-to-play), TtW (time-to-wallet), FTD-success, KYC-TtV.
Tracks: trace-id desde la puerta de enlace hasta la base de datos.
SLO: por ejemplo, 'Depósito p95 ≤ 300-500 ms', 'éxito ≥ 98. 5%`, `availability ≥ 99. 9%`.
Burn rate alertas + auto-pausa lanzamientos cuando se degradan.

9) Incidentes, post mortem, turnos

Runbooks en los flujos críticos (depósito/retiro/CUS, juegos en vivo).
Escala de prioridad: P1...P4, propietario, ETA, comunicación (pancarta, status page, socios).
Blameless post mortem con action items y fechas.
Alternaciones on-call, alertas de chat, actualizaciones de estado cada N minutos.
Dock-trace: quién/cuándo/qué puso (commit, artefacto, miércoles, bandera).

10) Seguridad y cumplimiento (DevSecOps)

SAST/DAST/IAST, secreto-escaneado en CI.
mTLS servis↔servis, JWT con TTL pequeño, rotación de claves.
Masking PII/PAN en los logotipos/trays; Registros WORM de acciones administrativas.
Geo-segregación: clústeres/DB por región, enrutamiento a través de gateway.
Gestión de cambios: ticket/approval para zonas sensibles (monedero/límites).

11) DORA-métricas y FinOps

Deployment Frequency (lanzamientos pequeños diarios).
Lead Time for Changes (ideal: reloj).
MTTR (recuperación: minutos/horas).
Change Failure Rate (objetivo ≤ 15%).
FinOps: costo de los alrededores, almacenamiento en caché RPS, pools cálidos, workers de pausa automática, «costa per transaction».

12) iGaming-especificidad

Picos (torneos/live): congelación de grandes cambios, calentamiento de caché/imágenes, aumentos de cuotas.
Pagos/billetera: grupos/nodos individuales, SLO mejorado, rollout canario por región, doble telemetría de proveedores PSP.
CUS/cumplimiento: cadencia de lanzamientos separados, postapruvas de cumplimiento obligatorios.
Socios/afiliados: SDK seguros, versión API con ventana de soporte y monitoreo de clientes antiguos.

13) Ejemplo CI/CD (YAML, GitHub Actions → ArgoCD)

yaml name: ci-cd on:
push:
branches: [ main ]
paths: [ "services/wallet/" ]
jobs:
build_test_scan:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- name: Setup Node uses: actions/setup-node@v4 with: { node-version: 22 }
- run: npm ci --omit=dev working-directory: services/wallet
- run: npm test -- --ci working-directory: services/wallet
- name: Lint & SAST run: npm run lint && npm run sast working-directory: services/wallet
- name: Build image run:
docker build -t registry. local/wallet:${{ github. sha }} -f Dockerfile.
cosign sign --key $COSIGN_KEY registry. local/wallet:${{ github. sha }}
- name: SBOM & Scan run:
syft packages registry. local/wallet:${{ github. sha }} -o cyclonedx-json > sbom. json trivy image --exit-code 1 --severity HIGH,CRITICAL registry. local/wallet:${{ github. sha }}
- name: Push image run: docker push registry. local/wallet:${{ github. sha }}

deploy_stage:
needs: build_test_scan runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- name: Bump Helm values (image tag)
run: yq -i '.image. tag = "${{ github. sha }}"' helm/wallet/values-stage. yaml
- name: Create PR to gitops repo run: gh pr create -R org/gitops -B stage -H stage-bump/wallet-${{ github. sha }} -t "wallet:${{ github. sha }}" -b "Promote to stage"

promote_prod:
if: github. ref == 'refs/heads/main'
needs: deploy_stage runs-on: ubuntu-latest steps:
- name: Gate: SLO/quality checks run:./scripts/gates/check_stage_health. sh # p95, 5xx, e2e ok
- name: Canary 10%
run:./scripts/gitops/canary. sh wallet ${{ github. sha }} 10
- name: Auto-pause on degradation run:./scripts/gates/guardrails. sh./scripts/gitops/rollback. sh wallet
- name: Roll to 100%
run:./scripts/gitops/rollout. sh wallet ${{ github. sha }} 100
💡 Idea: recogemos y firmamos la única imagen, publicamos SBOM, promovemos a través de GitOps; el Prod Rollaut es canario, con guardrails.

14) Hojas de cheques

Antes de merge en main

  • Unidad/CDC/integración verde.
  • Linters/SAST/licencias limpias.
  • Se han actualizado los esquemas OpenAPI/AsyncAPI y las migraciones de BD.
  • Se agregan banderas de fiche, se definen los follbecs.

Antes de la versión prod

  • Imagen firmada, SBOM aplicada, vulnerabilidades HIGH/CRIT cerradas.
  • Se han creado dashboards/alertas; Las puertas SLO están conectadas.
  • Plan de retroceso, kill-switch, Shadow (si es necesario).
  • Se confirman las restricciones regionales y las políticas de datos.
  • Runbook encontrado y actualizado.
  • Comunicación a usuarios/socios (plantilla, ETA).
  • Postmortem a las 48 horas, action items con fechas.

15) Anti-patrones

«Recolectamos de nuevo para cada medio» (no hay promoción del artefacto).
Pasos manuales sin auditoría/repetibilidad.
Migraciones de DAB «de frente», respuestas de API incompatibles.
Secretos en las variables CI o en el repositorio.
Fiches catastróficos sin bandera/retroceso.
Ausencia de SLO/guardrails en el lanzamiento canario.
Registros con PII/PAN, sin enmascaramiento.

16) Patrones de microcopia útiles

Lanzamiento (partners):
  • "Lanzamos la actualización del módulo de pago por etapas (10%→100%). Es posible retrasos breves en la inscripción de hasta 2 minutos. ETA de finalización - 21:00 EET"
Incidente (banner en el producto):
  • "El proveedor de pago X no es apto. La inscripción puede tardar hasta 15 minutos. Estamos trabajando en una corrección. La próxima actualización de estado es en 30 minutos"
Reversión:
  • "La actualización se ha suspendido debido al aumento de los retrasos. Devolvemos la versión anterior. Se han guardado los datos y las operaciones"

17) Proceso de implementación (4 sprints)

1. Estándares de calidad y pipeline: SAST/Unit/CDC, imagen única, firmas, SBOM.
2. GitOps + entorno: Helm/Kustomize, ArgoCD, promoción del artefacto, política de secretos.
3. Lanzamientos progresivos y SLO-gates: canary/shadow, guardrails, auto-pausa.
4. Fiabilidad y costo: pruebas de caos, pools de skale/calientes, dashboards de FinOps.

Parche final

Trunk + flags + lotes pequeños = velocidad sin estrés.
Artefacto único firmado + SBOM = cadena de suministro controlada.
GitOps + directivas = reproducibilidad y auditoría.
Canary/Blue-Green + SLO-Gates = lanzamientos seguros.
Expand-and-contract para BD = tiempo de inactividad cero.
Observabilidad y DORA = mejoras gestionadas.
Aislamiento regional y cumplimiento = cumplimiento de las leyes y confianza.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.