Bonjour tout le monde,
 
On vient de lancer un projet de type webapp pour le compte d'un client. Le site sera écrit en Java + Framework MVC (pas encore sûr lequel, mais y a des chances que ce soit Tapestry). En discutant avec mon chef (qui n'est pas un informaticien), il ressort qu'il veut que le dev de l'appli soit fait sur des PC de bureaux normaux (ou éventuellement un peu vitaminés), là où de mon côté j'ai prévu une workstation à ~5k€.
Je précise que l'appli sera dev (fin du projet dans 2 ans) principalement par un seul dev. De mon côté je ferai principalement du contrôle de qualité et écrirait certaines parties très délicates. Nous avons aussi prévu de travailler avec un studio de graphistes qui interviendraient sur les vues, et un peu d'argent pour appeler un DBA quand c'est nécessaire. Mon idée était de donner cette workstation au dev, avec la possibilité pour les "autres" d'y accéder par SSH (ou autre, à voir) pour lancer leurs tests.
 
Ce qui m'inquiète ce n'est pas tant l'écriture du code en soit, c'est surtout le fait de lancer les tests (et le temps qu'ils prendront). En effet, l'appli en question est sensée aller chercher des données dans une BDD de bonne taille (je prévois quelque chose dans les 10 Go, à la louche) qui devra ensuite calculer et afficher des graphs basés là dessus. Je précise que pendant la phase de dev, notre petite équipe devra être indépendante des autres infrastructures disponibles (donc pas possible de loger notre BDD sur un de nos clusters par exemple). J'ai donc peur que lorsque l'appli sera un minimum avancée, le fait que chacun lance ses petits tests de son côté nous fasse perdre un temps considérable à tous, alors qu'on aurait pu s'en sortir mieux avec un gros noeud de calcul central.
 
Question 1: Ai-je raison ou bien je m'en fais pour rien?
Question 2: Si j'ai raison, vous avez une idée de comment je pourrais quantifier le manque à gagner niveau productivité (genre, il y a de la littérature là-dessus quelque part?).
 
La seule façon de le convaincre c'est de lui montrer que le choix qu'il signe, est celui qui va apporter le plus d'argent au final. C'est pour ça que même si on n'est vraiment pas à 5k€ près, il ne va pas me lâcher (et il a raison) si je lui prouve pas que chaque centime vaut la peine ..  
 
Merci
 

Perso, je pense pas qu'un ordi à 5000 euros soit absolument nécessaire pour du dév. Ce qu'il faut surtout c'est un CPU suffisamment puissant et assez de RAM. Quand on voit les prix du marché, déjà pour moins de 1000 euros, t'as des machines qui font l'affaire.
 
J'ai plusieurs applis web (php/mysql) qui tournent sur le même serveur de prod, un AMD Opteron 252 avec 2 Go de ram sous Linux. Il supporte sans pb plus de 2000 requêtes par minute sur le SGBD. Avant celui là, j'avais un Dell GX260 et ça allait bien durant un temps.  
 
Ce qui est clair, c'est qu'une même machine supporte beaucoup mieux les taches en parallèles sur un OS type Linux
 
Pour les tests en // sur la BD, si cela est possible, rien ne t'empêche de la dupliquer sur les PC bureautiques avec une synchro le soir pour limiter l'impact des tests des autres personnes sur la machine du dév principal. Voir aussi si c'est utile durant la phase de dév d'avoir une BD de 10 Go. faire des tests sur un échantillon représentatif de données suffit généralement. Après, pour les tests relatifs aux perfs, là oui, 10 Go voire plus, mais tu peux les faire que ponctuellement.  
De plus, sur les PC bureautiques, tu mets une machine virtuelle avec tout l'environnement de dév ou test qui va bien, comme ça, dès qu'un nouvel intervenant arrive, tu déploies l'environnement rapidement
 
Par ailleurs, pour le temps des tests "long", j'imagine qu'il s'agit plus des tests d'intégration qu'unitaires. Pour ça, je t'encourage à utiliser la méthode de dév agile XP + le pilotage par les tests afin d'automatiser au max tous les tests (TU et TI). Ensuite, tu lances les tests la nuit, comme ça, pas de perte de productivité

Merci pour ton feedback. Plusieurs commentaires ceci dit (merci de me dire là aussi si mes craintes sont valables)
 
- Avec des machines à 1000€, ça sera difficile de pouvoir tester l'application dans une structure proche de celle utilisée pour la prod (BDD dans une VM, serveur web dans une autre, serveur de cache dans une 3ème) à cause de l'overhead représenté par les 3 systèmes. Et surtout, on dédoublera ces VM "pour rien". juste?
- Mon dev sera sous linux à priori, moi j'ai un VM Linux (moyen mais j'ai besoin de Windows pour d'autres choses)
- Pour la BDD de 10 Go, oui tout à fait. Par contre le soucis c'est que ces courbes sont obtenues à la suite de traitements statistiques sur plusieurs dizaines de tables, difficile de vraiment tester le rendu de la courbe en entier sans charger une partie conséquence tes données.
- Pour les tests les plus longs (en effet, ceux d'intégration) j'ai prévu de faire tourner ça avec des batch pendant la nuit en effet.
 
Par contre ce qui me prend un temps fou sur ma machine c'est l'évaluation du code-coverage. Et lorsque je suis en mode "je comble les trous laissés par mes tests", je lance l'outil en boucle quasiment...  
Là j'ai lancé la suite de tests écrite pour une petite appli à usage interne sur mon optiplex (sans tests d'intégration, uniquement unitaires et fonctionnels) et ça prend près de 3 minutes, alors que je dois avoir à tout pêter 15 vues :s.
 
Suggestions?

Sans connaître plus en détails le projet, difficile d'être très précis. Perso, ça ne m'a jamais posé de pbs de développer et faire la plupart des TU/TI dans un environnement différent de celui de prod. En effet, on est toujours censé faire une dernière campagne de tests de validation sur l'environnement de pré-prod (quand il y en a un), qui lui, est représentatif de l'environnement de prod, ou direct sur l'environnement de prod (mais non accessible des futurs utilisateurs). Toutes mes applis web (php/mysql), je les développe sous WinXP alors que le serveur de prod est sous Linux : jamais eu de (gros) soucis durant la campagne de validation, juste qq ajustements.
 
Pour tes stats, si c'est pour vérifier la fiabilité de test algos, es-tu sûr d'avoir besoin d'autant de données et pas juste un échantillon représentatif de tous les cas possibles? Moi, c'est comme ça que je fais, je me le construis (à la mano si c'est pas trop long, un extrait d'une BD de prod s'il y en a une).
 
Pour le code-coverage, est-ce que faire un développement piloté par les tests ne pourrait pas t'aider dans ce cas?

- Oui de toutes façon les 2 environnements ne seront pas identiques. Je préfère généralement développer sous Linux parce que je suis plus familier avec le système, c'est tout.
- Difficile à dire pour les données. À priori non, on n'aura pas besoin du tout, mais probablement que la bdd de tests se chiffrera quand même en 100ènes de Mo.
- Je pratique le TDD, mais il y a quand même toujours des ratées .
 
Bon à moins que qqn arrive avec des raisons en béton. je risque de lui dire "on essaie omme ça et au pire, on avisera par la suite". Il va pas particulièrement aimer ma "non-réponse" mais là Rufo t'es arrivé à me faire douter

je confirme que le dev sur VM est plus facile a maintenir et deployer.
 
maintenant tu peux tres bien avoir une machine correcte a ~1000e qui n'heberge qu'une partie des vm ou services  et qui agit comme serveur de reference, il suffit de la monter correctement (ssd + ram + bon proc) et de deployer les env de dev sur des workstation reliés en eth gb
 
ca te permet de ne pas avoir a maintenir les datasets partout ni les configurations specifiques et si tu mets dessus une vm de dev tu pourra tester de temps en temps en "reel" sans overhead reseau
 
l'avantage etant que si il y a un manque de performance tu peux rapidement le profiler et centraliser plutot que de surdimensionner tous les postes.

Salut,
 
Comme je l'ai dit plus haut, on ne peut pas s'appuyer sur nos autres infra, donc pas de possibilité d'avoir des machines à 1000€ reliées à des gros workstations ... Sinon tant qu'à faire j'aurais proposé des null-disk à 200€ qui tapent sur un gros serveur/cloud
Là le truc c'est que mis à part mon Optiplex, on doit acheter neuf tout le reste...

... tu veux dire qu'acheter une machine et un switch qu'on fout dans un coin c'est pas possible mais qu'une ws a 5ke ca l'est?
 
si vous pouvez pas vous appuyer sur les infra vous faites comment pour le versionning et le reste?
 
je te parle pas de nulldisk la, je te parle de faire acheter une machine qui ferait office de serveur de test local afin de liberer des ressources sur les postes de dev.
 
en gros le petit serveur sert a maintenir un dataset cohérent de la dbb pour les dev, heberge une version frozen testable de l'app (typiquement les versions de chaque atterrissage) tout en permettant a chaque poste d'avoir ses propres versions locales et d'acceder a la dbb via un port.
 
l'exemple type de ce genre de machine c'est une team d'integration chez un client genre banque/assu qui n'autorise aucune connection a l'infra.
 
tu montes la machine, tu colles ton sgbdr dessus, un j2ee et des scripts maven de build, un serveur svn/bugtrack et c'est marre. un switch au cul et tu branches ton optiplex dessus ainsi que la machine du dev.
 
ou alors j'ai mal compris la problematique.

Ok je vois. En gros tu dis : Plutôt que d'acheter une grosse machine, les dev ont des machines de bureau et on achète une autre petite machine en plus à utiliser comme serveur. Juste?
ça serait totalement jouable en effet, reste à voir ce que ça donne niveau temps de test.. mais vu que vous me semblez optimistes, lundi je vais aller dire ça à mon chef (qui sera content de ne pas me filer les 5k€ )

disons que l'investissement est plus rentable, surtout quand un petit serveur ca se trouve a moins de 1000e
un serveur de test ca peut se transformer a terme en machine de bureau
 
ca permet aussi si ta machine est down de ne pas avoir tout perdu...
(ca marche dans l'autre cas aussi)
 
par contre ne pas sous dimensionner le serveur car il faut bien voir que sur un dev de 2 ans les machines cibles seront plus puissantes qu'actuellement et un serveur qui rame c'est... chiant.
 
au niveau des temps de tests si tu as des tests unitaires a check tu les mets dans ton test maven junit et ils seront lancé regulierement sur la build du serveur. ca te permet d'avoir des metriques et comparer l'evolution sur une meme machine.
 
apres evidemment il y a des concessions, au niveau connexion dbb depuis un poste de travail par exemple. mais avec 2 postes et un bon switch Gb ca marche plutot bien.
 
dev chacun sur son poste avec son dataset c'est du temps de perdu en sync des modifs de code ou d'environnement la au moins tu est sur que ton dev est au plus proche de l'env cible donc tu limites le risque sur les regressions/forks et le deploiement
 
en gros annonce un optiplex 980 (par ex) avec 8Go + SSD a ~1000eHT
vis a vis d'un client c'est facile a justifier, en interne tu dis que c'est un poste de travail secondaire en failover.