Modèle de développement - Page 1

Salut,

Une question pratique, avant de me lancer dans des scripts pas forcément pratiques je préfère avoir votre avis : je développe une application web. À l’installation l’utilisateur doit remplir un fichier de conf pour configurer l’accès à la bdd, et d’autres params.

Ma version de développement contient mon fichier de conf, avec mes params, mais quand je comitte mon travail je ne veux pas que ces params soient comittés, je veux que le fichier de conf du dépôt soit le modèle de config, vierge.

J’utilise subversion, est-ce qu’il est possible de lui préciser de ne jamais comitter certains fichiers ?
Sinon, quelles sont les solutions intelligentes que je peux employer ? J’écrirais bien un petit script qui copie ma version locale du fichier de conf ailleurs, fait un revert, puis le commit, puis restaure ma version locale du fichier, mais j’aimerais éviter ce genre de bricolage. Une idée ?

[edit] Au passage, une autre question du même genre : quand je fais une release, je modifie différents paramètres à différents endroits dans le code, pour passer du mode dev au mode production. J’aimerais, pareil, pouvoir automatiser cette tâche.

oui, avec tortoise SVN tu peux utiliser la liste ignore-on-commit, je sais pas comment c'est géré au niveau de svn "core".

en gros t'as un fichier versionné, mais au moment de faire commit, tu dis "jamais celui là".

pour le 2e point je sais pas trop.

Pour le premier point, tu peux ajouter une propriété "svn:ignore" sur le dossier qui contient ton fichier de configuration pour lui préciser de ne jamais le commit.

[edit] la commande doit être "svn propset svn:ignore fichier.conf dossier", ou pas loin ^^

Pour le deuxième, je sais pas.

pour la 2em question, j'aurais tendance à dire que normalement tu ne dois modifier qu'un seule paramètre : celui indiquant l'environnement : 'dev' ou 'prod', et tout le reste doit en découler automatiquement. car si tu as beaucoup de paramètres à modifier, il arrivera tjrs un moment ou tu en oubliera un. de même si à un moment tu as un nouveau paramètre différent en fonction de la dev et la prod, tu n'as qu'à faire un switch automatique en fonction de la variable d'environnement, tu n'as rien à modifier dans ton commit, ce qui est quand même bcp mieux...

Zephyr: tu peux faire un svn ignore sur un fichier géré dans le repository? sur un fichier qu'on veut pas *du tout* ok , mais la il veut le conserver dans le repo, sans les modifs ultérieures.

Ah pardon, j'ai mal lu. Je ne connais pas l'effet du svn:ignore sur un fichier déjà sous contrôle, mais c'est l'occasion d'essayer (ça me semblerait logique que ça ignore simplement les nouvelles versions, c'est à dire exactement ce qu'il cherche)

./3 Merci
./4 Je suis d’accord

Je crois que ca marche. Committe ton fichier puis fais un deuxième commit où tu le mets en ignore. En tout cas je sais que ca fout le bordel quand on veut pas du tout qu'il soit dans le svn.
Sinon regarde la propriété svn:needs-lock (svn help propset) et la commande lock (svn help lock). Comme en général quand on commit on ne lock jamais, ca évite de committer par inadvertance un fichier en needs-lock=true. Je crois l'avoir déjà utiliser parce que des collègues modifiaient systématiquement un fichier pour mettre des chemin de fichier sur leur machine.

Après pour la gestion des propriétés de déploiement, j'ai vu plusieurs solutions implémentées.

La première est d'avoir plusieurs répertoires conf (dev/conf, prod/conf, integration/conf, hudson/conf, etc....) dans lequel il y a des fichiers avec les propriétés de déploiement. Et suivant l'environement, un des répertoires est ajouté au classpath de build.
C'est assez simple, mais le war qui est buildé ne peut être déployé que dans un seul environement, et si tu veux changer une propriété de déploiement en prod, faut rebuilder le war...

Une deuxième solution que j'ai vu est de jouer avec l'override de web.xml: http://docs.codehaus.org/display/JETTY/override+web.xml . Dans le web.xml sont définis toutes les propriétés de déploiements en tant que context-param avec des valeurs par défaut. Ensuite à chaque développeur de maintenir son override-web.xml et les admins à maintenir leur override-web.xml dans l'environement de prod.
Le problème est que les propriétés faut aller les chercher dans le webapp context, ce qui peut être chi***. Et faire du xml plus ou moins abscons pour juste mettre prop=value, on fait rarement plus compliqué.... Et tu peux faire ca dans autre chose qu'un jetty (a priori).

La solution que je préfère est de jouer avec le classpath au runtime plutot qu'à la compilation: http://docs.codehaus.org/display/JETTY/Classloading#Classloading-UsingtheextraClasspath%28%29methodonWebAppContext Chaque développeur a un répertoire conf dans lequel il a son deploy.properties. En prod pareil, un répertoire conf où l'admin pose son deploy.properties.
Après si on déploie pas dans un jetty, un simple copy dans WEB-INF/classes fait l'affaire à chaque démarrage de l'appli web.
Autre truc aussi c'est d'avoir des valeurs par défaut. Les développeurs démarrent plusieurs fois par jour l'appli, donc les valeur par défaut sont faites pour eux.
Ca s'implemente très facilement avec un java.util.Properties, suffit de charger le defaut puis celui dans conf. Si tu utilises Spring, y'a le PropertyPlaceholderTrucChouette qui t'injecte ça dans ton context.
Et si tu mets un peu de commentaire dans celui par défaut, ca te fait direct la doc des propriétés de déploiement à refiler aux admins.

Merci pour ces idées (cependant je ne code pas en J2EE mais en PHP/Yii ou Java/Play!)

arf, j'suis vraiment intoxiqué java moi....

