Cet article propose un workflow GitHub Actions idéal pour les applications Symfony. L'objectif principal est de garantir que le code et les dépendances livrés fonctionnent dans un environnement similaire à la production. Il met en avant un workflow de CI de base axé sur les tests, le linting, l'analyse statique et la sécurité des dépendances.
Le workflow présenté inclut des étapes essentielles pour une application Symfony typique. Il couvre la configuration de PHP, l'installation des dépendances via Composer avec mise en cache, la création et la migration de la base de données de test (PostgreSQL ou MySQL), ainsi que la validation de la cohérence du schéma de base de données avec le mapping Doctrine. Ce workflow est conçu pour s'exécuter lors des pull requests et des commits sur la branche principale, assurant une intégration continue fiable.
Le workflow CI utilise un environnement de test avec une version de PHP correspondant à celle de production, ainsi qu'un service de base de données (PostgreSQL ou MySQL) pour simuler un environnement réel. Il inclut également la gestion des étapes de validation de la base de données pour détecter et afficher les divergences entre le schéma attendu et celui généré par les migrations.
Résumé pour Shaarli:
Workflow GitHub Actions recommandé pour les applications Symfony, axé sur les tests, l'analyse et la validation dans un environnement proche de la production. Il automatise l'installation des dépendances, la gestion de la base de données de test et la vérification de la cohérence du schéma, assurant la fiabilité du code avant le déploiement.
L’article explique comment détecter les régressions visuelles dans une CI en utilisant Playwright et Docker. L’idée principale est d’intégrer des tests de capture d’écran pour comparer l’apparence actuelle d’une page avec une référence, afin d’éviter des modifications CSS non détectées avant la mise en production. Playwright propose l’assertion toHaveScreenshot() qui compare les images et échoue si la différence dépasse un seuil configuré.
La mise en œuvre repose sur des tests simples couvrant les pages clés du site, mais nécessite un environnement déterministe pour éviter les faux positifs. L’équipe a dû éliminer les sources de variation, comme les images en lazy loading ou les polices web, en attendant que la page soit visuellement stable avant de capturer l’écran. Un helper stabilize() est utilisé pour attendre la fin du chargement des ressources et des polices.
Enfin, la solution est intégrée dans une CI via Docker pour garantir un rendu cohérent entre les machines, et les images de différence sont postées directement dans les commentaires des pull requests pour faciliter le diagnostic des régressions.
L’article explique comment optimiser une chaîne d’intégration continue (CI) en mettant en cache l’état d’une base de données pour éviter de régénérer les données à chaque build. L’idée centrale est de remplacer le rechargement systématique des fixtures et migrations par un snapshot (instantané) de la base, reconstruit uniquement lorsque les fichiers sources (migrations, fixtures) changent. Cela réduit considérablement le temps de CI, passant de 50 secondes à quelques secondes pour la préparation de la base, tout en garantissant la cohérence des données.
L’auteur détaille une implémentation concrète sur un projet Symfony utilisant Castor pour l’automatisation et des runners GitHub Actions auto-hébergés. Le cache est partagé entre les jobs via des dossiers locaux, mais une solution équivalente est possible avec les caches natifs de GitHub. L’empreinte du snapshot est calculée à partir des fichiers déterminants (migrations, fixtures), permettant une invalidation automatique et fiable du cache.
Enfin, l’article souligne que cette méthode évite les écueils des dumps statiques (obsolescence ou régénération inutile), tout en restant compatible avec des architectures distribuées. L’approche est présentée comme une alternative efficace aux techniques classiques d’optimisation de CI, avec un gain de temps significatif pour les projets où les modifications des données sont rares.
Tout est dans le titre
Tout est dans le titre
L'auteur étudie plusieurs cas de figure, ici c'est l'entreprise qui n'a ni intégration continue, ni déploiement continu... Que se passe-t-il en cas de problème ?
L'auteur présente Open Source Vulnerability Detector aka osv-detector qui permet de détecter les vulnérabilités des dépendances de tous types de projet (utilisation de npm, de composer, etc.) Il a même créé une image docker pour l'utilisation dans une CI
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Mise en place de l'intégration continue avec GitLab CI
Tout est dans le titre