Discussion :

[JerryOne3]

Bonjour à vous, amis de l'internet !

Je sollicite votre aide pour une question à propos de laquelle je ne suis pas certain de la marche à suivre.

Je souhaite installer un environnement de développement propice au travail en équipe, pour un site de vente en ligne.

Il faut donc que chacun des développeurs ait son propre environnement de développement, puis qu'il puisse commit ses changements quand il en est satisfait. Aussi, j'ai imaginé procéder comme suit pour créer un environnement de dev personnel pour chacun :

- Installer un serveur PHP avec MySQL en local, type WAMP.
- Dump la BDD sur le serveur MySQL local.
- Copier les fichiers du FTP en local dans l'arborescence de WAMP.
- Modifier le fichier hosts du PC pour lui rediriger adresse_du_site.com en localhost
- Installer Git sur le serveur
- Installer un client Git sur le PC et le connecter au dossier où se situent les fichiers du site.

Ainsi, le dev peut coder comme il veut sur son PC, puis commit via Git quand il est satisfait.

Cela vous semble t-il plausible ? Auriez-vous des recommandations pour moi ?

Merci d'avance pour votre aide !

[jabbounet]

Le plus simple est probablement de discuter avec l'équipe de dev pour voire avec eux ce qui serait le plus efficace.


À défaut en discuter avec une personne qui fait référence dans l'équipe.

En général plus c'est facile a mettre en place, mieux cela passe au niveau des équipes.

[JerryOne3]

Hello,

en réalité, l'équipe n'est pas vraiment formée encore. Je pose les bases pour que ça se passe du mieux possible ensuite. D'où mes questions. Il faut que ça soit le plus simple possible à mettre en place par la suite et le moins contraignant possible aussi.

[tdutrion]

Bonjour,

Pour moi, il est très important que le système et les versions du serveur. Il faut absolument la même chose pour les serveurs de développement, intégration, test et production. C'est vital car on trouve des différences liées aux systèmes (insensibilité à la casse pour Windows vs sensibilité à la casse pour Linux).

Personnellement, j'aime bien ne pas avoir à m'occuper de mon environnement, donc si tu as un admin system suffisamment bon et que tu as les serveurs qui vont avec, il faut mettre un serveur pour la prod et éventuellement le testing (accès client sécurisé pour validation), et un autre serveur, interne uniquement, pour les autres plateformes. Ensuite tu attribues un espace à chacun avec une copie du projet, et tu fais exactement comme tu avais décrit.

[JerryOne3]

Bonsoir,

effectivement, j'avais pensé à ça aussi... Mais ça demande alors de :

- Faire un commit à chaque modification aussi minime soit-elle de ton fichier : chiant !
- Avoir un sous domaine par développeur ?!?!

Alors que si chacun est en local, c'est peut-être source de bugs, mais plus simple et de toute façon il re-teste une fois le commit fait ?

[tdutrion]

