> ## 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 vers l'environnement de développement

> Détail du processus de déploiement automatique vers l'environnement de développement. Du push sur develop au Rollout canary, avec les rôles et responsabilités de chaque acteur.

L'environnement de développement est le terrain d'expérimentation des équipes Kaeyros Analytics. Tout push sur la branche `develop` déclenche automatiquement une chaîne de déploiement sans porte de validation humaine : c'est le lieu où le code est intégré, testé et visualisé en conditions réelles le plus rapidement possible.

## Rôles et responsabilités

| Rôle | Action | Outil / Système |
| - | - | - |
| **Développeur** | Push du code sur la branche `develop` | Git, GitHub |
| **CI GitHub Actions** | Build, tests, scan sécurité, push image | GitHub Actions |
| **argocd-image-updater** | Détection du nouveau tag d'image | argocd-image-updater (cluster) |
| **ArgoCD** | Application des manifests Kubernetes | ArgoCD (cluster) |
| **Rollout** | Déploiement canary court | Argo Rollouts (cluster) |

## Étapes du processus

**1. Push sur develop**

Le développeur merge une PR ou pousse directement sur `develop`. Cette branche n'exige pas de review obligatoire, mais la CI doit être verte.

**2. Déclenchement de la CI**

GitHub Actions exécute le workflow `ci.yml` : lint, tests unitaires, coverage, Semgrep SAST, gitleaks, build Docker.

**3. Publication de l'image**

L'image Docker est tagguée avec le SHA court du commit (7 caractères) et poussée vers `ghcr.io/kaeyros-analytics-org/<service>:<sha-court>`.

**4. Détection par argocd-image-updater**

L'updater surveille ghcr.io toutes les 2 minutes. Il détecte le nouveau tag et met à jour l'Application ArgoCD via la méthode `write-back-method: argocd`.

**5. Synchronisation ArgoCD**

ArgoCD détecte la modification de l'Application et synchronise les manifests. Le champ `image.tag` dans les values est mis à jour.

**6. Rollout canary court**

Le Rollout déploie la nouvelle version avec une stratégie canary rapide : 100% du trafic bascule dès que les pods sont ready (pas de phase progressive en dev).

**7. Validation automatique**

Les healthchecks Kubernetes et les sondes de readiness valident que l'application démarre correctement. En cas d'échec, le Rollout annule automatiquement.

## Diagramme du flux

```mermaid theme={null}
graph LR
    A[Push sur develop] -->|Webhook| B[GitHub Actions CI]
    B -->|Build OK| C[Push image ghcr.io]
    C -->|Tag SHA court| D[argocd-image-updater]
    D -->|Update Application| E[ArgoCD]
    E -->|Sync| F[Rollout canary]
    F -->|Pods ready| G[Dev live]
    F -->|Échec healthcheck| H[Auto-rollback]

    style A fill:#e1f5fe
    style G fill:#c8e6c9
    style H fill:#ffcdd2
```

## Caractéristiques du déploiement dev

> **Auto-review sans obstacle**
>
> Pas de review obligatoire, pas d'approbation DevOps. Le développeur itère rapidement. La CI verte est la seule porte.

> **Canary court**
>
> Le Rollout en dev n'utilise pas de phase progressive. Dès que les nouveaux pods passent les readiness probes, 100% du trafic bascule.

> **Tags SHA court**
>
> Les images sont identifiées par les 7 premiers caractères du hash du commit. Traçabilité immédiate entre code et déploiement.

> **Durée typique**
>
> De push à pods running : 3 à 5 minutes (build CI : \~2 min, détection updater : \~2 min, sync + rollout : \~1 min).

> [!NOTE]
>
> L'environnement de développement est volontairement permissif. C'est le terrain de jeu où les développeurs valident leurs hypothèses. En contrepartie, aucune donnée client ou sensible n'y transite.

## Monitoring du déploiement

Pour suivre un déploiement en cours :

```bash theme={null}
# Voir les Applications ArgoCD en dev
kubectl get applications -n argocd -l env=dev

# Suivre le statut d'un Rollout
kubectl argo rollouts get rollout <nom-du-rollout> -n <namespace-dev>

# Logs de l'updater
kubectl logs -n argocd deployment/argocd-image-updater -f
```

## En cas de problème

> **La CI échoue**
>
> Consultez les logs GitHub Actions. Les échecs les plus fréquents sont : tests unitaires en échec, findings Semgrep bloquants, ou secrets détectés par gitleaks. Corrigez le problème en local et repoussez.

> **L'image n'apparaît pas dans ArgoCD**
>
> Vérifiez que argocd-image-updater est bien configuré pour surveiller l'image. Contrôlez les annotations de l'Application :
>
> ```bash theme={null}
> kubectl get application <nom-app> -n argocd -o yaml | grep image-updater
> ```

> **Le Rollout reste bloqué**
>
> Inspectez les événements du Rollout et les logs des pods. Le blocage est généralement dû à un healthcheck échouant ou à une erreur de démarrage de l'application.
>
> ```bash theme={null}
> kubectl argo rollouts get rollout <nom-rollout> -n <namespace>
> kubectl describe rollout <nom-rollout> -n <namespace>
> ```

> [!WARNING]
>
> L'environnement de développement partage le cluster de production mais est isolé par namespace. Ne déployez jamais manuellement avec `kubectl apply` : passez toujours par ArgoCD pour préserver la traçabilité GitOps.

> [!TIP]
>
> Pour accélérer vos itérations, utilisez `kubectl port-forward` pour accéder directement à un service en dev sans passer par l'ingress public :
>
> ```bash theme={null}
> kubectl port-forward svc/<mon-service> 8080:80 -n <namespace-dev>
> ```


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