Et vous arrivez à faire des vraies applications en J2EE ? Parce que du peu que j’ai essayé c’est pas super bien fichu… Vous utilisez peut-être Spring ou Struts par-dessus, non ?

ca dépend. Pour faire une appli web qui se contente de recevoir des packets binaires depuis un device quelconque, l'API servlet suffit amplement. Mais c'est vrai que dès qu'il faut faire une appli pour un browser web, on utilise un framework. Et y'en a une pléthore: Spring MVC/Webflow, Struts, Wicket, GWT, JSF, Cocoon, Tapestry, etc...

Je profite de mon topic pour poser une autre question : quelle système de gestion de versions me conseillez-vous ? J’aime bien subversion que je connais déjà un peu, mais j’ai aussi le choix avec git dont la principale différence est d’être décentralisé si j’ai bien compris. Or, je n’ai pas du tout besoin de cette décentralisation : la version de référence de l’appli sera sur le dépôt. Est-ce que git a d’autres intérêts ou avantages par rapport à Subversion ?

Bah, à mon avis pas vraiment, et je n'aime pas du tout git (surtout parce que les frontends graphiques sont tous pourris, mais aussi parce que ça m'agace quand des développeurs ne publient pas leurs développements en temps réel, je suis pour le commit early, commit often dans un dépôt central public), mais il y en a d'autres qui ne jurent que par ça et de plus en plus de projets y passent.

ça permet de faire des commits annulables dans un train, avion, boulot avec net pas connecté, etc

mais c'est compliqué à utiliser je trouve. faut vraiment s'y mettre.

Je suis pour subversion aussi. Relativement simple à utiliser (surtout avec des outils comme TortoiseSVN ), bien répandu, et connu de tous. Je vois pas pourquoi t'embêter avec autre chose si tes besoins sont déjà remplis
(git je m'en suis jamais servi parce qu'après avoir passé plus d'une nuit à biduler des trucs avec des choses dans mon dos pour télécharger les sources du noyau linux il y a 1 ou 2 ans, j'en ai conclu que ça ne valait pas ce qui se faisait à côté (plein de temps perdu alors que je voulais _juste_ compiler le machin derrière))

git sera utile quand TortoiseGIT marchera correctement.

Les Tortoise*, c'est totalement pourri: pas portable, et abus de l'explorateur de fichiers à la place d'une interface dédiée. Pour SVN, je conseille kdesvn, eSvn ou RapidSVN.

qui a besoin d'un outil portable pour travailler sous windows©?

sinon, linux n'a qu'à supporter l'API win32.

Je vote aussi pour svn

Kevin Kofler (./18) :
Les Tortoise*, c'est totalement pourri: pas portable, et abus de l'explorateur de fichiers à la place d'une interface dédiée.

C'est ce qui fait tout son intérêt #trigol#

Pour SVN, je conseille kdesvn, eSvn ou RapidSVN.

Mais pourquoi être obligé de lancer une interface dédiée ? Ça n'apporte rien !

Bah je ne comprends pas pourquoi Kevin a dit ça, kdesvn s’intègre complètement dans l’explorateur de fichiers, de la même manière que TortoiseSVN.

Bah ! Il n'est plus à une contradiction près

Sasume (./21) :
Bah je ne comprends pas pourquoi Kevin a dit ça, kdesvn s’intègre complètement dans l’explorateur de fichiers, de la même manière que TortoiseSVN.

Je n'utilise pas du tout cette fonctionnalité, j'utilise l'application dédiée. D'ailleurs l'intégration à Dolphin/Konqueror peut être désactivée carrément (et c'est le cas ici, mais de toute façon j'utilise Krusader).

on s'en tape Komplètement!

je suis justement en train de m'intéresser à ce sujet pour remplacer subversion justement. J'ai regardé les 3 qui se disent décentralisés, gratuits, libres et populaires:
* git : apparemment le plus performant, mais vraiment trop compliqué
* mercurial : apparemment performant, la ligne de commande est semblable à celle de svn.
* bazaar : réputé moins performant mais ça s'améliore. J'ai pas encore trop bien compris sa gestion des branches, elle me parait louche: il gère le move mais pas la "copie" de fichier par exemple...

Je bosse aussi de manière "centralisée". Et à part git, il peuvent fonctionner de la même manière que subversion: dès que tu commit en fait ca va direct sur le repo distant. Pour moi l'intérêt de ces outils c'est qu'ils ont une vrai gestion des branches et des merges. Avec svn tu peux t'accrocher pour faire un truc dans ce genre: http://nvie.com/git-model (et c'est ce qui nous pose pas mal de soucis au boulot). Je sais pas si vous avez vu la video du Linus qui parle de git lors d'un conf google. Faut la voir si vous l'avez pas vu. A prendre pas mal au second degré, y'a des moments fun
Autre truc qui me plait, mais c'est plutôt un problème chez subversion qu'une feature des systèmes distribués, c'est qu'il y a des .svn partout, et qu'au final la working copy subversion fait 2 fois la taille de ce que tu as commité. Alors que git et al. arrivent à faire moins et avec l'historique.

donc si tu as le temps, je dirais essaye mercurial. Sinon effectivement subversion est une valeur sûre.

mercurial aussi pèse son poids. je dirais git, à choisir entre hg et git.

Bah, si tu veux une copie de travail minimale, il y a un seul choix: CVS!

Pour les merges avec SVN, --ignore-ancestry peut faire des miracles. SVN cherche à être très malin quand on merge des dépôts avec un ancêtre commun, alors que dans la plupart des cas, un simple merge de type diff+patch est beaucoup plus efficace (surtout quand on a déjà mergé une partie des commits).

CVS

crayon

je dirais même plus, CVS est obsolète (c)

Comme gopher quoi