Une vieille version de PHP est plus lente et, une fois sortie du support de sécurité, cesse de recevoir des correctifs pour des problèmes devenus publics. La montée de version est d'ordinaire indolore ; le risque vient de basculer sans vérifier, et la vérification prend dix minutes.

D'abord, savoir ce qui va casser

composer require --dev php-parallel-lint/php-parallel-lint
vendor/bin/parallel-lint --exclude vendor .

Cela analyse chaque fichier avec la version en cours et nomme tout ce qui ne compilera pas. Cela n'attrape pas les changements de comportement, mais bien ceux de syntaxe, qui sont l'essentiel.

Tester sur une copie

  1. Copier le site sur un sous-domaine de préproduction
  2. Basculer CELUI-LÀ sur la nouvelle version — Dans EGPNL, site par site.
  3. Activer les erreurs en préproduction seulement — display_errors là-bas, et jamais en production.
  4. Parcourir les chemins qui comptent — Se connecter, envoyer un formulaire, payer, lancer le script cron à la main.

Ce qui casse d'habitude

  • Une extension ou une bibliothèque abandonnée qui utilise quelque chose retiré depuis des années.
  • Passer null là où une chaîne est attendue - une dépréciation depuis 8.1 qui fait du bruit dans le journal plutôt qu'une erreur, mais beaucoup de bruit.
  • Une extension non installée pour la nouvelle version - chaque version a son propre jeu, et c'est la surprise la plus fréquente.
php -m   # under the new version, compare against the old

Revenir en arrière

Remettre la version dans le panneau est immédiat et ne change rien d'autre : le pire cas, c'est quelques minutes. C'est ce qui rend l'essai bon marché.

Regardez le journal après la bascule, pas seulement les pages. Une dépréciation écrit à chaque requête et peut remplir un disque en une journée alors que rien n'a l'air cassé.
Avancez d'une version à la fois. De 7.4 à 8.3 d'un seul bond, vous recevez tous les changements en même temps, sans moyen de dire lequel a cassé quoi.