GitHub Actions : Automatisation des sorties

(Section : Technologie et infrastructure)

Résumé succinct

GitHub Actions est un « pipeline comme code » natif dans le référentiel. Pour iGaming, il s'agit de versions rapides et sécurisées des services backends, front-end, ETL/DBT et ML/LLM : matrices de test, cache de dépendance, pools runner isolés, Reusable Workflows pour des standards unifiés, OIDC au lieu de secrets à longue durée de vie, signature et SUD BOM, les versions tags et les pare-chocs GitOps des manifestes. La clé est les modèles et les jeux de qualité/sécurité pour garder p99 et le coût sous contrôle.

1) Principes architecturaux

Piplines en tant que code ('.github/workflows/.yml'), DRY via Reusable/Composite Actions.
Runner pools : hosted (ubuntu-latest) + self-hosted (K8s/VM, GPU pour ML).
Environnements (Environments) : 'dev/stage/prod'avec des réviseurs required, des taimauts et des secrets par environnement.
Politiques : marques protégées/tags, CODEOWNERS, vérifications obligatoires.
Observabilité : job summaries, artefacts, loging, métriques de durée.

2) Modèle de base CI → CD (backend)

yaml name: ci-cd-backend on:
pull_request:
branches: [ main ]
push:
tags: [ "v" ]
permissions:
contents: read id-token: write    # для OIDC packages: write

env:
IMAGE: ghcr. io/${{ github. repository }}/api:${{ github. sha }}

jobs:
lint_test:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5 with: { python-version: '3. 12' }
- name: Cache pip uses: actions/cache@v4 with:
path: ~/.cache/pip key: pip-${{ runner. os }}-${{ hashFiles('requirements. txt') }}
- run: pip install -r requirements. txt
- run: make lint && make test
- name: Build & push image (BuildKit)
uses: docker/build-push-action@v6 with:
push: ${{ github. event_name == 'push' }}
tags: ${{ env. IMAGE }}
cache-from: type=gha cache-to: type=gha,mode=max

security:
needs: [ lint_test ]
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- name: SCA/SAST/Secrets uses: your-org/security-composite@v3  # Composite Action вашей орг.

release_prod:
if: startsWith(github. ref, 'refs/tags/v')
needs: [ security ]
runs-on: ubuntu-latest environment: production steps:
- uses: actions/checkout@v4
- name: SBOM & Sign uses: your-org/sbom-sign-action@v2 with:
image: ${{ env. IMAGE }}
- name: GitOps bump manifests uses: your-org/gitops-bump@v2 with:
image: ${{ env. IMAGE }}
path: apps/api/values. yaml

Idée : PR → lint/units → sécurité → par tag'v "- SBOM/signature et GitOps-bump manifestes pour le dépliant.

3) Réutilisation : Reusable/Composite

Reusable Workflows : modèles de pipeline uniques pour tous les services (dans un repo distinct de '.github').
Actions Composite : Scrabble des pas répétés (lint/units/scans).

yaml jobs:
ci_template:
uses: your-org/ci-templates/.github/workflows/python. yml@v3 with:
python: '3. 12'
run-tests: true

4) Matrices, cache et performances

