Staging-piplines et versions

1) Pourquoi avez-vous besoin de staging-pipline

• reproductibilité de l'assemblage et de la version ;
• un fidbek rapide et prévisible ;
• Réduire au minimum les risques (roulements progressifs, filaments, reculs) ;
• conformité à la conformité et contrôle des changements.

2) Flux d'approvisionnement de référence (haut niveau)

1. PR → contrôles automatiques (lint, unit, SAST, licences).
2. Build → image/paquet déterministe, signature et SBOM.
3. Test sur Ephemeral → per-PR.

• une image dépréciée ;
• contrats, intégrations, e2e tests ;
• DAST/IAST, régressions, smoke de charge ;
• manuel UAT/QA si nécessaire.
• 5. Release Candidate (RC) → freeze window → Prod (canary/blue-green).
• 6. Contrôle post-deploy et retour automatique sur le budget SLO/error.
• 7. Runbook/Changelog → clôture de la sortie et rétrospective.

3) Modèle de pipline YAML normalisé (extrait)

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4) Gates et critères de préparation (Gates de qualité)

Code et sécurité : lentilles, couverture, SAST/SCA, politique de dépendance, pas de « critical/high ».
Contrats : compatibilité des schémas (API/événements), validation Pact/Buf.
Tests : unit/integration/e2e seuil de passage p, stabilité (flake-rate).
Charge smoke : p95/p99 dans le budget, pas de dégradation.
DAST/IAST : pas de findings critiques, script de test de mousse pour les chemins sensibles.
Observability : dashboards/alerts « as code » mis à jour, runbooks joints.
BOU/UAT : confirmation dans les fenêtres de sortie (si nécessaire par la réglementation/les entreprises).

5) Stratégies de sortie

Canary - augmentation progressive de la part du trafic (5 % → 25 % → 50 % → 100 %), roll-forward/rollback automatique sur SLO et anomalies.
Blue-Green - environnements parallèles ; commutateur instantané, simple retour.
Feature Flags - Activation logique des fiches sans redeploy ; possibilité de « dark launch » et A/B.
Shadow/Traffic Mirroring est un trafic passif sur la nouvelle version sans impact sur les utilisateurs.
Ring Deployments - vagues par région/tenants.

6) Les retraits et la politique de sécurité des communiqués

Retour automatique par déclenchement : augmentation du taux d'erreur, p95/TTFB au-dessus du seuil, augmentation de 5xx/timeout, surtension de DLQ.
Retour manuel : commande '/rollback <service> <sha> 'dans le chatbot, un bouton dans la console de sortie.
Freeze Windows : la sortie dans les événements critiques (tournois/matchs de pointe) est interdite.
Changelog & Release Notes : génération à partir de PR, balises BouVer, composants, migrations.

7) Migration OBD et compatibilité

1. ajouter des champs/index compatibles ;

2. Une application déplexe (lit/écrit dans les deux schémas) ;

3. Migration des données par jobs de fond ;

4. supprimer l'ancien.

Les schémas sont versionés, les migrations idempotent, dry-run vers staging.

Protect destructive SQL : require flag/approval, backup automatique et plan-check.

8) Ficheflagi et activation progressive

Séparez les drapeaux ops (pour une exploitation sûre) et les drapeaux produit.
Inclusion par public : pourcentage, géo, tenant, rôle.
Indicateurs d'indicateur : impact sur la conversion, latitude, erreurs.
En cas de problème, la réduction du drapeau est plus rapide que la restauration.

9) Observability dans le cadre de la sortie

Trajets : "trace _ id'de bout en bout de la passerelle à la base de données/files d'attente ; comparaison des anciennes/nouvelles versions.
Métriques : p50/p95/p99, taux d'erreur, RPS, saturation, DLQ, retraits, Time-to-Wallet/Business KPI.
Logs : structuré, masque PII, corrélation "request _ id'.
Alert : Budget SLO, pages urgentes sur appel, sortie auto-réduction.

10) Sécurité de la chaîne d'approvisionnement (chaîne d'approvisionnement)

SBOM pour chaque ticket, stockage et liaison à la balise de sortie.
Signatures d'image (cosign), vérification sur le cluster (admission de politique).
attestations SLSA : origine prouvée de l'artefact.
Policy-as-Code (OPA/Conftest) : deny-by-default pour les relations publiques d'infrastructure.
Secrets : uniquement de KMS, jetons à courte durée de vie, rotations en piplines.

11) Contrôle des changements et processus

RFC → CRQ → l'ACR : nous négocions un changement de comportement/contrat documenté à l'avance.
Calendrier de sortie : fenêtres visibles par produit/région/équipe.
Runbooks : pour chaque composant - procédures d'activation/de restauration/de diagnostic.
Postmortem/Retro : après des sorties significatives - analyse et actions.

12) Profils de test de staging

Contrat (API/Events) : bloque les modifications incompatibles.
Intégration/e2e : scripts de bout en bout « dépôt », « KYC », « retrait ».
Smoke de charge : pics représentatifs ; nous surveillons les limites des ressources.
Scénarios de chaos : arrêt du fournisseur, augmentation de la latence, flappings en réseau.
Surveillance synthétique : opérations « d'essai » programmées.

13) Exemple Makefile objectifs de sortie (fragment)

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14) Rôles et responsabilités

Dev/Team : qualité de code, tests, migrations, runbooks.
QA : scénarios UAT/région, contrôle de qualité sur les gates.
SRE/Plateforme : fiabilité des pipelines, observabilité, politiques.
Release Manager : calendrier, fenêtres, BOU, solution finale.
Sécurité : SAST/DAST/SCA, supply-chain, politique des secrets.

15) Modèle de maturité des sorties

1. La base est la vérification manuelle, les sorties rares, les retours sont difficiles.
2. Avancé - standard CI/CD, circuit de staging, canary/blue-green, versions fréquentes.
3. Experte - livraison progressive par tenants/régions, feature flags-first, policy-as-code, retour automatique sur SLO, traçabilité complète et SLSA.

16) Feuille de route pour la mise en œuvre

M0-M1 (MVP) : modèle de pipline, build + signe + SBOM, staging-deploy, tests de base et gates.
M2-M3 : canary/blue-green, preview per-PR, test de contrat, DAST, checks synthétiques.
M4-M6 : feature flags platform, shadow traffic, policy-as-code, auto-retour, release calendar + BOU-workflow.
M6 + : ring-deployments par région, certification SLSA et admission stricte, automatisation complète des runbooks.

17) Chèque-liste avant la publication

• Image signée, SBOM téléchargé et lié à la version.
• Les contrats sont compatibles, les tests sont verts, e2e sont passés sur staging.
• Migration vérifiée (dry-run), backap prêt, plan de retour décrit.
• Dashboards/alerts mis à jour, les gates SLO sont actifs.
• Runbook et Changelog sont publiés, les fenêtres de sortie sont harmonisées.
• Feature flags sont configurés pour s'activer progressivement.
• Freeze-restrictions respectées, on-call prêt.

Conclusion brève

Un staging-pipeline bien conçu transforme les sorties en une routine gérée : des modèles uniques, des gats de qualité clairs, une chaîne d'approvisionnement sécurisée, des roulements progressifs et une observabilité réduisent les risques et réduisent le temps de sortie des changements de production, tout en conservant le contrôle de la qualité et des métriques d'entreprise.