> ## Documentation Index
> Fetch the complete documentation index at: https://infra-docs.kaeyros.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Flux d'une modification, du commit à la production

> Trajet d'un changement de code : feature branch, revue, merge sur develop, promotion vers staging puis production.

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.

```mermaid placement="top-right" theme={null}
flowchart LR
    A[Feature branch] -->|PR| B[develop]
    B -->|GitHub Actions| C[Build image dev]
    C -->|argocd-image-updater| D[Deploy auto dev]
    D -->|PR| E[staging]
    E -->|GitHub Actions| F[Build image stg]
    F -->|ArgoCD| G[Deploy staging]
    G -->|QA valide| H[PR staging->production]
    H -->|GitHub Actions| I[Build image prod]
    I -->|Argo Rollouts| J[Deploy canary prod]
```

**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.

```bash theme={null}
git checkout develop
git pull origin develop
git checkout -b feat/<sujet> develop
```

> [!TIP]
>
> 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.

```bash theme={null}
git add .
git commit -m "feat: ajoute le calcul des cohortes mensuelles"
git push -u origin feat/<sujet>
```

> [!NOTE]
>
> 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

> [!NOTE]
>
> 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 :

```text theme={null}
ghcr.io/kaeyros-analytics-org/<image>:<sha>
```

Le tag est marque comme `dev`. `argocd-image-updater` detecte la nouvelle image, ArgoCD applique le changement dans le namespace `*-dev`.

> [!TIP]
>
> 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.

> [!NOTE]
>
> 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.

> [!WARNING]
>
> 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 :

```bash theme={null}
kubectl argo rollouts abort <nom-du-rollout> -n <namespace-prod>
```

Le trafic revient instantanement a la version precedente stable.

> [!TIP]
>
> 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.