La qualité de LydiaCMS repose sur l’analyse statique, les tests et une pipeline de release. Tout ce qui peut être automatisé, je l’automatise : du contrôle du code jusqu’au déploiement.
Analyse statique de PHP : PHPStan et Rector
PHPStan tourne au niveau maximal (max) avec 8 règles maison qui surveillent les conventions du projet, et 14 règles Rector maison savent corriger les écarts en masse dans tous les paquets. Le résultat est une meilleure qualité de code : les erreurs d’architecture sont détectées à l’analyse et non à l’exécution. Code : PHPStan, Rector.
Tests : Nette Tester et E2E dans Playwright
- Le noyau compte plus de 600 tests unitaires et d’intégration dans Nette Tester. Ils s’exécutent en parallèle et chaque thread travaille avec son propre préfixe de tables de base de données.
- L’application d’exemple dispose d’une suite de tests E2E dans Playwright (plus de 30 fichiers) qui parcourt la partie publique du site et l’administration.
- Les tests des paquets PHPStan et Rector tournent dans la pipeline CI, tandis que je lance les tests du noyau en local dans Docker.
Pipeline CI/CD dans GitLab : versions automatiques et publication des paquets
Les paquets s’installent depuis un registre Composer privé ; chaque publication doit donc être uniforme et sans étape manuelle. Tous les paquets utilisent ainsi une même pipeline GitLab, et un changement de processus se fait en un seul endroit. Elle comporte trois étapes :
- Check.
composer validate --strictet un contrôle de la syntaxe PHP dans toutes les sources. En cas d’échec, le paquet n’est pas publié. - Tag. Sur la branche principale, la version suivante est calculée et envoyée.
- Build. Le tag envoyé publie le paquet dans le registre Composer, et l’application récupère la nouvelle version avec
composer update.
Déploiement sans interruption (zero-downtime deployment)
Une nouvelle version du site n’est pas déployée directement dans l’application en cours d’exécution. Un script prépare à côté d’elle une release complète et ne bascule qu’une fois celle-ci vérifiée :
- construit la release à partir de la branche et installe les dépendances sans les paquets de développement,
- rattache les données partagées (
.env, journaux, fichiers téléversés), - démarre l’application à l’essai, si bien qu’un build défaillant n’atteint jamais le basculement,
- sauvegarde la base de données et exécute les migrations (
lydiacms:upgrade), - vérifie le site par un contrôle de santé et, en cas d’échec, revient tout seul à la release précédente.
Sauvegarde et retour arrière
La base de données est sauvegardée avant les migrations. En cas de problème, on peut restaurer aussi bien la release précédente (les fichiers) que la base de données à partir de la sauvegarde.