# Un serveur de build partagé pour plusieurs sites WordPress d’agence

> Mutualiser une machine dédiée à la compilation des assets plutôt que de répéter le même build sur chaque poste et chaque runner CI de l'agence.

- Auteur : Clément Hadrot
- Publié le : 2022-06-15
- Mis à jour le : 2022-06-15
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/serveur-build-partage-plusieurs-sites-agence/

## L’essentiel

- Une seule machine pour compiler les assets de tous les projets
- Cache partagé entre les builds
- Réduction nette de la charge sur les runners CI

Sur une agence qui gère une vingtaine de sites WordPress, chacun avec son propre build front (Sass, JS bundlé, parfois des blocs Gutenberg personnalisés), la répétition du même travail de compilation sur chaque poste de développeur et sur chaque runner CI individuel finit par représenter un coût réel : temps machine gaspillé, caches de dépendances jamais partagés, et une variabilité entre postes qui produit parfois des résultats de build légèrement différents selon la version locale de Node installée.

La solution retenue ici a été de sortir la compilation de chaque poste et de chaque pipeline pour la centraliser sur une machine dédiée, un serveur de build interne, qui reçoit les demandes de compilation de tous les projets de l'agence et renvoie les artefacts compilés.

## Pourquoi mutualiser plutôt que dupliquer

Chaque pipeline CI classique repart de zéro : téléchargement des dépendances npm, compilation complète, à chaque exécution, sur une machine éphémère sans mémoire des builds précédents. Sur vingt-cinq projets qui partagent souvent les mêmes dépendances front (React, une même version de webpack ou de Vite, les mêmes polices), ce travail redondant s'additionne en temps de build cumulé et en consommation de minutes CI facturées.

## Architecture retenue

> L'essentiel à retenir : Une seule machine pour compiler les assets de tous les projets ; Cache partagé entre les builds ; Réduction nette de la charge sur les runners CI

```
agence-build-server/
├── cache/
│   ├── npm/              # cache npm partagé entre tous les projets
│   └── composer/         # cache Composer partagé
├── projets/
│   ├── client-a/
│   ├── client-b/
│   └── client-c/
└── build.sh               # script appelé par chaque pipeline CI
```

Le serveur expose un accès SSH restreint utilisé par les pipelines CI de chaque projet, qui se contentent d'envoyer les sources et de récupérer les assets compilés en retour, plutôt que d'exécuter elles-mêmes la compilation sur un runner éphémère :

```
ssh build@build-interne.exemple "cd projets/client-a && ./build.sh"
scp build@build-interne.exemple:projets/client-a/dist/* ./dist/
```

## Le gain concret sur le cache partagé

Le cache npm et Composer, stocké une seule fois sur le serveur de build et partagé par tous les projets, évite de retélécharger les mêmes paquets pour chaque site. Sur des projets qui partagent une bonne partie de leur socle technique (même thème parent, mêmes extensions maison), ce partage de cache réduit sensiblement le temps de build par rapport à un cache isolé par projet et par runner CI.

## Les compromis de cette architecture

- Le serveur de build devient un point de défaillance unique : sa panne bloque la compilation de tous les projets simultanément, contrairement à des runners CI isolés qui échouent indépendamment les uns des autres.
- Isoler correctement chaque projet sur le serveur partagé demande une discipline stricte : un mauvais chemin de cache partagé entre deux projets peut provoquer des dépendances croisées difficiles à diagnostiquer.
- La montée en charge simultanée de plusieurs builds nécessite un dimensionnement CPU et mémoire suffisant, sous peine de ralentir tous les projets en même temps lors de pics d'activité.

## Sécuriser les accès

Chaque pipeline CI dispose d'une clé SSH dédiée avec des droits restreints à son propre dossier de projet, via une configuration `authorized_keys` avec des restrictions de commande (`command=`) empêchant tout accès en dehors du script de build prévu :

```
command="/opt/build-server/build.sh client-a",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA...
```

> Un serveur de build partagé n'a de sens qu'à partir d'un certain nombre de projets actifs simultanément. En dessous d'une dizaine de sites, la complexité d'exploitation ajoutée dépasse largement le gain de temps obtenu.

## Ce que cette solution ne remplace pas

Ce serveur mutualisé compile les assets front, il ne remplace ni le déploiement final vers l'hébergement de chaque client, ni les tests automatisés qui doivent rester exécutés dans un environnement isolé par projet pour éviter tout effet de bord entre deux bases de code différentes.

## En résumé

Pour une agence qui gère un volume conséquent de sites WordPress avec des builds front similaires, mutualiser la compilation sur un serveur dédié réduit la redondance de travail et le coût en minutes CI, au prix d'une infrastructure supplémentaire à sécuriser et à maintenir. C'est un choix d'architecture qui se justifie à l'échelle, pas une recette universelle pour toute taille d'équipe.