Voici comment j'ai procédé. J'espère que cela vous plaira !

Avertissement

Nous 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'exécution de bin/console doctrine:migrations:up-to-date prend en compte la configuration schema_filter.

Comment fonctionnent les migrations Doctrine

Lors 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 :

• up applique les commandes SQL pour combler l'é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.
• down permet d'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.

L'astuce magique

Il n'existe actuellement aucun moyen simple de vérifier si une migration n'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.

Les mots-clés dans la description ci-dessus sont fichiers de migration. J'utilise le fait que l'exécution de la commande bin/console doctrine:migration:diff génère un nouveau fichier et échoue s'il n'y a aucun changement à appliquer.

Connaître la liste des fichiers existants avant l'exécution de cette commande, puis l'exécuter, permet de détecter qu'il y a des modifications qui n'ont pas été commitées dans un fichier de migration dans cette pull (ou merge) request.

Étapes à suivre

1. Créez votre base de données
2. Exécutez vos migrations existantes
3. Puis exécutez l'étape de vérification des modifications manquantes (voir ci-dessous)

Avantages

1. Tester que vos migrations ne échouent pas
2. Assurer la cohérence du schéma de base de données avec le mapping de Doctrine

Vous voulez l'extrait de code, n'est-ce pas ?

Voici le code bash :

#!/bin/bash

set -e
set -o pipefail

# run doctrine migration diff to check if there is a new migration file generated and check last exit code
if [[ -z $(bin/console doctrine:migrations:diff -n --quiet) ]]; then
    echo "Error ! bin/console doctrine:migration:diff found a new migration which must not be the case.";
    # cat last file (should be the newly generated one)
    cat $(ls -Art migrations/*.php | tail -n 1);
    # remove that file (just in case to comply with my paranoïac side)
    rm -f $(ls -Art migrations/*.php | tail -n 1);
    exit 1;
else
    exit 0;
fi

Et 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é !

Ok, mais pourquoi ne pas utiliser bin/console doctrine:schema:validate ?

La 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).

Le problème avec bin/console doctrine:schema:validate est qu'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.

Un collègue m'a dit qu'il s'agit d'un problème connu qui pourrait être corrigé prochainement (https://github.com/doctrine/migrations/issues/1406).

Merci d'avoir lu cet article et n'hésitez pas à laisser vos commentaires si vous avez des questions !

TL;DR : Vous voulez juste le code (je comprends parfaitement 😉) ? Faites défiler jusqu'à l'extrait de code.

Quel était mon besoin concernant les appels HTTP ?

J'avais besoin d'avoir une idée rapide des performances du système de cache que j'avais mis en place sur un point de terminaison HTTP, et je voulais que ce soit rapide et simple.

Avec mes notions de Shell et ma connaissance de base de Curl (un petit cadeau d'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.

Cette solution est une solution courte et simple qui correspond à mes besoins, à savoir tester localement mon point de terminaison HTTP. Si 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, Gatling, ou d'autres outils similaires.

Comment Curl m'a aidé à tester mon appel HTTP ?

J'ai donc ouvert mon terminal et exécuté :

for i in {1..100}; do curl 'https://some-domain/some-uri/some-path?cache=false' \
-H 'cache-control: no-cache' \
-H 'pragma: no-cache' \
--compressed \
--insecure -s -o /dev/null -w "%{time_total}s\n";
done

# Which printed :
0.057703s
0.067895s
0.063033s
0.062455s
0.074864s
...

Pour quelques explications, j'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) et je l'ai encapsulée dans une boucle for qui exécute cet appel HTTP cent fois.

Le seul changement que j'ai apporté à la requête Curl a été d'ajouter les options -s pour une sortie silencieuse, -o /dev/null pour éviter d'afficher le corps de la réponse et, le plus important, -w "%{time_total}s\n" 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.

Et voilà 🎉 ! Vous pouvez avoir une idée rapide des performances uniquement avec les outils que vous utilisez peut-être déjà.

J'espère que cela vous sera utile !

N'hésitez pas à laisser vos commentaires ou questions ci-dessous.