Projet multi-composants pour la gestion d'étudiants, composé d'une API backend Spring Boot, d'une application mobile Flutter et d'un environnement d'exécution conteneurisé (PostgreSQL + Redis).
etudiant-service/: API REST Java (Spring Boot, Spring Data JPA, PostgreSQL, Redis cache, Actuator, OpenAPI).mobile_app/: application Flutter (base de projet, UI initiale).docker-compose.yml: orchestration des servicespostgres,redisetetudiant-service..github/pull_request_template.md: template de PR déjà aligné avec une checklist qualité/sécurité/tests.
- Docker et Docker Compose
- Java 25 (si exécution locale hors Docker)
- Flutter SDK (si exécution de l'application mobile)
- Créer un fichier
.envà la racine avec les variables nécessaires (exemple) :POSTGRES_DBPOSTGRES_USERPOSTGRES_PASSWORDETUDIANT_SERVICE_PORTSPRING_DATASOURCE_URLSPRING_DATASOURCE_USERNAMESPRING_DATASOURCE_PASSWORDSPRING_REDIS_PORT6DD3
- Lancer la stack :
docker compose up --build
- Vérifier la santé du service :
http://localhost:<ETUDIANT_SERVICE_PORT>/actuator/health
Depuis etudiant-service/ :
- Windows :
.\mvnw.cmd spring-boot:run - Linux/macOS :
./mvnw spring-boot:run
- Étudiants :
POST /api/etudiantsGET /api/etudiantsGET /api/etudiants/{id}PUT /api/etudiants/{id}DELETE /api/etudiants/{id}
- Départements :
POST /api/departementsGET /api/departementsGET /api/departements/{id}PUT /api/departements/{id}DELETE /api/departements/{id}
- Observabilité :
GET /actuator/health
- Documentation API (springdoc) :
GET /swagger-ui/index.html
Depuis etudiant-service/ :
- Windows :
.\mvnw.cmd test - Linux/macOS :
./mvnw test
Le projet inclut :
- des tests Spring Boot de contexte,
- des scénarios BDD Cucumber (
src/main/resources/features/etudiant.feature), - un rapport Cucumber généré dans
target/cucumber-reports/report.html.
Les règles suivantes s'appliquent à toutes les Pull Requests de l'équipe :
- Délai de review : toute PR doit recevoir une première review sous 48h maximum.
- Responsable de la review : l'auteur assigne au moins 1 reviewer (et 2 reviewers pour les changements sensibles : sécurité, base de données, infra).
- Commentaires bloquants : tout commentaire marqué bloquant (bug, régression, faille sécurité, non-respect architecture) doit être résolu avant merge.
- Conversations résolues : aucune conversation GitHub ne doit rester ouverte au moment du merge.
- Qualité automatique obligatoire : la PR n'est mergée que si la CI est verte (build + tests + checks qualité configurés).
- Traçabilité : chaque PR doit référencer un ticket (ex. Jira) et décrire clairement le pourquoi, le quoi et le plan de test.
- Taille et lisibilité : privilégier des PR petites et cohérentes (un objectif fonctionnel par PR) pour accélérer la review.
- Mise à jour documentaire : si comportement, API ou configuration changent, la documentation et les variables d'environnement doivent être mises à jour dans la même PR.
- Règle d'approbation : merge autorisé uniquement après approbation explicite d'au moins un reviewer et absence de point bloquant.
- Exceptions (hotfix critique) : en cas d'urgence de production, merge possible avec revue différée, mais une revue complète et une PR de régularisation doivent être faites sous 24h.
- Suivre le template de PR présent dans
.github/pull_request_template.md. - Vérifier localement les tests avant ouverture de PR.
- Éviter d'inclure des secrets (tokens, mots de passe, clés) dans le code ou les commits.