GitLab CI/CD pour les projets iGaming

(Section : Technologie et infrastructure)

Résumé succinct

GitLab CI/CD est un « pipeline » de livraison pour les applications, les analyses et les services ML iGaming. Il regroupe : le référentiel, les pipelines en tant que code, la gestion de l'environnement et de la sécurité, le registre des conteneurs/paquets, les intégrations avec Kubernetes et Terraform, ainsi que l'analyse des vulnérabilités et des licences. La clé du succès est les mêmes modèles de piplines, les runners éphémères avec auto-skale, un modèle strict de droits et de secrets, les processus GitOps et le contrôle des coûts.

1) Architecture et rôles

GitLab (SaaS ou Self-Managed) : groupes/projets, Marques protégées/tags, Merge Request Approvals.
Runners: Docker/Kubernetes/Virtual Machine executors. Les pods éphémères en K8s minimisent la dérive du milieu.
Registres : Container/Package/Dependency Proxy : Cache les images de base et les dépendances.
Observability : job logs, job artifacts, pipeline insights, exportation de métriques vers la surveillance.

Rôles : Développeurs (MR), maintainers (approve/release), SecOps (politiques de numérisation), Platform/DevOps (runners, modèles, GitOps).

2) Bases '.gitlab-ci. yml' : étapes, règles, dépendances

yaml stages: [lint, test, build, security, package, deploy]

variables:
DOCKER_DRIVER: overlay2
IMAGE: "$CI_REGISTRY_IMAGE/app:$CI_COMMIT_SHA"

workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

.default:
image: alpine:3. 20 before_script: [ 'apk add --no-cache bash curl jq' ]

lint:
stage: lint script: [ "make lint" ]
rules: [ { if: '$CI_PIPELINE_SOURCE == "merge_request_event"' } ]

unit:
stage: test script: [ "make test" ]
artifacts:
when: always reports: { junit: "reports/junit. xml" }
needs: [ "lint" ]

build_image:
stage: build image: docker:27 services: [ 'docker:27-dind' ]
variables: { DOCKER_TLS_CERTDIR: "" }
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $IMAGE.
- docker push $IMAGE cache:
key: "docker-${CI_COMMIT_REF_SLUG}"
paths: [ "/var/lib/docker" ]
policy: pull-push needs: [ "unit" ]

• 'rules 'pour les branches/MR/tags ;' needs 'pour le parallélisme DAG ;' artifacts : reports 'pour JUnit/coverage ;' workflow '- pour ne pas déclencher de piplines superflues.

3) Runner et auto-skale

Kubernetes executor (recommandé)

Pods éphémères, quotas CPU/RAM, nodeSelector/taints, isolation des secrets.
Cache/artefacts : stockage d'objets ; dependency proxy для NPM/Maven/PyPI/Docker.

Docker executor

Démarrage simple ; Utilisez DinD ou Kaniko/BuildKit pour construire sans privilèges.

• Pools de runner distincts par type de charge (Build/Test/Security/ML) ; les limites de concurrence par groupe/projet ; tags de runner ('k8s', 'gpu', 'security').

4) Cache, artefacts et matrices

yaml cache:
key: "pip-${CI_COMMIT_REF_SLUG}"
paths: [ "venv/", ".cache/pip/" ]
policy: pull-push

test:py:
stage: test parallel:
matrix:
- PY: ["3. 10", "3. 12"]
image: python:${PY}
script:
- python -m venv venv &&. venv/bin/activate
- pip install -r requirements. txt
- pytest -q

Utilisez global dependency proxy pour économiser du trafic et du temps, split-tests par matrice, artifacts:expire_in pour l'hygiène.

5) Sécurité et conformité (Shift-Left)

yaml sast:
stage: security image: registry. gitlab. com/security-products/sast:latest script: [ "analyzer run" ]
artifacts: { reports: { sast: "gl-sast-report. json" } }
rules: [ { if: '$CI_PIPELINE_SOURCE == "merge_request_event"' } ]

secret_detection:
stage: security image: registry. gitlab. com/security-products/secret-detection:latest script: [ "analyzer run" ]
artifacts: { reports: { secret_detection: "gl-secret-report. json" } }

sbom:
stage: security image: alpine:3. 20 script:
- apk add syft cosign
- syft $IMAGE -o cyclonedx-json > sbom. json
- cosign sign --key $COSIGN_KEY $IMAGE artifacts:
reports: { cyclonedx: "sbom. json" }

Aussi : DAST pour les stands, Dependency/License Compliance, obligatoire MR-approvals pour les findings critiques, masquage des variables.

6) Environnement, Review Apps et versions

yaml review:
stage: deploy image: bitnami/kubectl environment:
name: review/$CI_COMMIT_REF_SLUG url: https://$CI_COMMIT_REF_SLUG. apps. example. com on_stop: stop_review script:
-./deploy. sh --env=review --image=$IMAGE rules: [ { if: '$CI_PIPELINE_SOURCE == "merge_request_event"' } ]

stop_review:
stage: deploy when: manual environment:
name: review/$CI_COMMIT_REF_SLUG action: stop script: [ "./deploy. sh --env=review --delete" ]

Release/Tag Pipline : publication de cartes/artefacts Helm, génération de notes de sortie, signature d'images.

7) Progressive delivery: canary/blue-green

