Ask DLFP : "Outil pour développer du PHP en groupe"

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
15
nov.
2002
PHP
Je connais (un peu) CVS et c'est visiblement très bien pour le développement en groupe d'application tournant en local. On peu en effet rapatrier tout le projet et le faire tourner tranquillement chez soit. Mais pour les applications serveur comment faire ?
CVS conserve les fichiers sous une forme qui lui est propre. Il est ainsi impossible par exemple de faire tourner directement sur le serveur des pages PHP qu'il gère.
Je pourrais rapatrier le PHP et le faire tourner en local mais ce n'est pas le but car il utilise une BD et des CGI qui ne sont que sur le serveur... Une idée ?

NdM: une idée : faire un cvs checkout sur le serveur, et un cvs update quotidien. Et vous, vous faites comment ?

  • # Re: Ask DLFP :

    Posté par  . Évalué à 3.

    subversion
    mod_cvs (un truc achement bien pour Apache)

    • [^] # Re: Ask DLFP :

      Posté par  . Évalué à 6.

      mod_cvs ? Et pourquoi pas du rsync pendant qu'on y est ?

      Non, sérieusement, pour le besoin du monsieur, il y a précisément WebDAV qui existe et qui a été conçu exactement pour ça.

      Encore un doute ? vite http://www.webdav.org/(...) !

      • [^] # Re: Ask DLFP :

        Posté par  . Évalué à 0.

        ou faut passer sous zope, qui supporte webdav ;)

        • [^] # Re: Ask DLFP :

          Posté par  (site web personnel) . Évalué à 2.

          Il le supporte comme un pied. On modifie pas les sources mais le résultats des sources ce qui entraine pleins d'erreurs

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Re: Ask DLFP :

    Posté par  . Évalué à 8.

    voyons ! c'est un probleme d'organisation du travail et non de softs !

    des qu'on est en groupe (et meme quand on est seul), il faut un serveur de production et un ou plusieurs serveurs de dev . Au besoin on duplique tout ou partie des bases de donnees.

    on ne met sur le premier serveur que des choses qui sont sures, verifiees et numerotees (taggees) et on travaille sur les autres serveurs.

    donc sur le serveur de prod on fait une installation par tarball ou par cvs checkout/update avec un tag

    sur les autres serveurs on fait un cvs checkout/update ou bien on travaille carrement en local c'est au choix

    • [^] # Re: Ask DLFP : séparation référence / production

      Posté par  (Mastodon) . Évalué à 1.

      Je suis d'accord avec toi et un peu surpris que la question se pose en ces termes.
      Il me semble évident que le contenu du référentiel CVS doit bien être considéré comme tel : un référentiel. En aucun cas il ne devrait être question d'executer ce qui s'y trouve. Par contre je comprends bien que pour plusieurs raisons (notamment budgétaire), une seule machine accueille les deux fonctions (CVS et serveur), surtout dans la phase de développement.
      Mais même dans ce cas, il est indispensable de conserver une séparation logique claire, et "dupliquer" le code : version CVS (au format propre) dans le référentiel et version executée par le serveur.
      Corollaire : il faut une opération spécifique pour mettre à jour la version serveur; soit automatiquement (bestial) comme suggéré ci dessous, soit manuelle lorsqu'elle est nécessaire.
      NB : la solution automatique ne me plaît pas trop, car que donne-t-elle quand des fichiers contenant du code inter-dépendant sont mis à jour avec un petit décalage ?

      • [^] # Re: Ask DLFP : séparation référence / production

        Posté par  . Évalué à 2.

        « Par contre je comprends bien que pour plusieurs raisons (notamment budgétaire), une seule machine accueille les deux fonctions (CVS et serveur), surtout dans la phase de développement. »

        Faire serveur CVS, ça n'implique pas grand chose, si c'est pour un projet uniquement. Il est donc parfaitement inutile de placer le CVS sur une autre machine que le serveur.

    • [^] # Re: organisation

      Posté par  (site web personnel) . Évalué à 0.

      Je suis 1/2 d'accord avec toi. En pratique nous avons un serveur en prod et un serveur en dev qui sont similaires (exactement la meme config et les memes softs). On fait bien les mises à jour qu'en version stable sur la prod.
      Ce qu'on veut c'est éviter que chaque poste de développeur ne devienne un serveur de dev (ou une image de ce dernier). On ne veut pas avoir besoin d'avoir sur les postes de dev : Apache (avec la bonne config) + les cgi (en bonne version) + un acces à la BD...

      • [^] # paresse

        Posté par  . Évalué à 0.

        Je vois pas le problème et je me demande pourquoi personne ne t'a demandé de RTFM (vu que tu connais seulement "un peu" CVS). C'est tout con, comme dans la note du modérateur : tu fais un checkout du repository dans le répertoire de prod, et tu updates ce répertoire quand tu considère que le repository est stable.

        Faire une news pour ça, ça me tue.

        • [^] # Re: paresse

          Posté par  (site web personnel) . Évalué à 1.

          bon...sans voulir insister mais le faisant probablement, effectivement, si pas de moyens, et que la base de donnée n'est pas répliquée pour le test.. yapas mieux que le "co" sur le serveur lui-même, qui, du coup, se prend pour son propre client cvs.

          Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie

  • # Re: Ask DLFP :

    Posté par  (site web personnel) . Évalué à 3.

    Il y moyen de declencher automatiquement un script après chaque commit (ce qui est utilisé pour envoyer un mail), non ?
    Il suffirait de lancer un update du serveur...

    • [^] # Re: Ask DLFP :

      Posté par  . Évalué à 1.

      Y'a un truc comme ça entre subversions.gnu.org et www.gnu.org

    • [^] # Re: Ask DLFP :

      Posté par  . Évalué à 1.

      Il y moyen de declencher automatiquement un script après chaque commit (ce qui est utilisé pour envoyer un mail), non ?

      Avec CVS oui, tu peux déclencher des scripts pour plusieurs choses, avant le commit pour faire des tests, après le commit pour informer par mail, et d'autre choses. Ca correspond à ce qu'on met dans les fichiers commitinfo, loginfo, editinfo, notify, taginfo, etc...

      Par exemple, pour mon projet dont je suis le responsable, j'ai la ligne suivante dans le loginfo :

      PosServer mail -s "CVS loginfo: %{s}" jeannet@truc.com

      le "%{s}" est remplacé par le nom du ou des fichiers "commités", et dans le corps du message il y a le message de modif mis par celui qui a fait le commit.

      Ceci dit, dans le sujet de la nouvelle, il n'est pas forcément nécessaire de mettre à jour le site Web tout de suite, parfois c'est seulement après plusieurs commit à des endroits différents de l'arborescence qu'on voudrait remettre le site à jour.

      Je préfère la méthode la plus souvent utilisée, celle qui est mentionnée par kesako.

      • [^] # Re: Ask DLFP :

        Posté par  (site web personnel) . Évalué à 2.

        J'ai vu passer récemment sur freshmeat quelque chose qui s'appelle cvs toys, qui vise à étendre ce méchanisme un peu simpliste. Typiquement, synchroniser une version en production avec la version CVS.
        Pour les curieux, ça se trouve là: http://twistedmatrix.com/users/acapnotic/wares/code/CVSToys/(...)

      • [^] # Re: Ask DLFP :

        Posté par  . Évalué à 1.

        Je pense qu'il est également possible d'utiliser le fichier taginfo à ces fins. En plus tu peux gérer plusieurs tags différents, du coup cela permet de pouvoir mettre à jour le site de test et celui de production. Il est possible de différencier les utilisateurs au niveau du script que tu exécutes, ce qui te permet de donner à certains le droit de tagger pour uploader sur le site de test, à d'autres le droit de tagger pour uploader sur le site de production.

  • # Re: Ask DLFP :

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Comme indiqué sur le Cederqvist (voir sur le site de cvs http://www.cvshome.org/(...) ) page 138, annexe C, paragraphe 7.2 "Keeping a checked out copy".
    Dans cet exemple, on utilise le fichier loginfo pour faire un cvs update sur le serveur à chaque commit. Ainsi, tu travailles sur ta copie e tu l'as fait tourner avec une BDD de test et les CGI qui vont bien et quand tu as fini et testé à fond ;-), tu commit et le site Web est automatiquement mis à jour. En règle générale avec un petit peu de code en shell, perl ou autre, tu peux réussir à faire faire à peu près ce que tu veux à CVS. Par contre, il faut lire tout le passage sur les fichiers d'admnistration mais ça se fait et c'est pas trop compliqué.

    PS: tu peux aussi taper info cvs pour avoir le Cederqvist directement sur ta bécane. Perso, je préfère la version PS.

    • [^] # Re:

      Posté par  (site web personnel) . Évalué à 1.

      Merci, j'ai appliqué cette méthode et ça à l'air de marcher impecable.

  • # Re: Ask DLFP :

    Posté par  . Évalué à 5.

    Il y a deux problèmes :

    1. Maintenir une version à jour du projet sur le serveur:

    Il est possible de faire exécuter un script à chaque commit, cela se configure dans CVSROOT/loginfo, il suffit donc d'écrire un petit script qui maintient une copie à jour. Il faut un peu ruser à cause du verrouillage des fichiers, en faisant par exemple 'touch /tmp/have-to-update.MON-PROJET' au moment du commit; puis un script qui tourne dans la crontab se charge toutes les 5 ou 10 minutes de faire la mise à jour si ce fichier existe. Il y a pleins d'autres méthodes.

    2. Utilisation de BD et de CGI qui ne sont que sur le serveur:

    Cela dépends de la façon dont fonctionne ton projet, mais le problème de la Bdd est très courant, par exemple :
    - Avoir un fichier de config listé dans .cvsignore où chacun place l'URL de sa propre base de donnée
    - Tout le monde utilise la base de données sur le serveur

    De toute façon les bases de données sont faites pour etre accédé à distance.

    Pour les CGI, je ne vois pas le problème, ils ne peuvent justement etre accédé que via HTTP, donc cela ne change rien quelque soit l'endroits d'où on fait les requetes.

  • # Re: Ask DLFP :

    Posté par  . Évalué à 1.

    Je comprend assez mal le problème.

    serveur popol avec = un cvsroot et une copie du cvs (que le serveur sert...)
    machine de robert = avec une copie du cvs

    robert : cvs ci -m 'ma mouise'
    robert : ssh root@popol
    robert : cd /var/www/copieducvs && cvs update -d

    C'est règlé !

    Si j'ai bien compris, le but est d'automatiser les deux étapes qui suivent ? Ce n'est peut-etre pas une bonne idée, il est dès fois interessant de faire un commit d'un truc encore expérimental, qu'on veut tester ailleurs, mais pas directement sur la copie du cvs en production./..

    • [^] # Re: Ask DLFP :

      Posté par  . Évalué à 1.

      Si tu commit un truc experimental sans faire de checkout, le prochain développeur qui fera un co sur le serveur de prod activera le truc experimental, sans vraiment le savoir...

      C'est vicieux, si le truc experimental est foireux, il va commencer par croire que ça vient de son propre code...

      • [^] # Re: Ask DLFP :

        Posté par  . Évalué à 1.

        C'estg pour qu'il y'est important de :
        - mettre un commentaire de ChangeLog explicite
        - faire un cvs update avant de faire un cvs ci (histoire de voir si des modifs ont été faites)
        - et éventuellement ne faire qu'un cvs update dans le dossier sur lequel on à modifié des fichiers.

    • [^] # Re: Ask DLFP :

      Posté par  . Évalué à 6.

      Je gere un projet dont l'objectif est de mettre en place un portail web. Comme on est plusieurs dessus et à des endroits differents (US,France), le CVS s'est avere fort pratique.
      On distingue plusieurs serveur web:
      - Production: Il ne se met a jour depuis le serveur CVS uniquement en manuel, sur la branche principale.
      - Test: Il se synchronise regulierement sur une branche appelee test. Quand la version en test est approuvée, je met a jour la branche principale par rapport aux modifications appliquees sur test (merge) et je synchronise la version en production.
      - Dev: Synchronisé toutes les 5 minutes sur une branche appelée devel. C'est ici que vont tous les commits des développeurs. Pareil, quand on a un truc pas trop mal, on applique les modifications apportées sur devel vers test.
      De plus chaque developpeur a sa copie chez lui et fait tourner un serveur local. Il fait son developement dans son coin, commit sur dev. Apres quand c'est pas mal on merge sur test et ainsi de suite.

      Ca permet d'avoir d'orienter les divers intervenants vers différents sites:
      - Le public sur le site en production
      - Les commanditaires sur le site de test
      - Les dévelopeurs sur le site de dévelopement.

      On n'utilise par contre pas CVS pour les Bases de données pour les raisons suivantes:
      - Les données dans les sites de dévelopements, de tests et en production doivent être compartimentées. On risquerai de se retrouver avec un message du type "machin est un con" sur le site de production.
      - Si des modifications structurelles sont apportées à la base, il faut plutôt prévoir un script pour la migration des données de l'ancienne formule vers la nouvelle.

      • [^] # Re: Ask DLFP :

        Posté par  . Évalué à 1.

        > On n'utilise par contre pas CVS pour les Bases de données pour les raisons suivantes
        La vraie bonne raison c'est que les donnees d'un site en production renferment des infos bien reelles sur les gens et que la loi vous oblige a les proteger. Les developpeur n'ont pas a les connaitre. Eux n'ont besoin que du format et de quelques exemples.

        Gare a vous si le dump d'une base de prod est utilisée en dev et par un jeu de copie et recopie au petit bonheur, cette base ou une partie de cette base se retrouve sur le net !!!

        • [^] # Re: Ask DLFP :

          Posté par  . Évalué à 1.

          La raison que je trouve la plus valable, c'est qu'une base de donnée ne se modifie pas comme des fichiers PHP... Et pour avoir un suivi à ce niveau, il suffit de faire des dumps.

          Par contre, il n'est pas idiot de faire des dumps de structure dans des fichiers sur le CVS.

  • # Re: Ask DLFP :

    Posté par  . Évalué à 0.

    TRES SIMPLE :

    Tu créee pour chaque développeur un public_html sur le serveur, et chacun bosse sur SES sources. tu commit ensuite dans le repository, quand tu as fini une de tes parties.

    Ensuite, tu peux exporter régulièrement dans un répertoire commun pour voir le résultat (pour validation d'une pers. non developpeur). Mais le résultat, tu le verra en méttant à jour tes sources régulièrement, avec les commit des autres

  • # Et les terminaux graphiques ?

    Posté par  . Évalué à -1.

    Il a été question dans les commentaires du cas particulier ou on a un serveur de prod et un serveur de dev, et plein de clients (ordinateurs) avec des devz. qui bossent comme des furieux mais qui sont des manches en admin. donc ils savent pas comment installer un apache, un *sql en local et encore moins les administrer ...
    Je vous propose donc deux astuces
    - transformez votre serveur de dev en "terveur de TX" et tout baigne, tous les dev. bossent sur le même serveur, je ne vois donc pas "ou" est le probleme
    - chaque développeur se fait un coup de ssh (éventuellement -X) vers le serveur de dev et il code avec son emacs/vim/ed/cat favoris sur le serveur de dev, tout simplement !

    Allez hop!
    Éric

    eric.linuxfr@sud-ouest.org

    • [^] # Re: Et les terminaux graphiques ?

      Posté par  (site web personnel) . Évalué à 1.

      - chaque développeur se fait un coup de ssh (éventuellement -X) vers le serveur de dev et il code avec son emacs/vim/ed/cat favoris sur le serveur de dev, tout simplement !

      Et tu fais comment si plusieurs développeurs bossent sur le même code au même instant !!! Tu n'as pas dû comprendre à quoi servent des outils tels que CVS qui permettent le travail collaboratif à plusieurs avec possibilités de lock de fichiers, de merge....

  • # Re: Ask DLFP :

    Posté par  (site web personnel) . Évalué à -1.

    Si j'ai bien compris tu cherche une alternative au CVS en php? Si c'est cela je suis en train de le dévelloper alors mail moi à:

    noplay@djeyl.net

    • [^] # Re: Ask DLFP :

      Posté par  (site web personnel) . Évalué à 0.

      Non tu n'as pas bien compris, il cherche comment utiliser des outils collaboratifs tels que CVS, pour développer un site Web dynamique en PHP avec base de données, le tout à plusieurs développeurs qui se répartissent le boulot (et accessoirement peuvent être amener à travailler sur le même code).

  • # Re: Ask DLFP :

    Posté par  . Évalué à 0.

    utilise Oracle Designer :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.