{
  "data": [
    {
      "type": "blog",
      "id": "fr/blog/2024/symfony-and-doctrine-migrations-validation-in-ci",
      "url": "https://ktherage.github.io/fr/blog/2024/symfony-and-doctrine-migrations-validation-in-ci/",
      "attributes": {
        "alias": "/blog/symfony-and-doctrine-migrations-validation-in-ci/",
        "title": "Symfony & Doctrine Migrations : Validation en CI",
        "date": "2024-09-05T00:00:00+00:00",
        "description": "Comment détecter qu'un changement d'entité Doctrine est livré sans migration générée : un check CI simple qui échoue vite sur une incohérence schéma/mapping.",
        "cover": {"image":"img/birds-migration.jpg","alt":"Vol d'oiseaux formant un V en plein vol","caption":"Photo par <a href=\"https://www.pexels.com/@kai-filmer/\">Kai Filmer</a> sur <a href=\"https://www.pexels.com\">Pexels</a>"},
        "published": true,
        "tags": ["Symfony","Doctrine","Migrations","CI","DevOps"],
        "excerpt": "J'ai eu l'opportunité de travailler sur un projet avec une équipe relativement novice en matière de migrations Doctrine. Pour les aider à s'y habituer et écarter la possibilité d'avoir des pull (ou merge) requests avec des modifications d'entités Doctrine sans migration générée.\nVoici comment j'ai procédé. J'espère que cela vous plaira !",
        "body": "J&#039;ai eu l&#039;opportunité de travailler sur un projet avec une équipe relativement novice en matière de migrations Doctrine. Pour les aider à s&#039;y habituer et écarter la possibilité d&#039;avoir des pull (ou merge) requests avec des modifications d&#039;entités Doctrine sans migration générée.\n\nVoici comment j&#039;ai procédé. J&#039;espère que cela vous plaira !\n\n## Avertissement\n\nNous sommes le 10 juillet 2025 et cet article est obsolète en raison du merge de la Pull Request https://github.com/doctrine/migrations/issues/1406 ; désormais, l&#039;exécution de `bin/console doctrine:migrations:up-to-date` prend en compte la configuration `schema_filter`.\n\n## Comment fonctionnent les migrations Doctrine\n\nLors de la génération de la migration, Doctrine calcule un delta entre son mapping et le schéma actuel de la base de données. Avec ce delta en mémoire, il génère un **fichier de migration** avec deux méthodes principales :\n* `up` applique les commandes SQL pour combler l&#039;écart entre le schéma actuel de la base de données et son mapping. Utilisé pour déployer les modifications du schéma de votre base de données.\n* `down` permet d&#039;annuler la migration avec les commandes SQL nécessaires pour « annuler » les modifications effectuées dans la méthode up. Utilisé pour revenir en arrière sur les modifications du schéma de votre base de données.\n\n## L&#039;astuce magique\n\nIl n&#039;existe actuellement aucun moyen simple de vérifier si une migration n&#039;a pas été générée. Si ce code était fusionné, le schéma de la base de données pourrait ne plus être synchronisé avec le mapping des entités, entraînant ainsi une erreur serveur.\n\nLes mots-clés dans la description ci-dessus sont **fichiers de migration**. J&#039;utilise le fait que l&#039;exécution de la commande `bin/console doctrine:migration:diff` génère un nouveau fichier et échoue s&#039;il n&#039;y a aucun changement à appliquer.\n\nConnaître la liste des fichiers existants avant l&#039;exécution de cette commande, puis l&#039;exécuter, permet de détecter qu&#039;il y a des modifications qui n&#039;ont pas été commitées dans un **fichier de migration** dans cette pull (ou merge) request.\n\n## Étapes à suivre\n\n1. Créez votre base de données\n2. Exécutez vos migrations existantes\n3. Puis exécutez l&#039;étape de vérification des modifications manquantes (voir ci-dessous)\n\n## Avantages\n\n1. Tester que vos migrations ne échouent pas\n2. Assurer la cohérence du schéma de base de données avec le mapping de Doctrine\n\n## Vous voulez l&#039;extrait de code, n&#039;est-ce pas ?\n\nVoici le code bash :\n\n```bash\n#!/bin/bash\n\nset -e\nset -o pipefail\n\n# run doctrine migration diff to check if there is a new migration file generated and check last exit code\nif [[ -z $(bin/console doctrine:migrations:diff -n --quiet) ]]; then\n    echo &quot;Error ! bin/console doctrine:migration:diff found a new migration which must not be the case.&quot;;\n    # cat last file (should be the newly generated one)\n    cat $(ls -Art migrations/*.php | tail -n 1);\n    # remove that file (just in case to comply with my paranoïac side)\n    rm -f $(ls -Art migrations/*.php | tail -n 1);\n    exit 1;\nelse\n    exit 0;\nfi\n\n```\n\nEt voilà ! Vous pouvez désormais vous assurer que chaque pull (ou merge) request contient des migrations fonctionnelles, sans modification en attente laissée de côté !\n\n## Ok, mais pourquoi ne pas utiliser `bin/console doctrine:schema:validate` ?\n\nLa raison est que le projet sur lequel nous travaillions utilisait la configuration `schema_filter` de Doctrine pour filtrer certaines tables dont nous ne voulions pas nous occuper (contrainte liée au projet).\n\nLe problème avec `bin/console doctrine:schema:validate` est qu&#039;il ne prenait pas en compte cette configuration, et signalait donc des modifications (tentant de supprimer toutes les tables normalement filtrées) sans rapport avec ce que nous voulions.\n\nUn collègue m&#039;a dit qu&#039;il s&#039;agit d&#039;un problème connu qui pourrait être corrigé prochainement (https://github.com/doctrine/migrations/issues/1406).\n\nMerci d&#039;avoir lu cet article et n&#039;hésitez pas à laisser vos commentaires si vous avez des questions !"
      }
    },
    {
      "type": "blog",
      "id": "fr/blog/2024/bash-and-curl-simple-http-call-performance-testing",
      "url": "https://ktherage.github.io/fr/blog/2024/bash-and-curl-simple-http-call-performance-testing/",
      "attributes": {
        "alias": "/blog/bash-and-curl-simple-http-call-performance-testing/",
        "title": "Bash & Curl : Test de performance simple d'appels HTTP",
        "date": "2024-01-19T00:00:00+00:00",
        "description": "Une façon rapide et simple de tester les performances de vos appels HTTP.",
        "cover": {"image":"img/terminal-code.jpg","alt":"Texte de langage de programmation informatique","caption":"Photo par <a href=\"https://www.pexels.com/@nathan Dumlao/\">Nathan Dumlao</a> sur <a href=\"https://www.pexels.com\">Pexels</a>"},
        "published": true,
        "tags": ["Bash","Curl","Performance","Testing"],
        "excerpt": "Les appels HTTP sont essentiels au fonctionnement du Web et sont critiques pour tout projet de développement web. Vous vous êtes peut-être demandé comment visualiser rapidement les performances de vos appels HTTP. Je vais vous montrer comment j'ai fait simplement avec Curl.",
        "body": "Les appels HTTP sont essentiels au fonctionnement du Web et sont critiques pour tout projet de développement web. Vous vous êtes peut-être demandé comment visualiser rapidement les performances de vos appels HTTP. Je vais vous montrer comment j&#039;ai fait simplement avec Curl.\n\n**TL;DR :** Vous voulez juste le code (je comprends parfaitement 😉) ? Faites défiler jusqu&#039;à l&#039;extrait de code.\n\n# Quel était mon besoin concernant les appels HTTP ?\n\nJ&#039;avais besoin d&#039;avoir une idée rapide des performances du système de cache que j&#039;avais mis en place sur un point de terminaison HTTP, et je voulais que ce soit rapide et simple.\n\nAvec mes notions de Shell et ma connaissance de base de Curl (un petit cadeau d&#039;un collègue : vous trouverez une antisèche Curl ici), je savais que je pouvais facilement exécuter cent fois le même appel HTTP et obtenir le temps total en résultat.\n\nCette solution est une solution courte et simple qui correspond à mes besoins, à savoir tester localement mon point de terminaison HTTP.\nSi vous prévoyez de faire de véritables tests de performance/charge sur des serveurs réels comme la staging ou la production, alors jetez un œil à des outils comme [Apache JMeter](https://jmeter.apache.org/), [Gatling](https://gatling.io/), ou d&#039;autres outils similaires.\n\n# Comment Curl m&#039;a aidé à tester mon appel HTTP ?\n\nJ&#039;ai donc ouvert mon terminal et exécuté :\n\n```bash\nfor i in {1..100}; do curl &#039;https://some-domain/some-uri/some-path?cache=false&#039; \\\n-H &#039;cache-control: no-cache&#039; \\\n-H &#039;pragma: no-cache&#039; \\\n--compressed \\\n--insecure -s -o /dev/null -w &quot;%{time_total}s\\n&quot;;\ndone\n\n# Which printed :\n0.057703s\n0.067895s\n0.063033s\n0.062455s\n0.074864s\n...\n```\n\nPour quelques explications, j&#039;ai copié la requête envoyée par mon navigateur sous forme de requête Curl (cela se fait facilement sur la plupart des navigateurs, voir [ici](https://quickref.me/curl)) et je l&#039;ai encapsulée dans une boucle `for` qui exécute cet appel HTTP cent fois.\n\n**Le seul changement que j&#039;ai apporté à la requête Curl** a été d&#039;ajouter les options `-s` pour une sortie silencieuse, `-o /dev/null` pour éviter d&#039;afficher le corps de la réponse et, le plus important, `-w &quot;%{time_total}s\\n&quot;` qui permet de formater la sortie de Curl pour retourner le temps total. Vous pouvez trouver la liste complète des « Write out variables » disponibles [ici](https://everything.curl.dev/usingcurl/verbose/writeout.html#available-write-out-variables).\n\nEt voilà 🎉 ! **Vous pouvez avoir une idée rapide des performances uniquement avec les outils que vous utilisez peut-être déjà.**\n\nJ&#039;espère que cela vous sera utile !\n\nN&#039;hésitez pas à laisser vos commentaires ou questions ci-dessous."
      }
    }
  ]
}