Pour la mise à jour des environnements de dev, je ne pensais pas à des commits sur Git mais à des synchonisations par FTP à l'aide de l'IDE (pour ce que j'en sais, ça existe dans Netbeans, Eclipse et Zend Studio).

Pour le sous domaine par développeur, c'est un peu le problème en effet, à moins d'être à même de faire des vhosts basés sur l'adresse en mettant en place une adresse côté serveur par développeur...

Sinon tu as l'idée de phpcloud ou Openshift, avec des systèmes de VM ou d'applications packagées.

Après ta première stratégie est bonne, mais il ne faut pas oublier lors d'un commit de tester en "intégration", c'est à dire une base propre où on teste si les morceaux ajoutés fonctionnent.

[JerryOne3]

Merci pour toutes ces précisions

Je vais passer sur les possibilités de virtualisation serveur, j'ai jamais été un grand fan, ça amène trop d'emm...nuis :/

En restant en dehors de ça donc, ça demanderait vraiment une sous domaine par dev, ce qui est plutôt lourd et contraignant... Et une branche Git par dev, sur laquelle il synchro ses changements et qui est merge ensuite vers la dev "principale", t'en penses quoi ?

Merci encore

[tdutrion]

Au niveau de l'utilisation de GIT je n'ai malheureusement qu'une seule experience, mais qui a fonctionné quand même.

Dans mon cas (deux développeurs), on créait une branche git par fonctionnalité, puis merge avec la branche dev, puis branche integration et enfin branche prod. Comme ça on déploie avec git directement en test, intégration et prod depuis leur branches dédiées.

[humitake]

Bonjour,

Je vais passer sur les possibilités de virtualisation serveur, j'ai jamais été un grand fan, ça amène trop d'emm...nuis :/

La virtualisation a bien évolué, aujourd'hui je trouve ça très stable voir plus intéressant qu'une multitude de serveur physique. Couplé à un NAS ou un SAS et c'est royal, si ton serveur physique tombe en panne il te suffit d'en démarer un autre et de redéployer tes VM dessus, temps de l'opération : 10 minutes maximum (en étant très méchant) si tu as un autre serveur (pas forcément identique) sous la main

L'avantage c'est également que tu garde ta configuration donc tu lance et sa marche.

[JerryOne3]

Okay pour adopter ça comme solution principale en fonction des besoins, mais pour ce qui est du dev en équipe, ça peut pas remplacer une solution comme Git, je pense, si ?

[tdutrion]

Les vm et tout c'est plus pour la partie environnement de développement, alors que GIT va servir pour la synchronisation des sources, ce qui sont deux choses différentes.

Du coup disons par exemple :

• un serveur local, avec des VM pour chaque développeur (même configuration que le serveur de prod), accessible depuis le poste de chaque développeur pour qu'il bosse directement dessus
• ces VM sont clonables pour ajouter un développeur quand on veut
• Une VM sur ce même serveur pour l'intégration (la mise en commun des codes de développeurs)
• Un serveur GIT, une branche par fonctionnalité, une branche par environnement de déploiement
• Un serveur pour la marche à blanc et pour la prod

L'avantage des VM ici : possibilité d'ajouter un développeur hyper rapidement, possibilité pour un développeur de bosser sur n'importe quel ordinateur (vnc ou autre accès distant sur sa VM).

[tdutrion]

J'oubliais aussi, un wiki complet et un bug tracker, à l'image de ce qui se fait sur Bitbucket ou Github.

Le wiki contiendra notamment les instructions pour cloner des VM, pour le style du code, les adresses de tous les serveurs, les versions des logiciels serveurs, l'architecture du projet...

Le tracker devra être à jour en permanence, sinon ça n'avancera pas.

[JerryOne3]

Salut salut !

Bon, après avoir été pris pendant un long moment, j'ai pu me replonger dedans. résultat, sous les conseils d'un gars qui s'y connaissait un peu, et le cassage de dents sur le bitume aidant, j'ai opté pour :
- Git installé sur le serveur d'intégration
- VM sous linux sur les machines de chaque dev, qui bosse ainsi en local
- Création de branches en local pour les développements à faire, quand le dev est fini merge avec master puis tests persos, et envoi ensuite sur origin/master (le serveur d'intégration) pour tests
- Si tout va bien, bascule en prod

Ma question maintenant est la suivante :
Y-a t-il un moyen de backup mon travail local ? Si je bosse longtemps sur un projet de longue haleine, j'ai pas envie de tout perdre si le PC crash ou si la VM me lâche... J'ai pensé à un autre repository ailleurs vers lequel je push toutes mes branches le soir... C'est faisable ? C'est une bonne idée ? Si oui, comment cloner le repos git de ma VM sur un serveur ?

[tdutrion]

Si tu peux, tu devrais t'intéresser à backup-manager ou un logiciel dans ce gout, et mettre en place une sauvegarde incrémentale sur chaque VM direction le serveur de sauvegarde.

Avec une sauvegarde master par semaine plus deux mineurs par jour (pause midi et soir) ou une le soir selon l'organisation, ça marcherait impecable