Skip to main content
Cette page décrit le parcours complet d’une modification de code, depuis la création d’une branche de feature jusqu’au déploiement en production chez Kaeyros Analytics. Suivez ces étapes pour garantir que chaque changement passe par les validations nécessaires.
1

Creer une branche de feature depuis develop

Partez toujours de la branche develop pour creer votre feature branch. Cela garantit que vous travaillez sur la version la plus recente du code.
Utilisez un prefixe descriptif pour vos branches : feat/, fix/, chore/ ou docs/. Cela facilite la revue et le tri dans GitHub.
2

Developper, committer et pousser

Travaillez localement, faites des commits atomiques avec des messages clairs, puis poussez votre branche sur le depot distant.
Les hooks de pre-commit (lint, formatage) sont executes automatiquement. Corrigez les erreurs avant de pousser.
3

Ouvrir une Pull Request vers develop

Sur GitHub, ouvrez une PR de votre feature branch vers develop. GitHub Actions lance automatiquement :
  • Les tests unitaires et d’integration
  • Le lint et le controle de formatage
  • Un build de verification de l’image Docker
Si la CI echoue, la PR est bloquee. Corrigez les erreurs et poussez un nouveau commit ; la pipeline se relance automatiquement.
4

Revue de code et approbation

Un pair doit examiner votre PR. La revue verifie la logique metier, la qualite du code, la couverture de tests et la conformite aux standards de l’equipe.
  • Au moins une approbation est requise
  • Les conversations doivent etre resolues
  • La CI doit etre verte
Une fois validee, mergez la PR sur develop (merge commit, pas de squash force).
5

Deploiement automatique en developpement

Apres le merge sur develop, GitHub Actions construit et publie l’image :
Le tag est marque comme dev. argocd-image-updater detecte la nouvelle image, ArgoCD applique le changement dans le namespace *-dev.
Verifiez le deploiement dans l’interface ArgoCD ou via kubectl get pods -n <app>-dev.
6

Promotion vers staging

Le tech lead ouvre une PR de develop vers staging. Apres validation rapide, le merge declenche :
  1. Un build de l’image avec le tag stg
  2. La publication sur ghcr.io
  3. Le deploiement automatique dans le namespace *-stg
L’equipe QA valide ensuite fonctionnellement le comportement sur staging.
Staging est un environement de pre-production. Les donnees y sont anonymisees mais le comportement doit etre identique a la production.
7

Promotion vers production (canary)

Une fois QA validee, une PR de staging vers production est ouverte. Elle doit etre revue par un maintainer.Apres merge :
  1. Build de l’image avec le tag prod
  2. Argo Rollouts bascule le trafic par paliers progressifs :
    • 10% pendant 5 minutes
    • 25% pendant 5 minutes
    • 50% pendant 5 minutes
    • 75% pendant 5 minutes
    • 100%
A chaque palier, les sondes de sante et les metriques SLO sont verifiees. Si un seuil d’erreur est depasse, le deploiement est automatiquement annule.
Ne jamais reecrire l’historique de develop, staging ou production. Merges only, pas de force-push.
8

Verification et rollback

Apres le deploiement en production, surveillez les indicateurs pendant au moins 30 minutes :
  • ArgoCD : etat des pods, synchronisation des applications
  • Grafana : latence, taux d’erreur, throughput
  • Alertes : verifier qu’aucune alerte critique n’est declenchee
En cas de probleme, annulez le rollout immediatement :
Le trafic revient instantanement a la version precedente stable.
Le cycle complet d’une modification, du merge sur develop jusqu’au deploiement en production, se fait typiquement en 24 a 48 heures selon la complexite du changement et la disponibilite de la revue QA.