GH GambleHub

DevOps et CI/CD

1) Objectifs et principes

Rapide et sûr : cycles courts, petits lots de changements, contrôles automatiques.
Répétabilité : infrastructure en tant que code (IaC), environnement = code + politique.
Observabilité : métriques/trajets/logs de la boîte, SLO comme contrat.
Conformité : audit, contrôle du changement, isolement régional des données.

La règle d'or est : « D'abord la qualité, puis la vitesse - sinon la vitesse n'apparaîtra jamais ».

2) Branches et environnements

Trunk-based + feature flags est le choix de base.

Branches de fiche courtes (≤ 2-5 jours), merge quotidien en trunk.
Indicateurs (server-side) pour la livraison incrémentale et les retours sécurisés.
Environnement git : 'dev' → 'stage' → 'prod' (+ régional 'prod-eu', 'prod-latam').
Promotion d'artefacts : une image collectée avance à travers les environnements (tag immuable by digest).

Quand GitFlow : les versions rares des assemblages réglementaires/SDK sont alors la version + « hardening ».

3) Pyramide de qualité et « ligne rouge »

1. Analyse statique (SAST, linters, licences).
2. Tests basés sur l'unité/la propriété (secondes).
3. Contrats-tests (CDC) pour les API et les événements (OpenAPI/AsyncAPI, Schema Registry).
4. Intégration (Testcontainers, courtiers locaux).
5. E2E des chemins critiques : s'inscrire → KYC → déposer → lancer le jeu → retirer.
6. Tests de charge/chaos pour les paiements/portefeuille/fournisseurs de jeux.

La qualité ne passe pas → bloquée. Il n'y a pas d'exceptions manuelles sans changement de dossier.

4) Chaîne d'approvisionnement en logiciels (chaîne d'approvisionnement)

SBOM pour chaque image/paquet (CycloneDX/SPDX).
Signatures d'artefacts (cosign), stratégie « uniquement signée » dans l'admission.
SCA/Dependabot : vulnérabilités et licences.
Provénance/SLSA : assemblages reproductibles, agent de facturation fermé, attestations.
Secrets : dans le gestionnaire (KMS/External Secrets), pas un seul secret dans les revues/logs.

5) GitOps и IaC

Infra as Code : Terraform/Pulumi pour le nuage ; Helm/Kustomize pour k8s.
Contrôleur GitOps (ArgoCD/Flux) : manifestes déclaratifs, PR-revue, piste d'audit.
Fenêtres/gelées : semaines de tournoi/heures de pointe - auto-pause des sorties.
OPA/Kyverno politiques : no ': latest', non-root, read-only FS, interdiction hostPath.

6) Livraison progressive

Canary : 1→5→10→25→50→100 % selon les métriques guardrail (p95 latency, 5xx, error budget burn).
Bleu-Vert : commutateur rapide + plan de retour.
Shadow/Mirroring : copie des requêtes sans impact sur la réponse (pour les nouveaux adaptateurs PSP).
Feature flags : inclusion par segment (région/rôle/partenaire/canal) + kill-switch.

7) Migrations OBD (expand-and-contract)

Étape 1 : nous étendons le schéma (nouvelles colonnes/index) - compatible avec l'ancien code.
Etape 2 : Un code qui s'écrit dans les deux versions/champs.
Étape 3 : Migration des données par job d'arrière-plan, métriques de progrès.
Étape 4 : bascule la lecture vers de nouveaux champs.
Étape 5 : Supprimer l'ancien est une version distincte.
Interdire les DDL de blocage en temps de pointe ; pour les tables hautes - migration en ligne.

8) Observabilité et SLO

Métriques : RPS, p50/95/99, 4xx/5xx, saturation (CPU/mem/queue), DLQ/lag des courtiers.
Mesures commerciales : TTP (time-to-play), TtW (time-to-wallet), FTD-success, KYC-TtV.
Traces : trace-id de la passerelle à l'OBD.
SLO : par exemple, 'Deposit p95 ≤ 300-500 ms', 'success ≥ 98. 5%`, `availability ≥ 99. 9%`.
Burn rate alert + auto-pause de sortie en cas de dégradation.

9) Incidents, postmortems, changements

Runbooks sur les flux critiques (dépôt/retrait/CUS, jeux en direct).
Échelle de priorité : P1...P4, propriétaire, ETA, communication (bannière, page de statut, partenaires).
Blameless post mortem avec des items d'action et des dates.
Alternance d'appels, d'alertes de chat, de mises à jour de statut toutes les N minutes.
Piste de quai : qui/quand/ce qu'il a posté (commit, artefact, mercredi, drapeau).

