Reprise du message précédent :

http://nraynaud.fr/munin/

Après, ça dépend de tes besoins, si c'est pour stocker des clé/valeurs complètement arbitraires, en les utilisant qu'en simple affichage, ça peut le faire.

Après, si c'est juste parce que t'as la flemme de faire des tables avec pleins de champs, c'est pas une bonne idée (je parle par expérience )

Yeah
Reste plus qu'à activer d'autres plugins si tu veux d'autres stats

d'abord foutre un mot de passe je pense

C'est moins drôle

 
ne connaissant pas a l'avance les champs , ca me semble tendu de faire une table avec plein de champs
 
parceque le nombre d'attribut qu'une voiture peut avoir est super elevée  

function cleaner(str) {
        var s = new String(str);
        s = s.replace("nosurligner", "" );
        s = s.replace("surligner", "" );
        return s;
}

function AttendrePourLireLaSuite(Duree)
{
  LS = setTimeout(LireLaSuite,Duree);
}

 
ouaip y a eu changement de specs et ils ont envoyé ton script a des frees et visiblement il a encore été retouché en intégration
 
t1 j avais oublié ce passage qui m avait fait mourir de rire

Yeah, rajout des lignes dans mon sources.list, lancement d'aptitude, sélection des bons packages, install, tout roulorze et mon pb de group_concat avec de l'UTF-8 est réparé Temps total : 2 minutes.
Merci !

Le plus beau c'est surtout ce que le commentaire est resté mais le code correspondant a été viré

C'est toi qui mets les commentaires "ça c'est pas bien", "ça c'est crado mais pas le choix" ?

Bon c'est bon j'ai taté un peu la chose

Maintenant juste quelques questions pour être sûr

• Les serveurs de test, devs et prod sont-ils bien tous des working copies (d'un même repository of course) ?
• SVN gère-t-il les listes d'exclusions (fichiers de config différent suivant les serveurs, scripts de test) ?
• Comment gèrer les changements de structure (voire de contenu pour certaines tables fixes) dans les BDD ? à la main comme avant ?

non, le serveur de prod ne DOIT pas être une working copies mais un export sinon il y a les .svn qui traine avec une copie des sources dedans...
Après, pour le serveur de test ou de devs, c'est mieux ce ne sont pas des workings copies pour être iso avec la prod mais bon, moi, ça me perturbe pas plus que ça tant (pour l'instant)

svn prop-set:ignore je crois

bah, ça versionne des fichiers. tu peux versionner les migrations de base ou autre.

ha ben nan
ici (gatsu@corp) y a un repo different pour les front/back office
en FO on bosse avec svn mais les BO bossent avec maven (je crois) qui cree un build a chaque commit ce qui foutrait possiblement la merde si un build devait etre créé a chaque changement de css
et meme si php (par exemple) n est pas compilé je pense que c ets une methode nettement plus viable que d utiliser le meme repo
imaginons que tu commites un bug bloquant sur ton dev php ca empecherait ton equipe front office de bosser alors qu avec des repo séparés ils sont assuré de toujours bosser sur une version fonctionnelle
et pour les memes raison c ets important que que les tests et prod soient indépendants du repo de dev
(en général on se contente d exporter les version stables sur l un et l autre)
 

je pense surtout qu' un fichier de config ne devrait pas etre versionné et encore moins modifié...
 

...et c est encore plus valable pour une bdd

  non, maven, est utiliser pour builder le projet et gérer les dépendances.
Tu peux très bien 'checkouté' le projet sur ton serveur de test et le builder ensuite avec Maven.
...mais tu peux aussi builder le projet avec Maven sur un serveur d'intégration continue...qui créé un build a chaque commit  

