Aller au contenu

Référence CI/CD historique — sports-connect-front

Objet du document

Ce document décrit une photographie historique de l’ancienne architecture CI/CD de sports-connect-front.

Il ne décrit plus la chaîne active cible de HeyMoov. Il sert de référence de départ pour comprendre le builder legacy et les migrations réalisées ensuite.

Périmètre

  • Application : web app React
  • Dépôt GitHub : sports-connect-front
  • Environnements couverts :
  • staging
  • production (structure partiellement connue, modèle similaire à staging)

État du document :

  • référence legacy
  • non source de vérité pour les déploiements HeyMoov actuels
  • à lire comme état hérité avant bascule vers les nouvelles chaînes GitHub Actions

Vue d’ensemble

La chaîne actuelle repose sur trois rôles distincts : 1. GitHub Actions pour le déclenchement. 2. Un serveur de build pour la récupération du code, le build front et la publication de l’artefact. 3. Un serveur de déploiement par environnement pour récupérer l’artefact et l’installer sur le serveur web.

Machines identifiées

  • Serveur de build : ls2i-notification
  • Serveur de déploiement + web staging : ls2i-staging
  • Serveur de déploiement + web production : machine de production distincte

Flux global

Staging

  1. Un push sur la branche staging déclenche un workflow GitHub Actions.
  2. Le workflow s’exécute sur un runner self-hosted situé sur ls2i-notification.
  3. Le runner appelle le script local /opt/builder/bin/build sports-connect staging.
  4. Le script :
  5. charge la configuration d’environnement,
  6. met à jour le dépôt local,
  7. installe les dépendances,
  8. build l’application React,
  9. génère une archive staging.tar.gz.
  10. L’archive est rendue accessible via https://build.ls2i.net/....
  11. Le script appelle le webhook de déploiement staging : https://staging.deploy.ls2i.net/deploy/sports-connect.
  12. Le serveur ls2i-staging reçoit la demande, télécharge l’archive depuis build.ls2i.net, puis l’extrait dans le répertoire web staging.
  13. Le site staging est servi directement depuis ce répertoire.

Production

Le principe est équivalent : 1. push sur main 2. build sur ls2i-notification 3. publication de l’artefact 4. appel d’un webhook de déploiement production 5. récupération de l’artefact par le serveur de production 6. installation dans le répertoire web de production

Remarque : les détails exacts du webhook et du script de déploiement production n’ont pas encore été documentés dans cette version de référence.

Déclenchement GitHub

Workflow

Nom du workflow : Build and deploy

Déclencheurs : - push sur staging - push sur main - workflow_dispatch

Jobs

  • build-staging si github.ref == 'refs/heads/staging'
  • build-production si github.ref == 'refs/heads/main'

Commandes exécutées

Staging

/opt/builder/bin/build sports-connect staging

Production

/opt/builder/bin/build sports-connect main

Serveur de build — ls2i-notification

Le serveur de build a plusieurs responsabilités : - héberger le runner self-hosted GitHub Actions, - maintenir un clone local des dépôts, - exécuter les builds front, - publier les artefacts, - déclencher les déploiements via webhook.

Script principal de build

Chemin : /opt/builder/bin/build

Comportement du script

Le script de build : 1. valide les arguments (project, env), 2. charge un fichier d’environnement situé dans /opt/builder/env/<project>/<env>, 3. configure l’accès GitHub via une clé SSH dédiée, 4. clone le dépôt si nécessaire dans /opt/builder/src/<project>, 5. se positionne sur la branche définie par GIT_BRANCH, 6. exécute git fetch puis git pull si nécessaire, 7. vérifie la cohérence des variables VITE_APP* et REACT_APP* avec .env.dist, 8. nettoie node_modules et le dossier de build, 9. exécute : - pnpm install --no-frozen-lockfile - pnpm build 10. crée une archive .tar.gz dans /opt/builder/build/<project>/, 11. appelle un webhook de déploiement.

Exemple d’environnement staging

Fichier : /opt/builder/env/sports-connect/staging

Paramètres observés : - GIT_BRANCH=staging - DEPLOY_PATH=/var/www/staging.sports-connect.net - DEPLOY_SERVER=debian@152.228.231.145 - WEBHOOK_URL=https://staging.deploy.ls2i.net/deploy - WEBHOOK_TOKEN=***

Variables applicatives front : - VITE_APP_API_GO_BASE_URL=https://staging.app.sports-connect.net - VITE_APP_PREFIX_AUTH=/v1/web/auth - VITE_APP_PREFIX_PUBLIC=/v1/public - VITE_APP_PREFIX_API=/v1/web/api - VITE_APP_MERCURE_URL=https://staging.mercure.sports-connect.net - VITE_APP_MERCURE_PREFIX_TOPIC=https://staging.app.sports-connect.net - VITE_APP_BASE_SEGMENT_URL=/ - VITE_APP_HUGO_URL=https://staging.www.sports-connect.net - VITE_APP_UPLOAD=https://staging.app.sports-connect.net/uploads - variables de captcha masquées

Artefacts de build

Emplacement disque

Pour sports-connect : - staging : /opt/builder/build/sports-connect/staging.tar.gz - production : attendu sur le même modèle, par ex. main.tar.gz

Publication HTTP

Le domaine build.ls2i.net est servi par Nginx sur ls2i-notification.

Configuration observée : - root /opt/builder/build; - autoindex on; - accès HTTPS - restriction IP : - allow 152.228.231.145; - deny all;

Conséquence : - l’artefact /opt/builder/build/sports-connect/staging.tar.gz - devient accessible via https://build.ls2i.net/sports-connect/staging.tar.gz - uniquement depuis la machine ls2i-staging

