Discussion :

[BugsByte]

Bonjour,

Jusqu'à aujourd'hui, je développais mes applications PHP/MySQL directement sur mon serveur de production : FTP pour récupérer et déposer les fichiers et phpMyAdmin sur le serveur de production pour accéder à la base de données.

Aujourd'hui, je voudrais revoir l'ensemble de mon environnement de développement pour que ce soit un peu plus pro.
D'autant plus que je ne serais bientôt plus tout seul pour développer mes projets.

J'ai donc besoin de conseil d'experts en la matière pour m'aider à faire mes choix et les mettre en place.

J'ai pensé à utiliser Subversion comme système de contrôle des versions.
Et un serveur de tests ne serez pas non plus superflu.

Qu'en pensez-vous ?
Avez-vous des conseils à me donner ?

[Borus]

Bah y a pas grand grand chose à en dire. Ca dépend de tes besoins. Un Subversion par exemple, ca peut être intéressant, mais il faut voir si vous êtes 2 si vous en avez vraiment besoin.
De même, un serveur complet dédié aux tests me semble un poil exagéré mais encore une fois ca dépend de la charge que dois supporter le serveur,...

[BugsByte]

En fait, on va être à peu près 5 à développer sur le même projet.
Donc Subversion sera indispensable je pense.

Et quand je parle de serveur de tests, je voulais dire un serveur accessible que par les développeurs pour tester leurs scripts et l'application en entier avant de la mettre sur le serveur de production.
Ca permettra de déboguer sans se soucier des warnings que pourraient voir les internautes.

[Dia_FR]

l'idéal est d'avoir 2 serveurs identiques (versions de apache, php, mysql...) pour être sûr des tests réalisés

pour Subversion, c'est indispensable pour un travail collaboratif et cela permet de faire des saves (les devs ont une copie du projet sur leur PC, y en a une sur le serveur de dev et met le serveur svn sur le serveur de prod par exemple)

ensuite pour le déploiement, j'utilise rsync qui synchronise les dossiers entre le repository svn et le serveur de prod

[BugsByte]

Merci du conseil Dia_FR.
Et tu as raison : c'est un serveur de dév que je souhaite mettre en place et non pas un serveur de tests.

On va changer de serveur de prod prochainement, mais pas tout de suite : on va attendre que le nouveau projet soit un peu plus avancé avant d'investir dans trop de matos.
Je préfère donc installer SVN sur le serveur de dev si tu n'y vois pas d'inconvénient.
Ca nous permettra de bosser tranquillement en attendant la mise en production.

Je vais donc préparer mon serveur de dév aujourd'hui :
Linux Debian etch, Apache/2.2.3, PHP/5.2.0-8, MySQL/5.0.32, SVN/1.4.2.
Ce sont les dernières versions stables que l'on trouve dans les paquets Debian etch.
C'est bien comme environnement, non ?

Je pense donner le choix, aux développeurs, de leur système d'exploitation (mac, linux, win).
Comme cela, ils pourront installer leurs logiciels favoris et ainsi développer plus rapidement.
Est-ce que cela peut poser problème ?
Il suffit juste de vérifier l'encodage des fichiers pour que ce soit pareil de partout, non ?

J'ai bien compris que les développeurs récupéreront une copie du projet via Subversion et le modifieront en local avant publication, sur le serveur de dev, via Subversion également.
Ce que je n'ai pas compris c'est s'ils doivent avoir ou non eux-aussi apache, mysql, php sur leur poste ? Ou alors utilisent t-ils le serveur de dev pour tester leurs scripts.
Je pense qu'il est préférable qu'ils aient eux-aussi un environnement serveur pour éviter qu'un des développeurs publient sur le serveur de dev des erreurs bloquant les autres développeurs, non ?

Bon, je commence l'installe de mon serveur de dév et je reviens vous voir pour la suite.
J'ai encore pleins de questions.
Et faut également que je regarde de plus prêt rsync que je ne connaît pas du tout.

[Dia_FR]

C'est bien comme environnement, non ?

oui

Est-ce que cela peut poser problème ?
Il suffit juste de vérifier l'encodage des fichiers pour que ce soit pareil de partout, non ?

aucune idée, je n'ai jamais été confronté à ce problème
par contre ce qui est sûr c'est que des développeurs travaillant sur un même projet doivent utiliser le même charset
ce que nous faisons chez nous : on code tous avec php eclipse en UTF-8
à chaque fois que tu crées un projet, clic droit properties, encoding -> UTF-8
ça crée un dossier .settings que tu commites sur svn
comme ça, quand un autre dev fait un checkout du projet, il récupère aussi le .settings qui lui force l'encodage à UTF-8 et ça évite les problèmes
je sais pas si c'était très clair

Ce que je n'ai pas compris c'est s'ils doivent avoir ou non eux-aussi apache, mysql, php sur leur poste ? Ou alors utilisent t-ils le serveur de dev pour tester leurs scripts.

un serveur de dev porte bien son nom
tu développes dessus, pas d'environnement sur les postes des développeurs
si tu installes apache and co. pour chaque développeur, ce n'est plus un serveur dev mais de test

Je pense qu'il est préférable qu'ils aient eux-aussi un environnement serveur pour éviter qu'un des développeurs publient sur le serveur de dev des erreurs bloquant les autres développeurs, non ?

