Pipeline Complet — Du push au Paradis PROD
As-Sirât (الصراط) — le pont du Jugement Dernier en Islam. Plus fin qu'un cheveu, plus tranchant qu'une lame de rasoir. Il est tendu au-dessus de l'Enfer. Les pieux le traversent à la vitesse de l'éclair et accèdent au Paradis. Ceux qui ont péché tombent. Chacun le traverse selon ses œuvres.
Le code aussi sera jugé. Il traverse SIRRAT selon la qualité de ses tests.
Architecture du pipeline DYNORS
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DYNORS — LE CHEMIN DE SIRRAT │
└─────────────────────────────────────────────────────────────────────────────────────┘
😈 DÉVELOPPEUR 🔥 CI/CD 📦 DÉPÔTS
───────────────── ──────────────── ─────────────────────────
┌─────────────┐ ┌─────────────────────────┐
git push ────► │ GitLab CI │ ──Build──► │ Package Registry │
feature/… │ Pipeline │ │ (Maven — JAR) │
develop │ │ │ gitlab.com/.../packages │
release/… │ ① build │ └─────────────────────────┘
│ ② test │ ──Image──► ┌─────────────────────────┐
│ ③ scan │ │ Container Registry │
│ ④ publish │ │ (Docker — image:tag) │
└──────┬──────┘ │ registry.gitlab.com/… │
│ └─────────────────────────┘
│ résultats (tests, coverage, scan)
▼
────────────────────────────────────────────────────────────────────────────────────
🌫 SIRRAT — LE GARDIEN DU PONT
────────────────────────────────────────────────────────────────────────────────────
┌──────────────────────────────────────────────────────┐
│ sirrat.dynors.com │
│ │
│ • Reçoit les résultats CI (API webhook) │
│ • Calcule le Karma │
│ • Évalue les Quality Gates │
│ • Gère les déploiements autorisés │
│ • Archive les PV de recette │
└───────────────┬──────────────────────────────────────┘
│
┌────────────────────────┼────────────────────────┐
│ autorisé │ │
▼ ▼ │
──────────────────────────────────────────────────────────────── │
🌫 PRÉ-PROD (RMOA DYNORS) 🌟 RECETTE CLIENT (RMOA CLIENT) │
────────────────────────── ─────────────────────────────── │
│
docker pull image:tag docker pull image:tag │
docker-compose up docker-compose up │
│
QA DYNORS teste Client valide │
Quality Gate #1 Client signe PV │
│
────────────────────────────────────────────────────── │ SIRRAT
SIRRAT : PV signé + CTO ◄────────────────┘
──────────────────────
│
▼
────────────────────────────────────────────────────────────────────
😇 PRODUCTION
──────────────────────────────────────────────────────────────────
docker pull image:v1.3.0
docker-compose -f docker-compose.prod.yml up -d
curl /actuator/health ✅
──────────────────────────────────────────────────────────────────
Diagramme Mermaid — flux complet
flowchart TD
DEV["👨💻 Développeur\ngit push"]
subgraph CI["🔥 GitLab CI Pipeline"]
B1[① Build backend JAR]
B2[② Tests unitaires + intégration]
B3[③ Scan sécurité]
B4[④ Build image Docker]
B5[⑤ Publish artefacts]
end
subgraph DEPOT["📦 Dépôt d'Artefacts"]
PKG["Package Registry\nMaven JAR\ngitlab.com/.../packages"]
IMG["Container Registry\nDocker image:tag\nregistry.gitlab.com/..."]
end
subgraph SIRRAT_BOX["🌫 SIRRAT — Le Gardien"]
SR1[Réception résultats CI]
SR2[Calcul Karma]
SR3[Évaluation Quality Gates]
SR4{Gate passé ?}
end
subgraph PREPROD["🌫 Pré-prod — RMOA DYNORS"]
PP1[docker pull image:tag]
PP2[QA DYNORS teste]
PP3{Quality Gate #1}
end
subgraph RECETTE["🌟 Recette — RMOA CLIENT"]
RC1[docker pull image:tag]
RC2[Client teste]
RC3[Client signe PV]
RC4{Quality Gate #2/#3}
end
PROD["😇 Serveur Production\ndocker-compose prod\n✅ health check"]
DEV --> B1 --> B2 --> B3 --> B4 --> B5
B5 -->|JAR| PKG
B5 -->|image| IMG
B2 -->|résultats| SR1
B3 -->|résultats| SR1
SR1 --> SR2 --> SR3 --> SR4
SR4 -->|✅ autorisé| PP1
PP1 --> PP2 --> PP3
PP3 -->|✅ passé| RC1
RC1 --> RC2 --> RC3 --> RC4
RC4 -->|PV signé + CTO| PROD
SR4 -->|❌ refusé| DEV
PP3 -->|❌ bugs| DEV
RC4 -->|❌ refus client| PP1
IMG -.->|pull au déploiement| PP1
IMG -.->|pull au déploiement| RC1
IMG -.->|pull au déploiement| PROD
Le Dépôt d'Artefacts — pièce centrale
Le dépôt est le pont physique entre le CI et les environnements. Il contient deux types d'artefacts :
1. Package Registry (Maven — JAR)
Utilisé par les modules core et extensions (dynors-commons, dynors-security, etc.) — pas par les applications finales.
git push → CI publish → GitLab Package Registry
↓
gradle dependency resolution
↓
autre projet (SuperGest, Mediconnect…)
| Registry | URL | Projet |
|---|---|---|
| dynors-core | gitlab.com/api/v4/projects/75907047/packages/maven |
modules commons, security, db, events, interapp-client |
| dynors-extensions | gitlab.com/api/v4/projects/XXXXX/packages/maven |
notify, pdf, invoicing, billing… |
2. Container Registry (Docker — images)
Utilisé par toutes les applications (SuperGest backend, Mediconnect frontend, SLY…) pour déployer en pré-prod et prod.
git push → CI build image → GitLab Container Registry
↓
docker pull image:tag
↓
docker-compose up (RMOA / PROD)
Naming convention des tags Docker :
| Tag | Usage | Exemple |
|---|---|---|
dev-<sha7> |
Deploy DEV (auto) | backend:dev-a1b2c3d |
rmoa-dynors-<sha7> |
Deploy RMOA DYNORS (manuel) | backend:rmoa-dynors-a1b2c3d |
rmoa-client-<sha7> |
Deploy RMOA CLIENT (manuel) | backend:rmoa-client-a1b2c3d |
<semver> |
Deploy PROD | backend:v1.3.0 |
latest |
Alias PROD | backend:latest |
Option self-hosted : Harbor
Pour une infra 100 % interne (clients on-premise), Harbor est l'alternative open source gratuite au GitLab Container Registry :
# Installer Harbor sur un VPS
curl -L https://github.com/goharbor/harbor/releases/latest/download/harbor-online-installer.tgz \
| tar -xz && cd harbor
cp harbor.yml.tmpl harbor.yml
# Configurer hostname, TLS, admin password
./install.sh
Harbor offre : scan de vulnérabilités intégré (Trivy), quota par projet, réplication entre registries.
Séquence complète : push → prod
sequenceDiagram
actor Dev as 👨💻 Développeur
participant GL as GitLab CI
participant PKG as 📦 Package Registry
participant IMG as 🐳 Container Registry
participant SR as 🌫 SIRRAT
participant RMOA as 🌫 RMOA DYNORS
participant REC as 🌟 RMOA CLIENT
participant PROD as 😇 PRODUCTION
Dev->>GL: git push (develop / release/*)
GL->>GL: ① build JAR
GL->>GL: ② tests (unit + integ)
GL->>GL: ③ scan sécurité
GL->>GL: ④ docker build
GL->>PKG: publish maven (si module core/ext)
GL->>IMG: docker push image:dev-sha
GL->>SR: POST /quality-gates/results (tests, coverage, scan)
SR->>SR: calcul karma, évaluation gate
Note over SR: Quality Gate #0 (CI) → autorisé deploy DEV
SR-->>RMOA: autorisé deploy DEV (automatique)
RMOA->>IMG: docker pull image:dev-sha
RMOA->>RMOA: docker-compose up (dev)
Note over Dev,RMOA: QA DYNORS teste 3-5 jours
SR->>SR: Quality Gate #1 passé ?
SR-->>RMOA: autorisé RMOA DYNORS (manuel)
RMOA->>IMG: docker pull image:rmoa-dynors-sha
Note over Dev,REC: Client teste 7-14 jours
SR->>REC: PV de recette généré
REC->>SR: Client signe PV
SR->>SR: Quality Gate #3 passé (PV signé + CTO)
SR-->>PROD: autorisé PRODUCTION (manuel CTO)
PROD->>IMG: docker pull image:v1.3.0
PROD->>PROD: docker-compose -f prod up -d
PROD->>PROD: health check ✅
PROD->>SR: déploiement confirmé
SR->>SR: Karma +50 → Code Divin ✨
Infrastructure recommandée (gratuite)
┌─────────────────────────────────────────────────────────────────────┐
│ INFRASTRUCTURE DYNORS │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ gitlab.com (gratuit) │
│ ├── Code source (tous les repos) │
│ ├── GitLab CI pipelines (+ runners self-hosted) │
│ ├── Package Registry (Maven — modules core/extensions) │
│ └── Container Registry (Docker — images apps) │
│ │
│ VPS DYNORS #1 — CI Runner (~10€/mois) │
│ └── gitlab-runner (executor docker) │
│ │
│ VPS DYNORS #2 — DEV + RMOA DYNORS (~20€/mois) │
│ ├── docker-compose.dev.yml (branch develop) │
│ └── docker-compose.rmoa-dynors.yml (branch release/*-internal) │
│ │
│ VPS/Serveur CLIENT — RMOA CLIENT (~selon client) │
│ └── docker-compose.rmoa-client.yml │
│ │
│ Serveur CLIENT — PRODUCTION │
│ └── docker-compose.prod.yml │
│ │
│ VPS DYNORS #3 — SIRRAT + Monitoring (~15€/mois) │
│ ├── SIRRAT app (Spring Boot) │
│ ├── Grafana + Prometheus + Loki │
│ └── Redis (cache SIRRAT + SLY) │
│ │
│ TOTAL INFRA DYNORS : ~45–50€/mois │
└─────────────────────────────────────────────────────────────────────┘
Variables d'environnement SIRRAT dans le CI
Chaque pipeline doit notifier SIRRAT à chaque étape clé. Les variables à configurer dans GitLab → Settings → CI/CD → Variables :
SIRRAT_API_URL=https://sirrat.dynors.com/api
SIRRAT_API_TOKEN=sirrat_xxxxxxxxxxxxx # token projet — MASQUÉ
SIRRAT_PROJECT_ID=supergest-001 # identifiant projet dans SIRRAT
Appels SIRRAT dans le pipeline :
# Après les tests
- curl -sX POST $SIRRAT_API_URL/projects/$SIRRAT_PROJECT_ID/quality-gates/results
-H "Authorization: Bearer $SIRRAT_API_TOKEN"
-d '{"type":"tests","status":"passed","coverage":85,"commit":"'$CI_COMMIT_SHA'"}'
# Après chaque déploiement
- curl -sX POST $SIRRAT_API_URL/projects/$SIRRAT_PROJECT_ID/deployments
-H "Authorization: Bearer $SIRRAT_API_TOKEN"
-d '{"environment":"dev","version":"'$CI_COMMIT_SHORT_SHA'","status":"deployed"}'
Résumé du chemin
CODE (pêcheur ou saint ?)
│
▼ git push
CI Pipeline
(jugement automatique : tests, scans)
│
▼ résultats → SIRRAT
📦 Dépôt (Maven JAR + Docker image)
│
▼ autorisé
SIRRAT 🌫 (le pont — Al-Sirāt)
"Traverseras-tu ou tomberas-tu ?"
│
┌────┴─────┐
│ │
▼ ▼ ❌ bugs
RMOA DYNORS ← Retour en Enfer DEV 😈
RMOA CLIENT
│
▼ PV signé
😇 PRODUCTION — Le Paradis
"Karma 100/100 — Code Divin ✨"
La vitesse de traversée du pont dépend des œuvres (tests, couverture, sécurité). Certains passent à la vitesse de l'éclair. D'autres rampent. Et certains tombent. — SIRRAT, Gardien Suprême