bah, si tu peux, ca permet de suivre les modifs de config. Mais bon, c'est pas forcement pratique quand on ne peut avoir qu'un seul fichier de config (si tous les développeurs commit leurs config dans le même fichier, ça risque d'être la galère...) A ce niveau là, l'orga dans le projet que je viens juste de quitté était sympa (mais un peu galère quand on pige que dalle a ce qui ce passe /o\)

  Dans rails, il y a le système de migration que tu versionne (et ça, c'est vraiment sympa)

Comme l'indique zapan666, c'est pas une bonne idée d'avoir une working copy pour la prod (parce que svn fout des répertoires .svn de partout). Mieux vaut avoir dev et test en working copy, et prod en export.

Une property "svn:ignore" spécifique à un répertoire donné (voir svn propget, proplist, propset, propedit et propget)

Ceux là je conseillerais de les versionner et de dispatcher par autre chose (hostname) pour la sélection de la config.

Tu versionnes les fichiers de migration (SQL, ou ruby si tu fais du rails)

Non

Ce sont des projets différents, et le front est inclus en svn:external dans le back
Ou alors c'est tout dans le même projet

C'est pas maven qui fait ça, c'est hudson (le serveur de build continu), et vu qu'un changement de CSS n'a aucune raison de pêter le build, ben le serveur aurait juste tendance à builder pour rien, ce qui est pas gênant.

Accessoirement, on peut aussi lui faire lancer des tests unitaires, au buildbot (mais bon celui de gatsucorp n'est déployé que sur les applis java, donc ça s'applique pas à php)

Bof.

Sur test/recette, on export pas sinon c'est merdique pour savoir à quelle révision on est (vu que svn ne crée pas de fichier de métadata disant quel chemin a été exporté et à quelle révision), et surtout c'est très chiant quand il faut mettre à jour pour tester les fix (vu que svn export, ben il écrase tout sans se poser de question, c'est pas rsync et il est pas là pour réfléchir)

Naturellement, ça peut être noté à côté, mais vu la propension des gens à oublier ça, et dans la mesure où il faut déjà qu'ils se souviennent de le noter pour la prod, vaut mieux éviter

Ben t'as tord

Là aussi t'as tord, le drop database + recréation from scratch c'est rarement une bonne idée quand on doit faire évoluer le schéma, surtout sur des grosses db bien vieilles avec plein de bordel dedans

Sauf qu'ils sont versionnés par index numérique incrémenté à chaque création de migration, donc si t'as 2 personnes qui créent des migrations en même temps c'est la merde \o/

 
bah justement c est le meme projet avec des repos differents
apres la facon dont le FO est integre en BO je m en fiche un peu
 

 
quand je parlais de foutre la merde c est ca que je voulais dire
builder un projet pour un commit de css c est un peu overkill quoi
 

 
justement sur test/recette on se fiche  un peu des numeros de build (enfin de mon coté et je crois pas que theredled bosse sur de grosses applis java ) la raison principale etant que les consultants n y bitent rien
 

 
si tu pouvais developper un peu merci
 

 
bah jpense qu un simple backup est nettement plus approprié pour une bd
et la encore si jme plante developpe

une migration = 5ko
un backup = 5Go
 
   

Pas au sens de repository svn, ils sont juste dans des répertoires différents

Tout le monde s'en fout, le serveur à rien de mieux à faire de sa journée de toute façon

Je parle pas des numéros de build mais des révisions, et non on s'en fout pas sinon on sait pas ce qui est actuellement sur test ou en recette

Avoir des fichiers de config versionnés permet:
1. D'avoir un fichier de config par défaut dont on peut voir l'évolution
2. D'avoir le fichier de config des autres utilisateurs comme example pour le sien (vu que sur les projets gatsucorp il n'y a pas de wizard pour créer ça)
3. D'ajouter les nouvelles propriétés qu'on vient de créer (ou des placeholders pour avec un joli commentaire) dans les fichiers de config de tout le monde quand on ajoute un setting mandatory
4. De pas avoir à penser à sauvegarder le fichier de config de la prod quand on veut la réinitialiser
 
Entre autres

Ben tu te plantes encore
1. Un backup et une migration, ça fait pas la même taille, surtout pour de vieilles db
2. Une migration, ça peut s'appliquer sur n'importe quelle base (toutes les machines de dev, base de dev, base d'integ, base de prod, ...) alors que la majorité des devs n'ont pas besoin d'une base de prod sur leur machine
3. Un backup, ça se versionne pas
4. Un backup ne permet pas de savoir facilement quand le schéma de la db a été changé, pourquoi, et en relation avec quelles autres modifs. Un fichier de migration (qu'il soit en sql ou pas) si

une bd 5Go
une bd svnisée 10Go
et je parle pas des ressources proc si tu dois committer automatiquement chaque changement de la bd

Personne n'a parlé d'avoir toutes les données des db sous svn, juste les migrations de schémas

Donc des fichiers qui vont ressembler à ça (pour ror):

class AddANewTable < ActiveRecord::Migration
    def self.up
      create_table :users do |table|
        table.column :name, :string
        table.column :login,  :string, :null => false
        # This column will contain an MD5 hash.
        table.column :password, :string, :limit => 32, :null => false
        table.column :email, :string
      end
    end
 
    def self.down
      drop_table :users
    end
  end

rien de plus

 
heu, tu peux taguer les révisions utilisables...en théorie le front office est pas sensé bosser en live sur ton code, tu leur fait des livraisons...tu tagues les livraisons et voilà...
 

 

 
Pour du web admettons, mais sinon ton truc est super dangereux...dans ma boite on a des bases qui se chiffrent en To, parce qu'on gère des milliers de pièces (un véhicule industriel en contient une chiée, et pour des raisons légales on a 30 ans d'historique en permanence...)...
déjà v'la la gueule du dump, et ensuite le temps de le faire, de faire ta modif, de remonter le backup, ça se fait pas en 5 min, et on a comme qui dirait un impératif que les serveurs tournent, sinon les usines s'arrêtent, c'est la fin du monde, et ton chef t'oblige à te petit suicider avec des bas résilles
 
donc si t'as juste moyen de faire passer des scripts discrétos un samedi et avoir le tout torché le jour meme pour pas rater téléfoot le dimanche matin, ben tu le fais
 

Et laisser le front office jouer avec svn:externals pour avoir un truc qui fonctionne? Ou ne pas utiliser svn du tout?

je suis pas sur de comprendre ta remarque...
 
pour moi si t'as front office/back office le back office fournit une sorte d'API...et je suis pas sur que le front office soit sensé pouvoir taper dans 100% du code live...ne serait-ce que si tu commite une classe vide par ex, ou autre, que le gars parte pas bille en tete dessus...

 
bah justement quand je fais un checkout sur le repo d un projet je n ai acces qu aux donnees FO du projet
apres ptet qu on se comprend pas sur "projet" pour moi le projet c est porsche ou vodafone ( )
 

 
if faire du travail inutile :
 points nerd -= 1  

 

bah vu que je produis pas de build pour moi spareil hein et comme je n exporte que la denriere version stable apres je m en fous bien

 
en princip la config generale devrait pas changer au cours du projet ...  
s il y en a un par user c est surement des trucs qui me depassent genre classpath toussa nan
(meme si je crois que ca existe pas un fichier classpath mais dans l idee quoi )
 

 
bah je considere les db au niveau de ce que je sais du web : certainement pas grand chose mais je pense que ca doit s auto gérer et si ton architecture doit etre modifiee souvent c est juste qu elle est mal pensée et tu dois virer ton dba quoi

non, mais en fait, pour eux, frontoffice, c'est la maquette HTML
et Backoffice, c'est le model de données, les servlets etc.

edit : ou pas

Tu parles d'avoir des révisions taggées ou des livraisons faites par le back au front. Ca implique que:

1. Le front bosse sur une branche (tirée de la révision taggée), ce qui vu les capacités de merging de svn est suicidaire. Et même sans ça, ça serait merdique
2. Le front bosse à partir d'un tag svn, donc soit sans svn du tout soit avec un svn:externals qu'il faut régulièrement modifier pour pointer sur le bon tag, ce qui ne fonctionne pas vraiment bien
3. Livraison faite par le back, donc le front bosse soit sur son propre svn complètement indépendant en important les livraisons du back soit sans svn du tout

Aucune des 3 n'est pratique (e.g. si le front découvre un truc pêté/bloquant, ben faut attendre la prochaine livraison back).

Les trucs les plus simples à faire deviennent alors:

• Comme c'est géré chez gatsucorp, le front bosse dans svn sur un projet séparé, complètement indépendament du back, et les libs du front sont ensuite liées au backend via svn:externals. De cette manière le front et le back sont globalement indépendants
• Le front et le back bossent dans le même projet, juste sur des parties de code différentes, là il faut s'accorder sur ce qui est stable ou pas (donc le back doit tenir le front au courant de ce qui a été commencé/terminé/autre de leur côté)
• Utiliser un DVCS, le front et le back ont des repository reférences différents qui eux-même sont clonés d'un repository "maître", au moment des livraisons back on push tout du repo back au repo maître, puis on fait redescendre côté front, et même chose en inverse lors d'une livraison front (en bonus on peut ajouter un repo intermédiaire de validation entre chacun des repos "équipe" et le repo maître)

ca tombe bien c est le sujet du topac

On se comprend surtout pas sur la notion de repository. Dans SVN, tous les projets sont dans le même repository, mais dans des répertoires différents.

Ouais ben ça a aucun rapport quand même

Si tu savais

Serveur de db, serveur CAS (pour l'authent), URLs de récupération (ou pas) des divers WS, ...

Nan mais quand tu dev une application il n'est pas rare que tes besoin évoluent, ou que tu te rendes compte que t'avais oublié un truc dans ton étude initiale, ou que ce que tu pensais pouvoir faire ben en fait tu peux pas, ou bien alors avec ton design initial super propre ben tes perfs sont moisies donc tu as besoin de dénormaliser, ...

Et ca c'est juste sur le codage initial, après quand le client demande des évolutions (par exemple), ben t'as pas le choix, faut bien modifier ton schéma et ça c'est pas possible de le prévoir initialement (idem quand le client change ses besoins en cours de route)

Et ces changements de schéma, ben faut les garder quelque part sinon impossible de savoir quelle état de la db (au sens schéma des tables, pas contenu des tables) correspond à quel état du code source.

edit:

Ca pourrait tout aussi bien être les templates HTML/JSP (si les maquettistes GatsuCorp en faisaient), ou bien le JS pour driver les webapps (ce que faisait shinuza sur tcht-tcht pas de marque, c'est pas du front pour toi?), ...

Tout ce qui est "directement" visible pour le client, en fait, c'est du front. Et tout ce qui sert à le driver mais n'est pas directement visible, du back

bah, c'est un peu cette séparation que j'ai mal compris sur le projet (mettre ici un nom de projet qui fait cool). Mais bon, on va dire que j'ai pas l'habitude de travailler comme ça.

càd? Le fait que les ingés ne bossent pas sur le front/les templates, ou pas directement en tout cas?

Je ne comprend pas ce qui te fait croire ça. Le principe même d'une interface de configuration c'est de pouvoir effectuer un changement rapide

 
c est ca que je comprends pas ... l option create repository here est toujours dispo
 

 
jmen cogne
 

 
ok    
 

 
ok je savais pas qu on pouvait juste versionner le schema des tables  
et comme le soulignait jubijub les tables que l on manipule on web sont petites comparees a celles de certaines grosses appli enterpriseÿs

Dans tortoise? Oui, mais c'est jamais utilisé ce truc

 
je sais bien mais en meme temps si ta config est stable y a pas de raison de la changer (a part dans les cas cités par masklinn que j avais pas percutées )
 

 
ok

\o/ http://trac.symfony-project.com/wiki/sfModelTestPlugin

Le truc, c'est que la config dépend de deux facteurs:

1. Les éléments de config dont l'application a besoin, si on ajoute un élément configurable, ben il faut ajouter les bouts de config qui vont avec (au minimum des valeurs par défaut, qui seront habituellement dans un fichier de conf par défaut, potentiellement des valeurs spécifiques pour soi même, la dev et la prod, et on laisse les collègues se démerder pour leur propre conf)
2. Certains éléments de config, comme je l'ai dit au dessus, sont impérativement spécifiques à une machine ou un dev, mais avoir les fichiers de conf des autres est intéressant pour pouvoir avoir un exemple ou leur ajouter des bouts de conf (quand ça fait suite au cas 1)

C'est moi ou ce truc est intégré par défaut dans rails depuis genre sa première release publique?

 
ben c'est ce que tu mets dans ton premier point dont je parlais moi...
ton point 3) a l'air intéressant ...mais bon, normalement je serais plus jamais amené à bosser sur un VCS autrement que pour mon usage perso, donc voilà
 

C'est de la repompe. Mais heureusement que les mecs l'ont fait car c'est bien pratique. Je comprend pas trop pourquoi c'est pas de base dans symfony

C'est probablement le plus merdique des 3, à part à la limite si le front et le back sont gérés par des boites différentes

C'est une plaisanterie?

Certains font le choix de pas dev toute leur vie pro mon cher machine

Hihi
Mais vous bossez tous dans la même boîte ou bien
J'avoue que j'ai lâché le débat sur la fin, back-office/front-office là, je crois que vous parlez d'un projet précis que je connais pas
 
Bref. Je retiens que :

• Il y a une différence entre un svn export et un svn update, donc prod != working copy
• Il existe des fichiers de migration MySQL, à fouiller

Et ça, c'est cool
 
La seule question qui me vient là :
Souvent je teste mon serveur test/dev (le même chez moi) avec la BDD du prod, avec une simple modif de config, pour voir et prévoir son comportement, sur les mêmes données, réelles et non corrompues par des tests pourris.
Masklinn disait que le test devait être une copie exacte du prod. Ca s'inscrit là-dedans, voir le comportement du truc dans un environnement réel. Donc on utilise la même BDD pour les deux.  
Seulement voilà, si j'ai fait des modifs dans le schéma de la BDD de test, comment je fais pour utiliser le contenu de la BDD de prod, avec la structure de la BDD de test, tout en gardant l'ancien schéma pour le serveur de prod ?  
 
3 bases ?