10) Sécurité et conformité (DevSecOps)

SAST/DAST/IAST, scan secret en CI.
mTLS servis↔servis, JWT avec petit TTL, rotation des clés.
Masking PII/PAN dans les logs/remorques ; Journaux WORM des actions admin.
Géo-segmentation : clusters/OBD par région, routage par passerelle.
Gestion du changement : ticket/approval pour les zones sensibles (portefeuille/limites).

11) métriques DORA et FinOps

Deployment Frequency (petites versions quotidiennes).
Lead Time for Changes (idéal : horloge).
MTTR (récupération : minutes/heures).
Taux d'échec du changement (objectif ≤ 15 %).
FinOps : coût des environnements, mise en cache RPS, pools chauds, workers auto-pause, « cost per transaction ».

12) iGaming-spécificité

Pics (tournois/vie) : gel des changements majeurs, échauffement du cache/images, boost des quotas.
Paiements/portefeuille : pools/nœuds séparés, SLO élevé, rollout canarien par région, double télémétrie des fournisseurs PSP.
CUS/conformité : une cadence séparée des versions, des aprouves de conformité obligatoires.
Partenaires/affiliations : SDK sécurisé, version API avec fenêtre de support et surveillance des anciens clients.

13) Exemple 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
💡 Idée : nous collectons et signons une seule image, publions le SBOM, faisons la promotion via GitOps ; le prod-rollout est canarien, avec les guardrails.

14) Chèques-feuilles

Avant merge en main

  • Unité/CDC/intégration verte.
  • Les linters/SAST/licences sont propres.
  • Les schémas OpenAPI/AsyncAPI et migration OBD ont été mis à jour.
  • Les drapeaux Fiche ont été ajoutés, les follbacks sont définis.

Avant la sortie dans prod

  • L'image est signée, le SBOM est joint, les vulnérabilités HIGH/CRIT sont fermées.
  • Les dashboards/alertes sont créés ; Les gates SLO sont connectées.
  • Plan de retour, kill-switch, Shadow (si nécessaire).
  • Les limites régionales et les politiques en matière de données ont été confirmées.

Incidents

  • Runbook trouvé et pertinent.
  • Communication aux utilisateurs/partenaires (modèle, ETA).
  • Post mortem à 48 heures, items d'action avec dates.

15) Anti-modèles

« Assemblons à nouveau pour chaque environnement » (pas d'artefact promotionnel).
Étapes manuelles sans audit/répétabilité.
Migration « front-to-front » des bases de données, réponses API incompatibles.
Secrets dans les variables CI ou dans le référentiel.
Fiches catastrophiques sans drapeau.
Absence de SLO/guardrails dans la version canarienne.
Logs avec PII/PAN, pas de masquage.

16) Modèles utiles de microcopy

Sortie (s) :
  • Nous effectuons une mise à jour progressive du module de paiement (10%→100 %). Des délais d'inscription de courte durée jusqu'à 2 minutes sont possibles. ETA terminé - 21h00 EET "
Incident (bannière dans le produit) :
  • "Le fournisseur de paiement X est instable. L'inscription peut prendre jusqu'à 15 minutes. Nous travaillons sur la correction. La prochaine mise à jour du statut est dans 30 minutes"
Retour en arrière :
  • "La mise à jour a été suspendue en raison de retards croissants. Nous retournons la version précédente. Les données et les opérations sont enregistrées"

17) Processus de mise en œuvre (4 sprints)

1. Normes de qualité et pipline : SAST/Unit/CDC, image unique, signatures, SBOM.
2. GitOps + environnement : Helm/Kustomize, ArgoCD, promotion d'artefact, politique des secrets.
3. Sorties progressives et SLO-gates : canary/shadow, guardrails, autoause.
4. Fiabilité et coût : tests de chaos, auto-skale/pools chauds, FinOps-dashboards.

La trappe finale

Trunk + flags + petits lots = vitesse sans stress.
Artefact signé unique + SBOM = chaîne d'approvisionnement contrôlée.
GitOps + politiques = reproductibilité et audit.
Canary/Blue-Green + SLO-gates = versions sécurisées.
Expand-and-contract pour la base de données = zéro interruption.
Observabilité et DORA = améliorations gérables.
Isolement régional et conformité = conformité aux lois et confiance.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.