Sprint 0 Report — Fondations & CI/CD de base
Période : 2026-05-02 à 2026-05-16 Équipe : 1 ingénieur DevOps (Youssef Kadi) Repo : gitlab.com/yk-devops/fastapi-eks-project
Rapport rédigé a posteriori (backfill du 2026-06-20) pour homogénéiser la série 0→4. Les stories et incidents proviennent du milestone GitLab et des incidents documentés à l'époque ; la rétrospective est reconstituée à partir de ces traces, pas d'un ressenti à chaud.
Executive Summary
Sprint d'amorçage du projet. L'objectif n'était pas de livrer une fonctionnalité visible mais de poser des fondations saines : migrer le code FastAPI existant sur GitLab, instaurer un Git Flow discipliné (branches develop / feature/*), et faire tourner un premier pipeline CI avec un stage de tests. En parallèle, l'environnement de développement local (FastAPI + PostgreSQL + Alembic via docker-compose) a été fiabilisé et le Dockerfile durci a minima (utilisateur non-root, image slim). Ces fondations, fragiles au départ, ont conditionné toute la suite : la discipline « une branche, une MR » née ici a tenu sur les cinq sprints suivants.
Stories livrées
| # | Description | Taille | Statut |
|---|---|---|---|
| #1 | Migrer le code FastAPI existant sur GitLab | S | Livré |
| #2 | Configurer Git Flow (branches develop, feature/*) |
S | Livré |
| #3 | Écrire le .gitlab-ci.yml — stage test |
M | Livré |
| #4 | Vérifier docker-compose local (FastAPI + PostgreSQL + Alembic) | M | Livré |
| #5 | Hardening Dockerfile (utilisateur non-root, image slim) | S | Livré |
| #6 | Écrire le README avec diagramme d'architecture | S | Livré |
Vélocité
| Taille | Nb éléments |
|---|---|
| S | 4 |
| M | 2 |
| Total | 6 |
Incidents majeurs et résolutions
Le sprint a capitalisé 3 incidents (INC-001 à INC-003), tous liés à la compréhension des priorités d'un outil (variables CI, configuration, migrations).
INC-001 : variable GitLab CI Protected sur une feature branch
Le stage test échouait sur SECRET_KEY Field required. Cause : la variable SECRET_KEY était marquée Protected, donc injectée uniquement sur les branches protégées (main, develop), jamais sur une feature/*.
Leçon : Protected = injecté seulement sur branches protégées ; Masked = caché dans les logs. Règle retenue : variables CI en Masked uniquement, sauf secrets de production.
INC-002 : Pydantic BaseSettings, priorité .env vs variables d'environnement
Connection refused: localhost:5432 en docker-compose. Cause : Pydantic lisait DB_HOSTNAME=localhost du .env, écrasant le DB_HOSTNAME=db injecté par Docker.
Leçon : un fichier .env.docker dédié pour le dev conteneurisé ; en CI, pas de .env (variables injectées). Connaître l'ordre de priorité des sources de config.
INC-003 : migration Alembic dupliquée
DuplicateTable: relation "users" already exists. Une migration recréait des tables déjà créées.
Leçon : toujours vérifier alembic history --verbose avant d'ajouter une migration ; ne jamais recréer une table existante.
Décisions d'architecture (ADRs)
Pas d'ADR formel à ce stade : les décisions de fondation (Git Flow, structure CI, Dockerfile) sont capturées directement dans .gitlab-ci.yml, le Dockerfile et le README. Les premiers ADR formalisés apparaissent au Sprint 2 (infra Terraform).
Rétrospective (reconstituée)
Ce qui a posé les bonnes bases. La discipline Git Flow (une branche, une MR) instaurée dès ce sprint a structuré tout le projet. Le pipeline de test minimal a donné un filet de sécurité immédiat.
Ce qui a coûté du temps. Trois incidents sur des priorités d'outils (Protected/Masked, .env/env vars, historique Alembic) : des pièges classiques de démarrage, vite résolus une fois la mécanique comprise. Le coût réel était la compréhension, pas le fix.
Ce que ça a appris. Comprendre comment un outil résout ses priorités (variables, config, migrations) évite des heures de debug. Ce réflexe (« lire le bon signal, comprendre la mécanique ») reviendra sur tous les sprints suivants.
Sprint 0 fermé le 2026-05-16. Premier jalon du projet : les fondations CI/CD et le développement local sont en place.