Assez fréquemment, je tombe sur un message dans /r/PHP qui pose une question. Je réponds à la question dans ma tête avant que les commentaires ne soient chargés. Le commentaire du haut contient généralement le même mot que celui que j'ai en tête : Docker.
La question la plus récente posée : comment exécuter plusieurs versions de PHP dans un projet ?
Docker était le commentaire le plus voté. Les alternatives allaient de l'installation locale de toutes les versions à Laravel Herd, Laragon, des scripts bash personnalisés et des configurations de serveur Web.
Aucune de ces alternatives ne me plaît personnellement – mais je ne suis pas non plus ici pour vous dire que vous avez tort. Si votre configuration fonctionne, cela fonctionne.
Ces questions fréquentes m'ont amené à me demander si ce qui ressemble à une aversion pour Docker n'est en réalité qu'un manque de familiarité. Le récent tollé suscité par la suppression de Sail de Laravel a renforcé ce sentiment (Sail n'est pas beaucoup plus qu'un Dockerfile et un mince wrapper CLI autour deDocker composer). Si les gens étaient mécontents de perdre cela, peut-être que Docker lui-même n'est pas le problème - c'est juste que personne ne leur a montré ce qu'il y a derrière le rideau.
Alors permettez-moi d'expliquer pourquoi « Docker » est si souvent la réponse.
À l'époque où j'ai commencé ce travail, la seule option viable pour exécuter un projet localement était de tout installer localement. Il existait des outils comme WAMP et LAMP qui vous permettraient d'y parvenir la plupart du temps, mais si vous aviez besoin de plusieurs versions de PHP ou de MySQL, bonne chance à vous.
Si vous aviez un projet utilisant Apache, un projet utilisant NGINX, tous deux liés au port 80, vous devrez vous rappeler d'en désactiver un et d'activer l'autre.
Si votre projet comptait un type de travailleur ou de consommateur, vous devrez vous rappeler de le démarrer tous les matins et de rappeler à vos collègues que la raison pour laquelle « ça ne marche pas » est parce qu'ils ont oublié de faire de même.
L'intégration d'un nouveau développeur signifiait une journée complète (si vous aviez de la chance) à « suivre simplement le README » suivi de « oh ouais, vous devez aussi faire ceci, et ceci, et cela ».
Quand il s’agissait de travailler avec d’autres développeurs ? "Ça marche sur ma ma...
[Courte citation de 8% de l'article original]