« Ce Makefile fait tout, personne ne sait plus exactement quoi. » Cette phrase, entendue lors d’une reprise de projet, résume bien ce qui arrive à un outil de déploiement pensé au départ pour tenir en une trentaine de lignes lisibles, et qui a fini par en accumuler plus de trois cents après quatre ans de correctifs ponctuels ajoutés dans l’urgence.
Un Makefile de déploiement WordPress commence presque toujours simplement : une cible pour synchroniser les fichiers, une pour vider le cache, une pour lancer les tests. Puis un cas particulier apparaît, on ajoute une condition. Puis un autre serveur rejoint le parc, on ajoute une variable. Au bout de quatre ans, le fichier devient un empilement de correctifs que personne n’ose plus toucher sans crainte de casser un déploiement en production.
Ce qu’on observe sur le terrain
Plusieurs symptômes reviennent presque systématiquement dans un Makefile de déploiement devenu illisible avec le temps. Aucun n’est fatal isolément, mais leur accumulation rend le fichier impossible à faire évoluer sereinement.
- Des cibles qui appellent d’autres cibles en cascade, sans commentaire expliquant l’ordre d’exécution attendu.
- Des conditions
ifeqimbriquées sur trois ou quatre niveaux pour gérer des variantes de serveurs jamais consolidées. - Des variables d’environnement définies à plusieurs endroits différents du fichier, avec des valeurs par défaut contradictoires.
- Une cible unique de plusieurs centaines de lignes qui mélange synchronisation de fichiers, migration de base de données et purge de cache.
- Des commentaires devenus faux, qui décrivent un comportement que le code ne reproduit plus depuis longtemps.
Pourquoi c’est un problème concret
Un Makefile de cette taille ne se lit plus, il se devine. Chaque modification devient un pari : personne ne peut prédire avec certitude l’effet d’un changement sur une cible sans relire l’intégralité du fichier, ce qui décourage les corrections mêmes mineures. Le risque le plus concret est le déploiement partiel : une cible qui échoue silencieusement à mi-chemin, faute de gestion d’erreur explicite entre les étapes enchaînées, laisse le serveur dans un état intermédiaire difficile à diagnostiquer.
Autre conséquence directe : l’onboarding d’un nouveau développeur sur le projet prend des heures rien que pour comprendre quelle commande lance réellement un déploiement complet, information qui devrait tenir en une ligne de documentation.
Quoi faire : un redécoupage progressif
Réécrire l’intégralité du Makefile d’un coup est risqué sur un projet en production active : la tentation de « tout refaire proprement » introduit souvent de nouvelles régressions. Une approche progressive limite ce risque :
- Identifier les cibles réellement utilisées en pratique en observant l’historique des commandes exécutées sur le serveur, plutôt que de se fier à la documentation existante, souvent obsolète.
- Extraire les cibles trop longues en sous-cibles nommées explicitement, chacune avec une seule responsabilité (synchronisation, migration, purge de cache).
- Déplacer les variables dispersées vers un unique fichier
.envouconfig.mkinclus en tête de fichier, avec des valeurs par défaut cohérentes. - Supprimer les cibles mortes une fois confirmé, sur plusieurs cycles de déploiement, qu’elles ne sont plus appelées nulle part.
- Ajouter une cible
helpqui liste les commandes disponibles avec une courte description, pour que la documentation vive dans le fichier lui-même.
Un exemple de redécoupage
# Avant : une cible fourre-tout de plusieurs centaines de lignes
deploy:
rsync -avz ./ user@serveur:/var/www/site/
ssh user@serveur "wp cache flush"
ssh user@serveur "wp db query < migrations/latest.sql"
# ... des dizaines de lignes supplémentaires
# Après : des cibles séparées, appelées explicitement
deploy: sync-fichiers migrer-base purger-cache
sync-fichiers:
rsync -avz ./ user@serveur:/var/www/site/
migrer-base:
ssh user@serveur "wp db query < migrations/latest.sql"
purger-cache:
ssh user@serveur "wp cache flush"Un Makefile ne devient jamais illisible en un jour : il le devient une exception à la fois, chacune paraissant raisonnable sur le moment.
En résumé
Un Makefile de déploiement surchargé n’exige pas nécessairement son remplacement par un autre outil, une décision qui mérite sa propre réflexion séparée. Le redécouper en cibles nommées, responsables d’une seule tâche chacune, avec une documentation intégrée via une cible help, redonne une lisibilité suffisante pour que l’équipe recommence à le faire évoluer sans crainte.