ma philosophie est que tu peux être prêt à perdre tout le contenu de ton serveur de dev d'un moment à l'autre (d'où le serveur svn sur le serveur de prod)
donc une boucle infinie... y a le timeout

bon courage

[BugsByte]

Encore merci à toi Dia_FR.

J'ai bien compris le problème du charset.
Je ferrais en sorte que l'on utilise tous l'UTF-8 comme encodage de fichiers.

Je comprends mieux également le but d'un serveur de dév.
Mais comment résouds-tu le problème suivant :

Imaginons qu'il y a 2 développeurs, Dev1 et Dev2.
Dev1 s'occupe de la maintenance du projet en production. Chaque jour, il modifie des fichiers, les teste sur le serveur de dev et les publie sur le serveur de prod.
Dev2, lui est en train de développer une nouvelle fonctionnalité sur ce même projet. Il en a pour plusieurs semaines de développement. Il utilise lui aussi le serveur de dev pour tester au fur et à mesure son code.

Comment Dev1 peut continuer à publier ces modifications journalières alors que Web2 et en train d'ajouter des fichiers qu'ils ne doivent pas être publié ?

[Dia_FR]

je vois que tu as déjà pas mal réfléchi à la problématique de ce que tu veux faire et de quoi mettre en place, c'est bien

et c'est une bonne question mais je me laisserai pas avoir comme ça

réponse :

dans subversion, tu peux créer l'arborescence que tu veux
mais très souvent, un projet dans subversion respecte cette organisation :
/trunk : branche principale celle qui sera envoyée en prod avec rsync
/tags : généralement pour stocker des versions (1.0 ; 1.1 ; ...)
/branches : différentes branches de développement

ton dev1 qui fait la maintenance travaille sur trunk
ton dev2 qui code une nouvelle fonctionnalité travaille sur un dossier dans branches

quand dev2 veut mettre à jour sa version avec les modifs dev1, il fait un compare entre trunk et sa branche (subclipse gère ça très bien) et il récupère toutes les modifs

attention, ici, on parle bien d'une maintenance (bugs) en parallèle avec une nouvelle fonctionnalité
si les 2 devs modifient en profondeur les mêmes fichiers l'un pour corriger et l'autre, je sais pas... pour changer la tête du code disons, ce fonctionnement sera impossible à gérer


edit :
rapide utilisation de rsync (blog d'un collègue) : http://www.blog.fbollon.net/archives/16
intro à svn : http://dev.nozav.org/intro_svn.html

[BugsByte]

C'est vraiment génial qu'il y ai des personnes pros comme toi pour conseiller ceux comme moi.
Et les liens que tu donnes sont vraiment très bien.
Ca faisait plusieurs années que j'avais abondonné la recherche d'aides via forum : A chaque fois je tombais sur des types qui répondait n'importe quoi ou complétement "à coté de la plaque".
Je suis vraiment content de ce forum très pro.
Mais revenons à nos moutons...

Je ne savais pas que Subversion permettait de faire tout ça.
Me voilà maintenant plus renseigné.

Rsync aussi est un outil très pratique.
Ca m'a donné des idées pour d'autres choses encore.

L'installation de mon serveur de développement est quasi-terminé.
Je vais voir maintenant pour l'installation et la configuration de Subversion et Rsync.

Sinon, désolé de ne pas être très réactif en ce moment : je suis en plein déménagement et je n'ai pas encore internet dans mon nouvel appart.

[Dia_FR]

de rien pour l'aide

moi je viens de commencer 2 semaines de congés

bon courage

[BugsByte]

Mon serveur de développement est enfin prêt.

Il ne me reste plus qu'à résoudre un petit truc :
Comment faire pour publier automatiquement le contenu du dépôt sur le serveur web de développement ?
Il ne faut quand même pas faire un "svn checkout" puis des "svn update" sur le serveur de développement après chaque "svn update" des développeurs ?

Merci d'avance à tous ceux qui éclaireront ma lanterne.

[Dia_FR]

quand l'interaction "svn-rsync-appli en prod" est ok, c'est à chaque développeur de mettre en prod quand i lfait une modif

il travaille, il teste, quand c'estbon, il commit puis il déploie

[BugsByte]

J'ai du mal me faire comprendre.

Ce que je demande, c'est comment les développeurs peuvent tester, sur le serveur de développement, leurs modifications.
La trame est la suivante :
1) Les développeurs récupérent les dernières sources du dépôt (svn update)
1) Ils modifient les fichiers en local (IDE)
2) Ils les envoient dans le dépôt (svn commit)
3) Ils testent leurs modifications (???)

J'ai suivi tes conseils : les développeurs non pas d'environnement web (apache, php, mysql, ...) sur leur poste, ils utilisent le serveur de dév à la place .
Alors comment mettre à jour les fichiers sources du DocumentRoot d'Apache par rapport à ceux du dépôt, pour que les dév puissent tester leurs modifs ?
Est-ce que cette étape est manuelle ou automatisée ?

Je vois bien une solution :
Dans le DocumentRoot, faire un svn update manuellement ou éventuellement appeler cette commande régulièrement grâce à un cron.
Mais cette solution ne me plaît pas du tout.

Je cherche une solution où le dépôt et le DocumentRoot seraient synchronisés.
Peut-être m'as-tu déjà donné cette explication, mais alors j'ai du passé à côté ou ne pas comprendre et j'ai beau relire tous tes messages, je ne vois rien de telle.

Merci d'avance de m'éclairer.

[Dia_FR]

les développeurs développent et testent sur le serveur de dév, il est là pour ça
ils ont chacun un dossier sur le serveur

quand ils ont bien testé leurs modifs en dev, ils commit puis déploient
le code commité est du code testé

[BugsByte]

Ok c'est très clair maintenant.

Je pense que j'ai appris tout ce que je souhaitais savoir.
Je suis fin prêt à accueillir mon équipe de développeurs.

Encore merci pour toute ton aide Dia.