Rôles
Étapes du processus
1
Ouvrir la PR develop vers staging
Le tech lead ouvre une pull request de la branche
develop vers staging. Le titre doit résumer clairement les changements promus (fonctionnalités, correctifs, dépendances mises à jour). La description de la PR peut lister les tickets associés et les points de vigilance pour le reviewer.2
Revue et merge
Un maintainer relit les fichiers modifiés, vérifie qu’aucun commit orphelin ne s’est glissé dans la PR, et s’assure que la branche
staging reste propre. Une fois la revue validée, il merge la PR. Seuls les merges sont autorisés : aucun force-push sur staging.3
Build de l'image stg
GitHub Actions détecte automatiquement le merge sur L’image est tagguée avec le hash du commit et le tag
staging. Il construit une nouvelle image Docker et la pousse vers le registre interne :stg pour le suivi.4
Déploiement automatique
argocd-image-updater scrute le registre ghcr.io et détecte la nouvelle image. ArgoCD applique ensuite le changement dans les namespaces *-stg correspondants. Le déploiement utilise les charts rollout-v2 (canary) ou antid-v2 (Deployment), selon la configuration du service.5
Tests d'intégration
La suite de tests d’intégration s’exécute automatiquement (ou est déclenchée manuellement selon le service) pour valider que les nouveaux composants communiquent correctement avec le reste de la plateforme sur la préproduction.
6
Validation QA
L’équipe QA valide fonctionnellement la préproduction. Sans ce feu vert, aucune pull request vers
production ne peut être ouverte. La validation QA est le gate obligatoire avant promotion.7
Décision de promotion
Si les tests d’intégration et la validation QA sont verts, le tech lead ouvre la PR
staging vers production. Le processus de déploiement en production est décrit dans la page Processus production.Vue d’ensemble du flux
Où vérifier le déploiement
Si la QA échoue
1
Reproduire le problème sur staging
Documentez le contexte complet : URL testée, paramètres envoyés, réponse observée, et écart avec le comportement attendu. Utilisez les logs du pod et les métriques du dahboard pour enrichir le rapport.
2
Ouvrir un ticket au développeur d'origine
Créez un ticket avec le label
qa-failed et assignez-le au développeur ou au tech lead responsable de la fonctionnalité. Incluez les étapes de reproduction et les captures d’écran si possible.3
Fix sur une branche de feature depuis develop
Le développeur crée une branche de feature à partir de
develop, applique le correctif, et suit le flux normal : PR vers develop, merge, puis le cycle staging recommence depuis l’étape 1.