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

# Processus de déploiement en préproduction

> Déploiement en préproduction : PR develop vers staging, validation QA, build stg, déploiement automatique par ArgoCD.

Le déploiement en préproduction suit une logique similaire à l'environnement de développement, avec l'ajout d'un gate de validation QA avant toute promotion vers la production. Cette page détaille les rôles et les étapes du processus staging.

## Rôles

| Rôle | Responsabilité |
| - | - |
| Tech lead | Décide de la promotion `develop` vers `staging` |
| QA | Valide la préproduction |
| Maintainer | Merge la PR sur `staging` |
| GitHub Actions | Build image stg, tests d'intégration |
| ArgoCD | Applique au namespace `*-stg` |

## É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 `staging`. Il construit une nouvelle image Docker et la pousse vers le registre interne :

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

L'image est tagguée avec le hash du commit et le tag `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](https://infra-docs.kaeyros.org/cicd/processus-production.md).

## Vue d'ensemble du flux

```mermaid theme={null}
flowchart LR
    A[develop] -->|PR + merge| B[staging]
    B -->|GitHub Actions| C[Build image stg]
    C -->|argocd-image-updater| D[ArgoCD]
    D -->|Déploiement| E[Namespaces *-stg]
    E -->|Tests auto| F{Tests OK ?}
    F -->|Oui| G[Validation QA]
    F -->|Non| H[Fix sur feature branch]
    H --> A
    G -->|Feu vert| I[PR staging vers production]
    G -->|Refus| H
```

## Où vérifier le déploiement

```bash ArgoCD theme={null}
argocd app get <app>-stg
```

```bash Rollout en cours theme={null}
kubectl argo rollouts get rollout <app>-rollout-v2 -n <ns>-stg --watch
```

```bash Pod actif theme={null}
kubectl -n <ns>-stg get pods
```

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

> [!WARNING]
>
> Ne jamais forcer un correctif directement sur `staging`. Tout fix doit passer par `develop` pour préserver l'intégrité des branches et la traçabilité des changements.

> [!TIP]
>
> La préprod utilise les mêmes charts que la prod (rollout-v2 en priorité), pour que les tests reflètent le comportement final.


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