CI/CD

Tous les dépôts de l'écosystème utilisent GitHub Actions. Cette page décrit les modèles et conventions communs.

Principes fondamentaux

1. On vérifie sur la PR, on déploie sur main. Une PR lance la construction et les tests, et ne déploie rien. Le déploiement ne démarre qu'après la fusion dans main.
2. On ne reconstruit que ce qui a changé. paths-filter détermine les parties modifiées et seuls ces services sont reconstruits.
3. Pas de déploiements concurrents. Un groupe concurrency met les déploiements de production en file d'attente pour qu'ils ne se chevauchent jamais.
4. Les secrets uniquement dans GitHub Secrets. Ils ne sont jamais écrits dans un fichier de workflow.

La forme habituelle d'un workflow

name: deploy

on:
  push:
    branches: [main]
    paths:
      - 'backend/**'
      - 'frontend/**'
      - '.github/workflows/deploy.yml'
  workflow_dispatch:          # possibilité de lancement manuel

concurrency:
  group: deploy-production
  cancel-in-progress: false   # ne jamais interrompre un déploiement en cours

cancel-in-progress: false est essentiel

Un déploiement coupé en plein milieu peut laisser un état incomplet : le nouveau conteneur non démarré, l'ancien déjà arrêté. Il faut laisser le déploiement aller à son terme et mettre le suivant en file d'attente.

L'étape de vérification (PR)

Vérification	Ce qu'elle fait
Build	Le code compile-t-il
Tests unitaires	Logique métier
Tests d'intégration	testcontainers — de vrais PostgreSQL/Redis
Lint	Style de code
Build strict de la documentation	Détecte les liens cassés et les fichiers manquants

Le contrôle strict de la documentation

MkDocs est construit en mode --strict. Dans ce mode, les avertissements deviennent des erreurs :

• liens internes cassés,
• fichiers déclarés dans nav mais inexistants,
• fichiers existants mais absents de nav.

Cela empêche une documentation cassée d'atteindre la production.

L'étape de déploiement

Elle se connecte à l'hôte en SSH. Les secrets nécessaires (nommage courant) :

Secret	Signification
DEPLOY_HOST	Adresse du serveur
DEPLOY_USER	Utilisateur SSH
DEPLOY_SSH_KEY	Clé privée
DEPLOY_PORT	Port SSH (facultatif, 22 par défaut)
DEPLOY_PATH	Chemin sur l'hôte

Une clé SSH, pas un mot de passe

Le déploiement utilise une clé SSH, pas un mot de passe. Une clé se révoque facilement, risque moins de se retrouver par accident dans les journaux, et se renouvelle sans avoir à la redistribuer à tout un groupe.

Constructions partielles

Dans un monorepo, un changement ne doit pas imposer de reconstruire tous les services :

- uses: dorny/paths-filter@v3
  id: filter
  with:
    filters: |
      backend: 'backend/**'
      frontend: 'frontend/**'
      edge: 'nginx/**'

Seuls les services modifiés sont ensuite reconstruits. Si c'est l'edge (nginx) qui a changé, il n'y a pas de reconstruction complète — seulement une synchronisation de la config + nginx -t + reload.

Déployer la configuration de l'edge

Le conf.d de l'edge nginx est géré par git. Séquence de déploiement :

1. Synchroniser le dépôt sur l'hôte avec git fetch && git reset --hard,
2. docker exec <nginx> nginx -t — valider la configuration,
3. En cas de succès, nginx -s reload.

Ne sautez jamais nginx -t

Un reload avec une configuration erronée empêche nginx de redémarrer — et à cet instant tous les domaines tombent. nginx -t doit s'exécuter avant le reload, et un échec doit interrompre le déploiement.

Runners auto-hébergés

Les builds iOS et Windows (signature de code, notarisation, empaquetage MSIX) utilisent des runners macOS / Windows auto-hébergés. Ils exigent des outils et des certificats propres à la plateforme, et ne peuvent donc pas s'exécuter sur des runners cloud.

Versionnement et rollback

• Les images sont taguées. Une variable <SVC>_IMAGE_TAG sur l'hôte permet d'épingler une version précise.
• Pour les sites statiques, on redéploie l'archive de la construction précédente.

La CI/CD de ce dépôt

Le dépôt docs-gerege-mn comporte deux workflows :

Workflow	Quand	Ce qu'il fait
ci.yml	PR + push sur main	Build MkDocs --strict ; laisse un artefact
deploy.yml	Push sur main + manuel	Build → copie → mise à jour du conteneur → installation du vhost edge → vérification du site en ligne

Voir Cette plateforme documentaire pour le détail.