Votre environnement de dev et Vagrant

[Akira777]

Salut !

Petite curiosité que je me posais : comment gérez vous votre environnement de dev web ?
Est-ce que vous utilisez des outils tel que wampserver, xampp, mamp, easy php ou des environnement virtualisés tel que Vagrant ou Docker ?

Historiquement, j'ai toujours travaillé avec wampserver (à la belle époque de Windows) et MAMP Pro depuis quelques années.
Depuis quelques mois je migre petit à petit vers Vagrant et les boxes "homestead" (pour nginx + php7 + hhvm), "scotch" (pour apache + php5.6 + nodejs + ruby) et "vaprobash" (pour quand je veux plus de souplesse pour mon code un peu plus vieux).
Je fais aussi du Docker, mais plus pour préparer des environnements de prod (pour l'hébergement en IaaS ou PaaS).

Pour ceux qui ne connaissent pas, Vagrant permet (entre autre) de configurer des machines virtuelles prêtes à l'emploi pour un environnement de dev. Ca permet d'être logiciellement au plus proche de ce qu'on retrouvera sur un environnement de prod et d'avoir toute la souplesse que l'on souhaite sur les extensions, les logiciels, ... Adieu WAMP et compagnie...

Si vous utilisez cet environnement, avez-vous des trucs & astuces ou des retours sur expérience à faire partager ?

Quelques liens :
- Vagrant (le site officiel de Vagrant)
- Pour ceux qui ne connaissent pas, un tuto vidéo en français
- La box "scotch", la box "homestead" (par Laravel) et "vaprobash".
- Docker, pour ceux que ça intéresse, c'est aussi fabuleux

[Xenos]

Salut!

Bonne idée de faire partager ces infos

Pour ma part, j'ai toujours utilisé une stack "prête à l'emploi" pour PHP/MySQL. Au départ, c'était EasyPHP car il s'agissait de la stack utilisée dans le bouquin papier d'initiation à PHP que j'avais.
Ensuite, l'année dernière, je suis passé sur WAMP à cause du taff. J'ai bien aimé le concept d'avoir des versions différentes de PHP/MySQL en parallèle (elles ne tournent pas en même temps, mais on peut switcher). En pratique, ça sert juste à rien...!
Enfin, ces derniers mois, je suis passé sur XAMPP car WAMP (ou moi? je sais pas trop) avait fichu le bazar dans les fichiers MySQL et après 3 remise à zéro de la BDD, je me suis lassé... XAMPP est plutôt bien fichu, assez modulaire et a maintenant ma préférence.


Perso, les machines virtuelles, bof bof... Je trouve que NetBeans (que j'utilise depuis 1 an et quelques) est déjà bien assez lourd comme cela, et switcher entre des machines virtuelles, c'est pas mon truc. Pour un dev, ça me semble pas nécessaire (le seul intérêt est d'avoir une configuration type à appliquer à tout le monde, mais comme la plupart des projets d'ici sont solo...). Pour l'admin système, c'est plus pratique, c'est sûr ^^
Si j'ai bien compris, l'intérêt des machines virtuelles est surtout de standardiser l'environnement de dev. En ce cas, je préfère ne pas le standardiser (aka, que chaque dev ait son environnement car il est censé le maîtriser), ça permet de le prendre en main et de le personnaliser sans soucis (d'un dev à l'autre, comme chacun bosse différemment et souvent, sur des éléments un peu différent, chacun a une méthode et des besoins un peu différents).

[Akira777]

Salut!

Bonne idée de faire partager ces infos

Pour ma part, j'ai toujours utilisé une stack "prête à l'emploi" pour PHP/MySQL. Au départ, c'était EasyPHP car il s'agissait de la stack utilisée dans le bouquin papier d'initiation à PHP que j'avais.
Ensuite, l'année dernière, je suis passé sur WAMP à cause du taff. J'ai bien aimé le concept d'avoir des versions différentes de PHP/MySQL en parallèle (elles ne tournent pas en même temps, mais on peut switcher). En pratique, ça sert juste à rien...!
Enfin, ces derniers mois, je suis passé sur XAMPP car WAMP (ou moi? je sais pas trop) avait fichu le bazar dans les fichiers MySQL et après 3 remise à zéro de la BDD, je me suis lassé... XAMPP est plutôt bien fichu, assez modulaire et a maintenant ma préférence.


Perso, les machines virtuelles, bof bof... Je trouve que NetBeans (que j'utilise depuis 1 an et quelques) est déjà bien assez lourd comme cela, et switcher entre des machines virtuelles, c'est pas mon truc. Pour un dev, ça me semble pas nécessaire (le seul intérêt est d'avoir une configuration type à appliquer à tout le monde, mais comme la plupart des projets d'ici sont solo...). Pour l'admin système, c'est plus pratique, c'est sûr ^^
Si j'ai bien compris, l'intérêt des machines virtuelles est surtout de standardiser l'environnement de dev. En ce cas, je préfère ne pas le standardiser (aka, que chaque dev ait son environnement car il est censé le maîtriser), ça permet de le prendre en main et de le personnaliser sans soucis (d'un dev à l'autre, comme chacun bosse différemment et souvent, sur des éléments un peu différent, chacun a une méthode et des besoins un peu différents).

Par rapport à ton retour sur les machines virtuelles :

L'interêt majeur selon moi c'est d'avoir au plus proche l'environnement de production et de ne pas être dépendant de mon poste de travail.
Grosso modo j'ai une machine virtuelle générale (que je lance comme je lancerai XAMPP le matin), avec des vhosts et tout ce qui va bien. Ensuite j'ai un postscript qui va hydrater toutes mes bases (à chaque fois que je relance la machine, je repars de zéro : logs, ...).

Pour les projets bien spécifiques, je commit mon fichier Vagrantfile dans le dépôt du site. Dans ce cas de figure, c'est une machine virtuelle dédiée au projet qui démarre (il faut quelques secondes pour la faire démarrer...) et elle a exactement la même configuration que l'environnement de prod (hormis l'affichage des erreurs et les options de sécurité). C'est trèèèès pratique quand on travail sur plusieurs machines. Les sources sont sous git et la BDD est gérée via des migrations.
Concrétement ça donne :

Code :

mkdir monprojet; cd monprojet
git clone {url_de_mon_projet} ./
vagrant up

Quelques secondes plus tard, j'ai plus qu'à me rendre sur monprojet.local et hop, je suis prêt à bosser

Ce qui est cool, c'est que je suis pas dépendant à travers les différents systèmes de mes besoins logiciels. Sur mon environnement de dev global j'ai vraiment tout : apache2, nginx, php, hhvm, mysql, postgre, ruby, node, rabbitmq, imagemagick, mongo, redis, ... et mes vhosts sont crées automatiquement (via le Vagrantfile).

Tout ça tient en un seul fichier texte. Quand un nouveau collaborateur arrive il a juste une commande à taper pour disposer des mêmes outils.
Quand moi je change de machine j'ai pas à me cogner d'avoir à tout réinstaller (hormis vagrant).

[niahoo]

Moi j'ai un laptop pour le dev, j'installe tout directement dessus. Là je suis sur linux mint mais je change souvent en fait. J'ai toutes mes sources via git ou dropbox donc quand je veux changer d'OS ça va vite pour réinstaller ou recompiler les différents outils.

[Xenos]

C'est vrai, si t'alterne entre les machines, cela peut être pratique. Vu que je n'ai que les miennes (PC maison, PC portable et encore...), j'ai pas trop ce soucis

Après, si t'as un nouveau collaborateur qui arrive, faut voir... Okay, cela permet d'installer tout boum d'un coup, mais cela l'obligera à se familiariser avec cette stack-là précisément (aka, le temps gagné à l'installation peut être perdu à l'apprentissage).
Perso, j'ai juste un dossier avec les installateurs nécessaires. Je trouve cela suffisant.

[Harparine]

Salut, très bonne idée de thread !
Après WAMP ou MAMP pendant des années, j'utilise maintenant Vagrant et je trouve ça absolument génial. Je n'y vois que des avantages :
- contrôle fin de la stack et possibilité de switcher entre des stacks différentes en 2min (sur WAMP, j'ai toujours galéré à faire cohabiter deux versions de PHP, il fallait relancer les serveurs 36 fois à chaque switch).
- pas de surprise, tout le monde à le même environnement de dev, et la prod est à l'identique du dev.
- en montant le dossier du site dans la machine virtuelle comme un disque périphérique, on peut bosser sur les fichiers depuis la machine hôte et les exécuter dans la machine virtuelle, donc chaque dev conserve l'environnement de travail qui lui plaît (on est trois dev sur un projet et on a tous des OS et IDE/éditeurs différents).
- on peut provisionner la VM avec un script de déploiement (j'utilise Ansible mais Puppet ou Chef fonctionnent aussi). Utiliser un Vagrantfile avec un OS nu + un script de provisionning est, selon moi, le combo ultime car ça permet de déployer l'environnement de prod avec le même script donc gros gain de temps et pas de surprise à la mise en prod. Vagrant permet même de simuler des serveurs en réseau local (comme le vRack d'OVH).
- on peut mettre en place des applications bien plus complexes qu'une simple pile LAMP en installant des exécutables qu'on peut tester. On peut aussi configurer finement le serveur web (j'utilise nginx) pour utiliser des trucs comme x-accel pour le téléchargement de fichiers (sur WAMP, la seule solution était de prier pour que tout fonctionne en prod et corriger rapidement si on faisait une connerie).

On versionne aussi l'infrastructure avec Git, donc l'intégration d'un nouveau dev sur le projet se fait en deux commandes.

Je n'ai pas testé Docker mais ça fait partie de mes objectifs "veille techno" de ces prochains mois

Xenos, Vagrant permet de standardiser ton serveur local, pas ton environnement de dev : le montage de répertoires dans la machine virtuelle permet d'avoir le beurre et l'argent du beurre : install est rapide tout en conservant tes habitudes.

++

[Xenos]

en montant le dossier du site dans la machine virtuelle comme un disque périphérique, on peut bosser sur les fichiers depuis la machine hôte et les exécuter dans la machine virtuelle

C'est bien comme solution ça
J'aime l'idée d'avoir la stack d'exécution (celle de pas prod) séparée de l'environnement de développement. Compris !


Mais bon, j'ai pas de besoin de switcher de version PHP/MySQL (c'est pour cela que cette fonction de WAMP, attrayante, s'est finalement avérée inutile ^^), vu que les mutualisés OVH sont assez contraints de ce point de vue-là (on ne la maîtrise pas, s'ils la changent, je subis). J'ai en fait remplacé Vagrant par une étape de "test sur le serveur de prod (pas à l'adresse de prod)", pour ne pas avoir de grosse surprise lors de déploiements finaux en prod (au sens d'erreurs de version/configuration d'environnement).

[rachids]

Hello !

Au commencement j'étais sur EasyPHP, je suivais le site du Zéro à l'époque où fallait nommer nos fichiers *.php3 et *.php4
Puis je suis passé sur Wamp que je trouvais plus stable.

Enfin, depuis que je me suis mis à Laravel, je suis passé sous Vagrant et Homestead et j'ai découvert à quel point ça pouvait être superbe d'avoir une vm (plus besoin de s'emmerder avec les PATH Windows pour les plugins exotiques par exemple).

Du coup j'ai envie d'apprendre le MEAN Stack avec une Docker et un bon bouquin dans les mois à venir