`strategy. matrix 'pour les tests parallèles (langages/OBD/OS).
Cache : 'actions/cache' pour les dépendances ; BuildKit с `cache-to: gha`; dependency proxies.
Compétitivité : 'concurrency : group : api- $ {{github. ref}}, cancel-in-progress : true '- permet d'économiser des minutes.
Artefacts : stocker les rapports/couvertures/profils avec 'retentation-days'.

yaml strategy:
matrix:
py: [ '3. 10', '3. 12' ]
db: [ 'mysql', 'postgres' ]

5) Environments и approvals

Configurez les réviseurs required pour 'production' (gate manuelle).
Les secrets de l'environnement : jetons déployés, clés de signature, URL des stands.
Durée de vie des environnements prévisualisés (auto-expire) pour contrôler les coûts.

6) Accès OIDC aux nuages (pas de secrets de longue durée)

Activez 'id-token : write', configurez la politique de confiance dans le nuage et utilisez des credenshls temporaires.
Applicable pour AWS/Azure/GCP/artefact-registry/secret-manager.
Principe de least privilège : rôles distincts sur "dev/stage/prod'.

yaml
- name: Assume cloud role via OIDC uses: your-org/oidc-assume@v1 with:
role: arn:aws:iam::123:role/gha-deploy-prod

7) Releases, tags et artefacts

Release par tag : changelog, release-assets, publication d'images/paquets.
Immutabilité : tags « en avant seulement », signature des conteneurs/charts.
SBOM (CycloneDX/SPDX) + signature (cosign/sigstore) - gate « sans signature - pas de déchet ».

8) GitOps и progressive delivery

Le CD n'est pas « des Actions », mais via PR/commit dans le manifeste-repo (Argo CD/Flux).
Canary/blue-green : étapes GitOps-bump poids/version ; auto-promotion sur les métriques SLO.

yaml
- uses: mikefarah/yq@v4 with:
cmd: yq -i '.image = strenv(IMAGE)' apps/api/values. yaml
- run:
git config user. name "gha-bot"
git commit -am "bump api -> $IMAGE" && git push

9) Sécurité Pipline et chaînes d'approvisionnement

Qui peut exécuter : seulement à partir des marques protégées/tags, avec required checks.
Scan : SAST/SCA/Secret-scan, DAST sur les environnements de prévisualisation.
Signatures : images, cartes Helm, binaires ; vérification à la dérive.
Politiciens : Les dispatches ne sont que des workflow de confiance ; pin SHA pour les actions tierces.

10) Observabilité, SLO et ChatOps

Rapports sommaires (JUnit/coverage/scans), statuts en PR.
Métriques : durée des étapes, succès/feels, « file de runner ».
ChatOps : commentaires du bot en PR (liens vers les dashboards, pré-URL), commandes '/promote ', '/rollback' via 'workflow _ dispatch'.

11) FinOps (coût des minutes et des ressources)

Concourency-cancel pour PR, matrices uniquement par parties modifiées (paths-filter).
Hygiène des artefacts : 'retention-days', autoproduction de preview bou.
Pools auto-hébergés pour assemblages lourds/ML, « heures silencieuses » de nuit.
Le cache dependency et le cache GHA BuildKit sont des économies importantes.

12) Monorepo et Parent/orchestration d'enfants

Déclencheurs par dossier/chemin : workflow indépendant par composant.
Reusable comme couche de normalisation entre les commandes (Payments/Risk/CRM/ETL/ML).
Diviser les secrets/environnements en composants.

13) Modèles pour iGaming

A) Backend/API (Go/Node/Python)

yaml name: backend on: [ pull_request, push ]
jobs:
ci:
uses: your-org/ci-templates/.github/workflows/backend. yml@v3 release:
if: startsWith(github. ref, 'refs/tags/v')
uses: your-org/ci-templates/.github/workflows/release. yml@v3 secrets: inherit

Б) ETL/DBT

yaml name: etl-dbt on: [ pull_request ]
jobs:
dbt:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5 with: { python-version: '3. 11' }
- run: pip install dbt-core dbt-bigquery
- run: dbt deps && dbt run && dbt test
- name: Publish docs run: dbt docs generate && tar czf docs. tgz target/
load artifact, retention period 3 days uses: actions/upload-artifact @ v4 with: {name: dbt-docs, path: docs. tgz, retention-days: 3 }

B) ML/LLM (inferences-artefacts)

yaml name: ml-pack on:
push:
tags: [ "model-" ]
jobs:
build-engine:
runs-on: self-hosted-gpu steps:
- uses: actions/checkout@v4
- run: python export_onnx. py
- run: trtexec --onnx=model. onnx --saveEngine=model. plan
- uses: actions/upload-artifact@v4 with: { name: engine, path: model. plan, retention-days: 7 }
- name: Sign & SBOM uses: your-org/sbom-sign-action@v2 with: { file: model. plan }

14) Chèque de mise en œuvre

1. Définissez les modèles CI/CD (Reusable/Composite) et appliquez-les à tous les repères.
2. Incluez les environnements avec les approvals et les secrets séparés.
3. Allez sur OIDC aux gestionnaires de clouds/secrets, enlevez les clés durables.
4. Entrez SAST/SCA/Secrets/DAST, SBOM et la signature des artefacts ; les gates sur les vulnérabilités critiques.
5. Personnalisez GitOps : manifeste-repo, auto-pare-chocs images/versions, canary/blue-green.
6. Optimisez le cache/matrices, 'concurrency. cancel-in-progress ', nettoyage des artefacts.
7. Développez les pools auto-hébergés (GPU inclus) avec des limites et une isolation.
8. Activez les réglages paths-filter et rule pour ne pas courir les jobs superflus.
9. Ajoutez ChatOps : statuts/commandes ; rapports au PR.
10. Fixez les politiques d'utilisation sécurisée des actions (pin SHA, limiter externe).

15) Anti-modèles

Les mêmes étapes dans tous les repos au lieu de Reusable/Composite → dissynchrone standard.
Les secrets cloud à longue durée de vie dans les variables au lieu d'OIDC.
Absence d'environnements/approvals pour la prod.
Les versions non joignables d'Actions tierces → les risques de la chaîne d'approvisionnement.
Pas de SBOM/signatures → pas de vérification sur CD.
Des matrices massives toujours en cours d'exécution → une augmentation des coûts.
CD d'Actions directement dans la prod sans trace de changement GitOps.

Résultats

GitHub Actions vous permet de construire un pipeline de sortie unique, sécurisé et reproductible : standardisez les pipelines via Reusable/Composite, utilisez OIDC et environnements avec approvals, implémentez SBOM/signature, transférez le CD vers GitOps avec livraison progressive, et les coûts sont sous contrôle cache/cache matrices/compétitivité. Cette approche s'adapte au rythme du produit iGaming, maintient la qualité et réduit les risques opérationnels.