GitLab CI/CD per i progetti iGaming

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

CI/CD è una «catena di montaggio» per applicazioni, analisti e servizi ML. Combina repository, pipline come codice, gestione degli ambienti e della sicurezza, registro dei contenitori/pacchetti personalizzati, integrazione con Kubernets e Terraform e scansione delle vulnerabilità e delle licenze. La chiave del successo sono gli stessi modelli di pipline, runner effimeri con skale auto, un modello rigoroso di diritti e segreti, processi GitOps e controllo dei costi.

1) Architettura e ruoli

GitLab (SaaS o Self-Managed): gruppi/progetti, Protected branches/tags, Merge Sollest Approvals.
Runners: Docker/Kubernetes/Virtual Machine executors. I sottostanti effimeri di K8s minimizzano la deriva dell'ambiente.
Maiuscole: Container/Package/Dipendency Proxy - Memorizza immagini e dipendenze di base nella cache.
Osservabilità: job logs, job artistacts, pipeline insights, esportazione di metriche nel monitoraggio.

Ruoli: sviluppatori (MR), maintainers (approve/release), SecOps (criteri di scansione), Platform/DevOps (runner, modelli, GitOps).

2) Basi '.gitlab-ci. yml ': fasi, regole, dipendenze

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'per rami/MR/tag;' needs'per parallelismo DAG; 'artifact'per JUnit/coverage;' workflow 'per non eseguire pipline in eccesso.

3) Runner e auto-scale

Kubernets executor (raccomandato)

Sottofondo effimero, quote CPU/RAM, nodeSelector/taints, isolamento dei segreti.
Cache/artefatti - Archivio oggetti dependency proxy для NPM/Maven/PyPI/Docker.

Docker executor

Una partenza semplice; Utilizzare un DinD o un Kaniko/BuildKit per assemblare senza privilegi.

• Singoli pool di runner per tipo di carico (Build/Test/Security/ML); limiti di concurrency per gruppo/progetto; tag runner («k8s», «gpu», «security»).

4) Cache, manufatti e matrici

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

Usi le dipendency proxy globali per risparmiare traffico e tempo, split-test per matrice, artifacts: expire _ in per l'igiene.

5) Protezione e 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" }

Inoltre: DAST per gli stand, Dipendency/License Compliance, Mr. approvals obbligatori per findings critici, occultamento delle variabili.

6) Ambienti, Review Apps e release

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 - Pubblicazione di una lista Helm/artefatti, generazione di note di uscita, firma di immagini.

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" ]

Aggiungi quality gates: SLO latency/error-rate dal monitoraggio di risoluzione/ripristino.

8) Parent/Child e pipline multi-progetto

Parent/Child: accelerano i grandi monorepi (ogni componente è child pipeline).

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

Multi-Project: «Release» progetto triguerà il CD in un manifesto repo (GitOps).

9) GitOps и Terraform/IaC

GitOps MR in un repository manifesto

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) Segreti e accessibilità

CI Variables: masked/protected; dividere per ambienti/gruppi.
Protected branches/tags - deposito in prod - solo da rami protetti e con conferma manuale.
Segreti esterni: integrazione con Secret Manager/HashiCorp Vault (JWT/OIDC), montaggio su runner solo per job.

11) Osservabilità pipline e SLO

Pipeline DORA/KPI: lead time, deployment frequency, change fail rate, MTTR.
Strumenti: retrai/timeout, 'allow _ failure'per attività non bloccanti, rapporto copertura codice.
Esportazione delle metriche: durata degli stadi, coda dei runner, success ratio; Gli alert nel ChatOps.

12) FinOps: costo e prestazioni

Dipendency Proxy + cache delle dipendenze e dei livelli Docker.
Separare i pool runner (prod/security/ML) dai limiti concurrency.
Interruzione automatica di Review Apps e degli ambienti inattivi; 'artifacts: expire _ in'.
Assemblaggi di grandi dimensioni su pool spot/premtabel; prima del riscaldamento delle immagini di base.

13) Modelli per valigette iGaming

Servizio 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' } ]

Modello 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 }

ML/LLM artefatto

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) Assegno foglio di implementazione

1. Definire i modelli di pipline e Shared Includi per i comandi (lint/test/build/security/deploy).
2. Espandere i runner K8s effimeri, attivare le dipendency proxy, lo storage degli oggetti per gli artefatti/cache.
3. Inserisci rule/needs/DAG, matrici e parallelismo.
4. Configura SAST/DAST/Secret/SBOM/License e MR-approvals per criteri.
5. Organizzate Environments/Review Apps, la protezione automatica e gli URL accurati.
6. Attivare il GitOps: manifesto-repo separato, MR-bump di immagini/scalette.
7. Assicurati di gestire i segreti (masked/protected, Vault/OIDC), protected branches/tags.
8. Collegare il Terraform/IaC e il «monitoraggio come codice».
9. Immettere la pratica FinOps: limiti runner, cache/proxy, espire artefatti, automatica stand.
10. Game-day regolari: caduta del runner, riempimento della cache, inattività del Registro di sistema.

15) Antipattern

Un runner «universale» senza isolamento e senza quote.
Pipline senza «rules» («sempre»), senza «needs» (lento).
Gli assiemi privilegiati vengono DinD in prod runner senza vincoli.
Memorizza i segreti nel repository/nelle unità job.
Nessuna fase di sicurezza e MR-approvals.
Infinite Review Apps senza «on _ stop» e «expire _ in».
Rilasci manuali in prod senza protected tags.

Riepilogo

Il CI/CD fornisce ai team iGaming una release rapida e prevedibile: modelli unificati, scale auto, gate di sicurezza di qualità, ambienti e deploy progressivi, e . Aggiungi osservabilità e FinOps - e le applicazioni, ETL e servizi ML saranno disponibili regolarmente, in sicurezza e con un costo controllato.