b1957c1c81
- Config Spec-Kit pour Spec-Driven Development - CONSTITUTION.md + .specify/memory/constitution.md - Commandes Cursor /speckit.*, règles projet - Mission: associations + mutuelles d'épargne et de financement - .gitignore: versionner config spec-kit unionflow Made-with: Cursor
196 lines
8.8 KiB
Markdown
196 lines
8.8 KiB
Markdown
# Lacunes limitant la maturité professionnelle – UnionFlow
|
||
|
||
**Date :** 25 février 2026
|
||
**Objectif :** Consolider les lacunes identifiées pour la mise en production (maturité « professionnelle »), à partir de commandes exécutées sur le dépôt et sur le VPS 176.57.150.2.
|
||
|
||
---
|
||
|
||
## 1. CI/CD dédié UnionFlow
|
||
|
||
### Constat
|
||
- **Aucune référence à `unionflow`** dans `.github/workflows/` du workspace.
|
||
- Les workflows existants (`backend-ci.yml`, `frontend-ci.yml`) ciblent uniquement :
|
||
- `mic-after-work-server-impl-quarkus-main/**`
|
||
- `afterwork/**`
|
||
- **Aucun dossier `.github/`** dans `unionflow/` (pas de workflows au niveau du projet UnionFlow).
|
||
|
||
### Preuves
|
||
```text
|
||
# Recherche "unionflow" dans .github
|
||
→ Aucun match
|
||
|
||
# Contenu paths des workflows
|
||
backend-ci.yml: paths: 'mic-after-work-server-impl-quarkus-main/**'
|
||
frontend-ci.yml: paths: 'afterwork/**'
|
||
```
|
||
|
||
### Impact
|
||
- Pas de build/test automatisé au push sur le code UnionFlow.
|
||
- Déploiement dépendant de **lionsctl** (infra) et de builds manuels ; pas de pipeline « code → test → image → déploiement » propre au dépôt UnionFlow.
|
||
|
||
---
|
||
|
||
## 2. Docker et contexte de build
|
||
|
||
### Constat
|
||
- **Un seul `docker-compose`** dans UnionFlow : `unionflow-server-impl-quarkus/docker-compose.dev.yml`.
|
||
- Contient uniquement **PostgreSQL + Adminer** (réseau `unionflow-dev`).
|
||
- **Aucun** service backend, client ou Keycloak dans ce compose.
|
||
- **Pas de docker-compose « full stack »** (backend + client + DB + Keycloak) pour recette/prod locale.
|
||
- Les **Dockerfile.prod** (client et serveur) utilisent une instruction invalide :
|
||
```dockerfile
|
||
COPY ../unionflow-server-api/pom.xml ../unionflow-server-api/
|
||
```
|
||
- `COPY` ne peut pas sortir du contexte de build ; ce chemin est invalide en build Docker classique depuis le répertoire du module.
|
||
|
||
### Preuves
|
||
```text
|
||
# Fichiers docker-compose dans unionflow
|
||
→ unionflow-server-impl-quarkus/docker-compose.dev.yml (postgres-dev + adminer uniquement)
|
||
|
||
# COPY dans Dockerfile.prod
|
||
unionflow-server-impl-quarkus/Dockerfile.prod: COPY ../unionflow-server-api/pom.xml ...
|
||
unionflow-client-quarkus-primefaces-freya/Dockerfile.prod: COPY ../unionflow-server-api/pom.xml ...
|
||
```
|
||
|
||
### Impact
|
||
- Build des images « prod » depuis ces Dockerfiles tels quels : **probable échec** sans contexte multi-module (type monorepo root).
|
||
- Pas de stack complète reproductible en local pour tester un déploiement type prod.
|
||
|
||
---
|
||
|
||
## 3. Couverture de code et dette explicite
|
||
|
||
### Constat (données JaCoCo précédentes + code)
|
||
- **Backend** (unionflow-server-impl-quarkus) :
|
||
- Couverture globale : **62 % instructions**, **44 % branches** (objectif typique prod ~80 %).
|
||
- **BaseRepository** : **0 %** couvert (classe de base des repositories).
|
||
- Modules à couverture faible : ex. mutuelle/credit, parties de DocumentService.
|
||
- **TODOs laissés dans le code** (dette explicite) :
|
||
- `OrganisationService.java` : `// TODO Cat.2 : repartitionRegion via Adresse`
|
||
- `NotificationService.java` : `// TODO: Support HTML body if needed`
|
||
- **Métriques Hibernate** : `quarkus.hibernate-orm.metrics.enabled=false` (application.properties et application-prod.properties).
|
||
|
||
### Preuves
|
||
```text
|
||
# TODOs
|
||
OrganisationService.java:376 // TODO Cat.2 : repartitionRegion via Adresse
|
||
NotificationService.java:399 // TODO: Support HTML body if needed
|
||
|
||
# Métriques désactivées
|
||
application.properties: quarkus.hibernate-orm.metrics.enabled=false
|
||
application-prod.properties: quarkus.hibernate-orm.metrics.enabled=false
|
||
```
|
||
|
||
### Impact
|
||
- Risque de régressions sur les zones non couvertes et sur BaseRepository.
|
||
- Fonctionnalités incomplètes (repartitionRegion, corps HTML des notifications).
|
||
- Pas de métriques ORM pour le tuning et le monitoring.
|
||
|
||
---
|
||
|
||
## 4. Métriques Prometheus (backend)
|
||
|
||
### Constat
|
||
- Les déploiements K8s sur le VPS ont les **annotations Prometheus** :
|
||
- `prometheus.io/scrape=true`
|
||
- `prometheus.io/path=/q/metrics`
|
||
- `prometheus.io/port=8080`
|
||
- Le **backend** n’expose **pas** l’endpoint `/q/metrics` :
|
||
- Aucune dépendance `quarkus-micrometer` ou `quarkus-smallrye-metrics` dans `unionflow-server-impl-quarkus/pom.xml`.
|
||
- Seul `quarkus-smallrye-health` est présent (endpoint `/health`).
|
||
- **Vérification sur le VPS** :
|
||
- `GET http://127.0.0.1:8080/health` → **200**, `"status":"UP"`.
|
||
- `GET http://127.0.0.1:8080/q/metrics` → **404**.
|
||
|
||
### Preuves
|
||
```text
|
||
# VPS - annotations sur les deployments
|
||
unionflow-server-impl-quarkus: prometheus.io/path=/q/metrics, prometheus.io/port=8080, prometheus.io/scrape=true
|
||
unionflow-client-quarkus-primefaces-freya: idem
|
||
|
||
# VPS - curl depuis le pod backend
|
||
/health → 200 {"status":"UP","checks":[...]}
|
||
/q/metrics → 404
|
||
|
||
# pom.xml backend
|
||
→ quarkus-smallrye-health présent
|
||
→ pas de quarkus-micrometer ni quarkus-smallrye-metrics
|
||
```
|
||
|
||
### Impact
|
||
- Prometheus scrape les pods mais **n’obtient pas de métriques** applicatives (404).
|
||
- Pas de métriques type taux d’erreur, latence, throughput par endpoint pour UnionFlow backend.
|
||
|
||
---
|
||
|
||
## 5. Documentation opérationnelle (runbook, rollback)
|
||
|
||
### Constat
|
||
- **Aucun fichier** `runbook*`, `PLAYBOOK*`, `CONTRIBUTING*` dans `unionflow/`.
|
||
- **SECURITY.md** : présent uniquement dans `unionflow-client-quarkus-primefaces-freya/`.
|
||
- **CHANGELOG.md** : présent uniquement dans le client.
|
||
- La section « Déploiement » du README client décrit déploiement manuel (serveur Linux, Nginx) mais **pas** :
|
||
- Procédure de rollback.
|
||
- Runbook d’incident.
|
||
- Escalade ou contacts.
|
||
|
||
### Preuves
|
||
```text
|
||
# Recherche runbook / playbook / CONTRIBUTING dans unionflow
|
||
→ 0 fichier runbook*, PLAYBOOK*, CONTRIBUTING*
|
||
|
||
# Déploiement / rollback dans .md
|
||
→ README client : section "Déploiement" (manuel)
|
||
→ CHANGELOG : mention "Déploiement expliqué"
|
||
→ Aucun document dédié rollback ou runbook
|
||
```
|
||
|
||
### Impact
|
||
- En incident ou après un mauvais déploiement, pas de procédure documentée dans le dépôt UnionFlow pour rollback ou diagnostic.
|
||
|
||
---
|
||
|
||
## 6. État du VPS et déploiement actuel (consultation)
|
||
|
||
### Constat (lecture seule)
|
||
- **Déploiements** : `unionflow-client-quarkus-primefaces-freya` et `unionflow-server-impl-quarkus` en **Running** (1/1), namespace `applications`.
|
||
- **Ingress** : `unionflow.lions.dev` (client), `api.lions.dev` (path `/unionflow` pour le backend), adresse **176.57.150.2**.
|
||
- **Monitoring** : services `grafana-service` et `prometheus-service` présents dans le namespace `monitoring`.
|
||
- **Pods** : 2 restarts sur les deux déploiements (il y a ~41 jours), âge ~63–65 jours.
|
||
|
||
### Preuves
|
||
```text
|
||
kubectl get deployments,services,ingress -n applications | grep unionflow
|
||
→ deployment unionflow-client-quarkus-primefaces-freya 1/1 74d
|
||
→ deployment unionflow-server-impl-quarkus 1/1 77d
|
||
→ ingress unionflow-client... unionflow.lions.dev 176.57.150.2
|
||
→ ingress unionflow-server... api.lions.dev 176.57.150.2
|
||
```
|
||
|
||
---
|
||
|
||
## Synthèse des lacunes (maturité professionnelle)
|
||
|
||
| # | Lacune | Gravité | Preuve (commande / fichier) |
|
||
|---|--------|--------|------------------------------|
|
||
| 1 | Pas de CI/CD dédié UnionFlow dans le dépôt | Élevée | Aucun path `unionflow/**` dans `.github/workflows/` |
|
||
| 2 | Docker : pas de compose full stack ; Dockerfile.prod avec COPY hors contexte | Élevée | docker-compose.dev.yml (DB seule) ; COPY `../unionflow-server-api/` dans Dockerfile.prod |
|
||
| 3 | Couverture backend 62 % / 44 %, BaseRepository 0 %, TODOs métier | Moyenne | JaCoCo ; OrganisationService/NotificationService TODOs ; hibernate-orm.metrics.enabled=false |
|
||
| 4 | Endpoint /q/metrics absent (404) malgré annotations Prometheus sur les pods | Moyenne | curl /health → 200, /q/metrics → 404 ; pas de quarkus-micrometer dans pom |
|
||
| 5 | Pas de runbook ni procédure de rollback dans UnionFlow | Moyenne | Aucun fichier runbook/playbook/rollback ; README déploiement manuel uniquement |
|
||
|
||
---
|
||
|
||
## Recommandations (ordre de priorité)
|
||
|
||
1. **CI/CD** : Ajouter un workflow (ex. `.github/workflows/unionflow-ci.yml`) qui déclenche sur `unionflow/**`, avec build + test + (optionnel) build d’image.
|
||
2. **Docker** : Corriger le contexte de build (build depuis la racine du monorepo ou adapter les Dockerfile.prod) ; ajouter un `docker-compose.yml` (ou équivalent) pour stack complète dev/recette.
|
||
3. **Métriques** : Ajouter `quarkus-micrometer` (ou l’extension Prometheus) au backend et exposer `/q/metrics`, ou retirer les annotations Prometheus des déploiements pour éviter des 404.
|
||
4. **Couverture / dette** : Viser ≥80 % couverture sur le backend ; couvrir BaseRepository ; traiter ou documenter les TODOs (repartitionRegion, HTML body).
|
||
5. **Opérationnel** : Rédiger un runbook (déploiement, rollback, incidents courants) et le versionner dans le dépôt UnionFlow (ex. `docs/runbook.md`).
|
||
|
||
---
|
||
|
||
*Rapport généré à partir de l’analyse du dépôt et de commandes exécutées sur le VPS (consultation seule).*
|