yaml deploy_canary:
stage: deploy script: [ "./helm_upgrade. sh --set canary. weight=10 --image=$IMAGE" ]
environment: { name: production }
rules: [ { if: '$CI_COMMIT_TAG' } ]

promote_100:
stage: deploy when: manual script: [ "./helm_upgrade. sh --set canary. weight=100" ]
needs: [ "deploy_canary" ]

Ajoutez quality gates : SLO latency/error-rate à partir de la surveillance → résolution/retour.

8) Parents/Enfants et pipelines multiprojets

Parent/Enfant : accélèrent les grands monorepos (chaque composant est une pipeline enfant).

yaml trigger_components:
stage: build trigger:
include: [ "ci/component-a. yml", "ci/component-b. yml" ]
strategy: depend

Multi-Project : « Release » projet triggerit le CD dans un manifeste-repo (GitOps).

9) GitOps и Terraform/IaC

GitOps via MR dans un référentiel manifeste

yaml gitops_bump:
stage: deploy image: alpine/git script:
- git clone $MANIFESTS_REPO manifests
- yq -i '.image = env(IMAGE)' manifests/apps/app/values. yaml
- cd manifests && git commit -am "bump $CI_COMMIT_SHA" && git push origin HEAD:$TARGET_BRANCH

Terraform в CI

yaml terraform:
stage: deploy image: hashicorp/terraform:1. 9 script:
- terraform init -backend-config="bucket=$TF_BUCKET"
- terraform plan -out tfplan
- terraform apply -auto-approve tfplan rules: [ { if: '$CI_COMMIT_BRANCH == "infra"'} ]

10) Secrets et accès

CI Variables: masked/protected; divisez par environnement/groupe.
Marques protégées/tags : Dépopulation dans prod - uniquement à partir de branches protégées et avec confirmation manuelle.
Secrets externes : intégrations avec Secret Manager/HashiCorp Vault (JWT/OIDC), montage sur les runners uniquement pendant le job.

11) Observation des pipelines et SLO

Pipeline DORA/KPI: lead time, deployment frequency, change fail rate, MTTR.
Outils : Retrai/Timauts, 'allow _ failure' pour les tâches non bloquantes, rapport de couverture de code.
Exportation de métriques : durée des étapes, file d'attente des runners, ratio success ; alertes dans ChatOps.

12) FinOps : coût et performance

Dependency Proxy + cache de dépendances et de couches Docker.
Séparation des pools de runner (prod/security/ML) avec des limites de concurrence.
Auto-pause Review Apps et les environnements inactifs ; 'artifacts : expire _ in'.
Grands assemblages - sur pools spot/préemptables ; Avant de chauffer les images de base.

13) Modèles pour iGaming Case

Service backend/API

yaml include: [ "ci/includes/security. yml", "ci/includes/docker. yml" ]
deploy_prod:
stage: deploy environment: { name: production, url: https://api. example. com }
script: [ "./helm_upgrade. sh --env=prod --image=$IMAGE" ]
rules: [ { if: '$CI_COMMIT_TAG' } ]

modèle ETL/DBT

yaml dbt_run:
stage: build image: ghcr. io/dbt-labs/dbt-snowflake:latest script: [ "dbt deps", "dbt run --profiles-dir. ", "dbt test" ]
artifacts: { paths: [ "target/" ], expire_in: 3 days }

artefact ML/LLM

yaml ml_pack:
stage: package image: nvidia/cuda:12. 1. 0-runtime-ubuntu22. 04 tags: [ "gpu" ]
script:
- python export_onnx. py
- trtexec --onnx=model. onnx --saveEngine=model. plan artifacts: { paths: [ "model. plan", "model. onnx" ] }

14) Chèque de mise en œuvre

1. Définissez les modèles de pipes et les inclusions partagées pour les commandes (lint/test/build/security/deploy).
2. Déployez les runners K8s éphémères, activez dependency proxy, le stockage d'objets pour les artefacts/cache.
3. Entrez rules/needs/DAG, matrices et parallélisme.
4. Configurez SAST/DAST/Secret/SBOM/License et MR-approvals par politique.
5. Organiser Environments/Review Apps, autoproduction et URL soignées.
6. Incluez GitOps : un manifeste-repo distinct, un bamp MR d'images/charts.
7. Assurez la gestion des secrets (masked/protected, Vault/OIDC), les marques protégées/tags.
8. Connectez Terraform/IaC et « surveillance en tant que code ».
9. Entrez les pratiques FinOps : limites de runner, cache/proxy, expire artefacts, autopause des stands.
10. Jour-jeu régulier : chute du lanceur, remplissage du cache, indisponibilité du registre.

15) Anti-modèles

Un runner « universel » sans isolement ni quotas.
Piplines sans 'rules' (démarre « toujours »), sans 'needs' (lent).
Assemblages DinD privilégiés dans les runners sans restrictions.
Stocker des secrets dans le référentiel/dans les logs job.
Pas d'étape de sécurité et MR-approvals.
Infinies Review Apps sans 'on _ stop' et 'expire _ in'.
Versions manuelles en prod sans tags protégés.

Résultats

GitLab CI/CD donne aux équipes iGaming des versions rapides et prévisibles : modèles uniques, runner auto-skale, gets de sécurité de qualité, environnements et deploi progressif, GitOps et intégration Terraform. Ajoutez l'observabilité et les FinOps - et vos applications, services ETL et ML seront publiés régulièrement, en toute sécurité et à un coût contrôlé.