Webhook de déploiement staging

URL

https://staging.deploy.ls2i.net/deploy/:project

Hébergement

  • Nginx sur ls2i-staging
  • reverse proxy vers 127.0.0.1:9222

Restrictions d’accès

Nginx n’autorise que l’IP du serveur de build ls2i-notification.

Authentification applicative

Le service Go vérifie un token transmis soit : - en query string : access_token - soit via le header : Authorization: X-Auth-Token <token>

Comportement du contrôleur

Le contrôleur : 1. lit le paramètre :project, 2. répond immédiatement 202 Accepted, 3. exécute ensuite la commande définie par DEPLOY_CMD, avec le nom du projet.

Point important

Le statut HTTP 202 est renvoyé avant la fin réelle du déploiement. Le succès de la requête HTTP ne garantit donc pas que le déploiement a abouti.

Déploiement staging

Service Go

  • variable DEPLOY_CMD=bin/deploy
  • le contrôleur lance : 
    bin/deploy sports-connect

Script de déploiement

Le script de staging : 1. définit server_url="https://build.ls2i.net" 2. télécharge l’archive : 

https://build.ls2i.net/sports-connect/staging.tar.gz
3. la stocke dans /tmp/build/sports-connect.tar.gz 4. choisit le répertoire cible via un mapping project -> deploy_path 5. pour sports-connect, le chemin cible est : 
/var/www/staging.sports-connect.net
6. crée le répertoire si nécessaire 7. extrait l’archive dans le répertoire cible avec tar xf

Répertoire cible observé

  • staging : /var/www/staging.sports-connect.net

Hébergement web staging

Le site staging est servi sur la même machine que le déployeur, à savoir ls2i-staging.

Diagramme logique

GitHub push (staging/main)
-> GitHub Actions
-> runner self-hosted sur ls2i-notification
-> script /opt/builder/bin/build
-> git fetch / git pull
-> pnpm install
-> pnpm build
-> archive tar.gz dans /opt/builder/build/<project>/
-> exposition via build.ls2i.net
-> appel webhook deploy
-> service Go de déploiement
-> téléchargement de l’artefact
-> extraction dans /var/www/...
-> site servi par le serveur web cible

Hypothèses opérationnelles

Staging

  • GIT_BRANCH=staging
  • l’artefact attendu est staging.tar.gz
  • le site est servi depuis /var/www/staging.sports-connect.net

Production

  • GIT_BRANCH=main
  • l’artefact attendu est probablement main.tar.gz
  • le site est servi par une machine de production distincte

Forces de l’architecture actuelle

  • séparation claire entre build et déploiement,
  • artefacts publiés via HTTP simple,
  • cloisonnement réseau par IP,
  • token applicatif sur le webhook,
  • architecture compréhensible et légère,
  • possibilité de centraliser le build sur une seule machine.

Faiblesses et points de vigilance

1. Le build n’est pas figé sur le SHA du workflow

Le script build la branche via git pull, et non le commit exact ayant déclenché le workflow.

2. Retour prématuré du webhook

Le webhook répond 202 Accepted avant la fin réelle du déploiement.

3. Déploiement non atomique

L’archive est extraite directement dans le répertoire servi.

4. Risque de fichiers obsolètes

Le répertoire cible n’est pas nettoyé explicitement avant extraction.

5. Pas de rollback natif visible

Aucun mécanisme de release versionnée, de symlink current, ou de restauration automatique n’a été identifié.

6. Reproductibilité partielle du build

pnpm install --no-frozen-lockfile réduit le déterminisme du build.

7. Contrôles qualité peu visibles

Aucun lint, test unitaire, audit de dépendances ou smoke test post-déploiement n’a été identifié dans les éléments documentés.

8. Gestion de concurrence non documentée

Aucun verrou explicite n’a été observé pour empêcher des builds ou déploiements simultanés.

Zones encore à documenter

Pour compléter cette référence, il reste à documenter : - le webhook de production, - le script de déploiement production, - le chemin final de déploiement production, - la configuration Nginx du site staging, - la configuration Nginx du site production, - la stratégie de rollback, - la politique de journalisation et d’alerting, - la gestion de la concurrence, - les tests attendus avant et après déploiement.

Pistes d’optimisation prioritaires

Priorité 1 — Fiabiliser

  • figer le build sur le SHA GitHub du workflow,
  • faire remonter le statut réel du déploiement,
  • ajouter un verrou par projet/environnement,
  • nettoyer ou versionner les répertoires de release.

Priorité 2 — Rendre le déploiement plus sûr

  • déployer dans un dossier versionné,
  • basculer via symlink current,
  • conserver les N dernières releases,
  • prévoir un rollback manuel rapide.

Priorité 3 — Améliorer la qualité pipeline

  • ajouter lint,
  • ajouter tests unitaires,
  • ajouter smoke tests post-déploiement,
  • utiliser un lockfile strict si possible.

Priorité 4 — Observabilité

  • centraliser les logs,
  • tracer le SHA déployé,
  • notifier les échecs de build et de déploiement avec contexte,
  • conserver un historique de releases par environnement.

Conclusion

L’architecture actuelle fonctionne comme une chaîne build centralisé + artefacts HTTP + déploiement pull via webhook. Elle est simple et opérationnelle, mais présente plusieurs fragilités classiques : traçabilité imparfaite du SHA, déploiement non atomique, absence de rollback visible, et retour de succès trop tôt côté webhook.

Ce document doit servir de base de travail pour cadrer les prochaines optimisations sans perdre la compréhension de l’existant.