hubshop-env

Healy vend dans des marchés qui n'ont presque rien en commun côté opérations — l'UE, les États-Unis, le Japon, la Corée, l'Inde, l'Australie, le Canada, le Mexique, la Colombie, la Thaïlande et le reste de l'Asie ont chacun leur boutique sur un cœur WooCommerce partagé. Le problème de l'équipe plateforme n'était pas de les construire. C'était de travailler dessus au quotidien.

L'ancien flux ne faisait tourner qu'une région à la fois. Changer voulait dire arrêter la stack, en démarrer une autre, et importer une base de données. Ça prenait quinze minutes, plusieurs fois par jour, chaque fois qu'un rapport de bug parlait d'un marché différent. Les hosts s'éditaient à la main, les certificats étaient propres à chaque développeur, et il n'y avait aucun moyen de lancer les tests.

hubshop-env est un fork du wp-env de WordPress, reconstruit pour que plusieurs régions tournent ensemble. Elles tournent toutes en même temps, donc changer, c'est juste changer d'URL, pas attendre. Le DNS passe en wildcard par dnsmasq et les certificats viennent de mkcert : une nouvelle région ne demande ni sudo ni approbation manuelle. L'installation est passée de vingt minutes à moins de dix.

Le reste, c'est ce qu'une équipe plateforme demande une fois que les bases ne posent plus problème : Xdebug et le profilage SPX derrière des flags, un conteneur de test dédié pour que PHPUnit ait un endroit où tourner, une commande `doctor` qui vérifie Docker, DNS, SSL et les conflits de ports au lieu de vous laisser deviner, une synchronisation qui permet de récupérer une base sans cinq gigaoctets de médias, la prise en charge des worktrees git pour faire tourner deux branches côte à côte, et un tunnel Cloudflare en une commande pour montrer son environnement local à quelqu'un sans compte ngrok.