Comment mettre en place un environnement de développement multi-projets efficace, à la fois accessible par le client, par les développeurs, par les systèmes d’intégrations continues et qui soit le plus robuste et rapide possible ?!
Première solution
Mettre en place un serveur de développement, avec tout le nécessaire (php, apache, mysql, etc …)
Créer une vhost qui gère tout le sous-domaine <projet>.dev.domain.tld et qui les rediriges dans un dossier « /home/public/projects/<project>/web » afin qu’il soit accessible de l’extérieur.
Ajouter un hook à vôtre VCS (Git, svn, etc ..) pour qu’il met à jour ce dossier à chaque commit, et fasse tourner votre système d’intégration continue.
Et pour les développeurs :
Mettre en place sur votre serveur de DNS local un domain du type <user>.<projet>.dev.
Créer une vhost qui gère tout le domain *.*.dev et qui redirige dans un dossier « /home/<user>/projetcs/<projet>/web.
Bon très bien ont répond déjà à la première question, qui est d’avoir un système accessible par le client « <projet>.dev.domain.tld », par les développeurs en local « <user>.<projet>.dev » et qui puisse êtres placé en intégration continue.
Oui mais !
Pour une raison Z ou Y, je dois travailler de chez moi, ou en direct chez le client que faire ?
VPN ? NFS ? Oui en effet si vous travaillez dans un éditeur type VIM, SublimeText (et encore) ça ne posera aucun souci, cependant je vous laisse tenter avec un IDE type Phpstorm, Netbeans, Eclipse qui lui, va indexer tous les fichiers de votre projet …
Si de plus ce serveur de dev est souvent chargé, que vous n’avez plus de connexion internet, ou un débit très bas, le NFS va vous poser de gros souci en terme de rapidité, pour en plus subir les freezes de l’IDE à chaque CTRL+s !
Je pourrais encore énumérer des dizaines de cas qui rendes cette solution peu efficace.
La solution avec deux grand V et un P
Vagrant, Virtualbox, Puppet !
Pour éviter tous ces petits souci, nous pouvons partir du principe que chaque développeur travail sur un PC/Mac/Chaise (ah bon ?), et que vous utilisez un VCS (git, svn, etc ..), l’idée est donc d’utiliser les ressources locales, plutôt que de centraliser tout sur une seule et même machine (le serveur de dev) toute en gardant une configuration (machine, soft, etc ) identique pour tout le monde.
Et pour ce faire Vagrant a spécialement été conçu pour ca
Pour résumer étape par étape :
- Je récupère en local sur mon poste le contenu du repository (qui contient au préalable en plus du projet, la configuration Vagrant).
- Je lance la commande vagrant up
- J’ouvre mon navigateur sur l’ip ou l’host configuré dans Vagrant
- Je code !
- J’ai fini !
- Je lance la commande vagrant halt
Pas de NFS, pas de VPN, et même plus besoin de connexion internet à ce stade !
Mais qu’es donc que ce biniou ?!
Pour résumer Vagrant va créer une VM appeler Box (ubuntu, debian …) dans virtualbox, lancer toutes les commandes préalablement configurés dans un système de provisionning (Puppet, Chef, Fabric, …) , nécessaires pour installer et tester, tout ce qu’il faut sur la VM (apache, php, mysql, memcache, nodejs, …).
Lancer des commandes spécifiques à votre projet automatiquement (création base de donnée, fixtures, clear du cache, …).
Vous vous retrouvez donc avec un serveur de développement prêt à l’emploi pour votre projet, sur votre poste en local et versionné avec vôtre VCS.
Votre éditeur passe directement par les fichiers de vôtre super méga rapide SSD, et enfin chaque modification faite par un développeur dans la configuration de Vagrant (ajout d’un soft, mise à jour, …) sera directement prise en compte quand vous ferez un up de vôtre repository et un reload de vagrant.
Voilà pour la solution miracle qui résout beaucoup de problèmes !
Je ferai prochainement un article sur la mise en place de Vagrant pour un projet Symfony2