Comments on: Organiser les développements http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/ e-Commerce, marketing des sites marchands, technologies 2.0… Fri, 09 Jan 2009 20:54:09 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Dave http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17864 Dave Wed, 13 Feb 2008 03:35:18 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17864 et la plateforme, ou plutot les plateformes de dev ? ^^ (parfois une sur chaque poste de developpeur plus une sur serveur pour l'intégration) également possible un serveur spécifique pour les tests par le client sans compter la gestion du versionning, indispensable pour le travail à plusieurs et un serveur de sauvegarde ? mais Laurent a très bien complété le poste vécu : l'équipe de prod (qui gère les serveurs), habituée aux gros systèmes (avec des bases de données complexes derrière), avait prévu pour ses sauvegardes automatiques d'arréter plusieurs heures tous les weekends le serveur internet... et donc le site rendant ainsi enragé l'équipe de dev. pas la meme vision de la qualité de service ^^ et la plateforme, ou plutot les plateformes de dev ? ^^ (parfois une sur chaque poste de developpeur plus une sur serveur pour l’intégration)
également possible un serveur spécifique pour les tests par le client
sans compter la gestion du versionning, indispensable pour le travail à plusieurs
et un serveur de sauvegarde ?

mais Laurent a très bien complété le poste

vécu :
l’équipe de prod (qui gère les serveurs), habituée aux gros systèmes (avec des bases de données complexes derrière), avait prévu pour ses sauvegardes automatiques d’arréter plusieurs heures tous les weekends le serveur internet… et donc le site
rendant ainsi enragé l’équipe de dev.
pas la meme vision de la qualité de service ^^

]]> By: BLOG E-COMMERCE de François Ziserman » Archive du blog » Organiser les développements : suite avec Laurent http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17472 BLOG E-COMMERCE de François Ziserman » Archive du blog » Organiser les développements : suite avec Laurent Sat, 09 Feb 2008 12:49:52 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17472 [...] Laurent a publié un commentaire, suite à mon billet sur l’organisation des développements. [...] [...] Laurent a publié un commentaire, suite à mon billet sur l’organisation des développements. [...]

]]> By: francois http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17470 francois Sat, 09 Feb 2008 12:40:17 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17470 @Laurent> Merci pour ces infos : tellement bien que je vais le publier ! François @Laurent> Merci pour ces infos : tellement bien que je vais le publier !

François

]]> By: Laurent http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17467 Laurent Sat, 09 Feb 2008 11:16:02 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17467 Lorsqu'on développe à plusieurs (ou même tout seul), les outils d'organisation de travail et groupe sont cruciaux, mais ne doivent pas nuire à la productivité ( combien de fois j'ai vu des plates-formes où il fallait plusieurs minutes pour mettre à jour un fichier, compiler, tester, tout ca parce qu'il était interdit de 'travailler sur son PC' !). Je vais me permettre de donner/compléter (succintement) quelques pistes : * La plate-forme de développement : principalement sur les postes de développeurs et un SVN, mais mutualisant généralement la base de données pour éviter les désagréments d'évolution des modèles. La base de données étant sous la responsabilité d'une (et d'une seule) personne. Chaque développeur produit des tests unitaires pour ses dévleoppements. * Une plate-forme d'intégration continue (de type CruiseControl ou autre) : Dès qu'une mise à jour de SVN est détectée, update de la branche, recompilation, déploiement scripté de la totalité du projet, et lancement des tests unitaires. Ainsi, pas besoin d'attendre plusieurs jours avant de détecter des problèmes d'intégration. C'est un peu long à mettre en place, mais ces techniques ont largement prouvé leur efficacité sur le moyen/long terme. * Une plate-forme de recette : Elle sert à valider fonctionnellement les développements. Celle-ci peut aussi être déployée à l'aide des scripts d'intégration continue pour faciliter. Je demande à mes équipes de mettre en ligne généralement deux ou trois fois par semaine. Cela permet aussi de suivre l'avancement général des développements et de ne pas être surpris la veille de la livraison :-) * Une plate-forme de pré-production : A l'identique "techniquement" (mais en version réduite pour limiter les coûts) de la plate-forme de production. L'objectif ici est de mettre en situation réelle (chez l'hébergeur, avec firewalls, DNS...) l'application avant déploiement pour réaliser une recette technique. * Une plate-forme de production : Pour limite la casse, dupliquer la production sur la pré-production avant recette technique. Préparer des scripts de retour en arrière (ca c'est la théorie, mais le jour où on en a besoin, on est bien content d'en disposer). Et enfin... faire les installation en production de préférence le lundi ou le mardi, jamais le vendredi (c'est toujours bon de le rappeler) ! Ca fait beaucoup d'environnements, certes, mais si la plate-forme est bien paramétrables (URL, DNS, adresses IP de chaque service) dans des fichiers de configuration, quasimment un seul fichier (web.config, config.php, autre...) peut permettre de paramétrer l'ensemble de la plate-forme. Tout cela ne sont que des principes d'organisation et doivent être bien entendu couplés à l'organisation de l'équipe et les méthodes de développement (développement itératif, scrum, ...) Lorsqu’on développe à plusieurs (ou même tout seul), les outils d’organisation de travail et groupe sont cruciaux, mais ne doivent pas nuire à la productivité ( combien de fois j’ai vu des plates-formes où il fallait plusieurs minutes pour mettre à jour un fichier, compiler, tester, tout ca parce qu’il était interdit de ‘travailler sur son PC’ !). Je vais me permettre de donner/compléter (succintement) quelques pistes :

* La plate-forme de développement : principalement sur les postes de développeurs et un SVN, mais mutualisant généralement la base de données pour éviter les désagréments d’évolution des modèles. La base de données étant sous la responsabilité d’une (et d’une seule) personne. Chaque développeur produit des tests unitaires pour ses dévleoppements.

* Une plate-forme d’intégration continue (de type CruiseControl ou autre) : Dès qu’une mise à jour de SVN est détectée, update de la branche, recompilation, déploiement scripté de la totalité du projet, et lancement des tests unitaires. Ainsi, pas besoin d’attendre plusieurs jours avant de détecter des problèmes d’intégration. C’est un peu long à mettre en place, mais ces techniques ont largement prouvé leur efficacité sur le moyen/long terme.

* Une plate-forme de recette : Elle sert à valider fonctionnellement les développements. Celle-ci peut aussi être déployée à l’aide des scripts d’intégration continue pour faciliter. Je demande à mes équipes de mettre en ligne généralement deux ou trois fois par semaine. Cela permet aussi de suivre l’avancement général des développements et de ne pas être surpris la veille de la livraison :-)

* Une plate-forme de pré-production : A l’identique “techniquement” (mais en version réduite pour limiter les coûts) de la plate-forme de production. L’objectif ici est de mettre en situation réelle (chez l’hébergeur, avec firewalls, DNS…) l’application avant déploiement pour réaliser une recette technique.

* Une plate-forme de production : Pour limite la casse, dupliquer la production sur la pré-production avant recette technique. Préparer des scripts de retour en arrière (ca c’est la théorie, mais le jour où on en a besoin, on est bien content d’en disposer). Et enfin… faire les installation en production de préférence le lundi ou le mardi, jamais le vendredi (c’est toujours bon de le rappeler) !

Ca fait beaucoup d’environnements, certes, mais si la plate-forme est bien paramétrables (URL, DNS, adresses IP de chaque service) dans des fichiers de configuration, quasimment un seul fichier (web.config, config.php, autre…) peut permettre de paramétrer l’ensemble de la plate-forme.

Tout cela ne sont que des principes d’organisation et doivent être bien entendu couplés à l’organisation de l’équipe et les méthodes de développement (développement itératif, scrum, …)

]]> By: Fred http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17174 Fred Wed, 06 Feb 2008 09:50:18 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17174 Au niveau des outils, je recommande pour ma part Selenium pour les tests de non régression ; simple, efficace : totalement indispensable ! Au niveau des outils, je recommande pour ma part Selenium pour les tests de non régression ; simple, efficace : totalement indispensable !

]]> By: Daniel http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17100 Daniel Tue, 05 Feb 2008 17:28:48 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17100 ben pour avoir un bon frontoffice c'est pas mal d'avoir un suivi des feedbacks testeurs et un outil d'animation de l'équipe de dev... ben pour avoir un bon frontoffice c’est pas mal d’avoir un suivi des feedbacks testeurs et un outil d’animation de l’équipe de dev…

]]> By: francois http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17087 francois Tue, 05 Feb 2008 15:26:57 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17087 @Olivier> Oui, il faut effectivement développer des scripts de migration. Effectivement, Trac et SVN sont des bons outils, de plus en plus utilisés. @Scott> Tout a fait d'accord @Willou> Désolé de te décevoir ! Effectivement, on pourrait en mettre des kilomètres, écrire un livre même... Mais ce blog doit trouver son équilibre à la frontière de la technique et du marketing... Pas trop descendre dans la techno donc. @Daniel> Yes, mais tu débordes à mon sens sur d'autres sujets (CRM, back office). Le sujet de mon billet était juste les plate-formes pour développer et mettre en prod le front office. @Olivier> Oui, il faut effectivement développer des scripts de migration.
Effectivement, Trac et SVN sont des bons outils, de plus en plus utilisés.

@Scott> Tout a fait d’accord

@Willou> Désolé de te décevoir ! Effectivement, on pourrait en mettre des kilomètres, écrire un livre même… Mais ce blog doit trouver son équilibre à la frontière de la technique et du marketing… Pas trop descendre dans la techno donc.

@Daniel> Yes, mais tu débordes à mon sens sur d’autres sujets (CRM, back office). Le sujet de mon billet était juste les plate-formes pour développer et mettre en prod le front office.

]]> By: willou http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17058 willou Tue, 05 Feb 2008 09:25:29 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17058 Pour une bonne collaboration sur un projet de développement, je recommande vivement l'outil trac : trac.edgewall.org Pour une bonne collaboration sur un projet de développement, je recommande vivement l’outil trac : trac.edgewall.org

]]> By: Daniel http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17057 Daniel Tue, 05 Feb 2008 09:23:00 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17057 On peut même ajouter: + 1 plate forme de feedback client (type feedback2.0) + 1 blog de projet pour cristalliser les idées (Bluekiwi) On peut même ajouter:

+ 1 plate forme de feedback client (type feedback2.0)

+ 1 blog de projet pour cristalliser les idées (Bluekiwi)

]]> By: willou http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/comment-page-1/#comment-17056 willou Tue, 05 Feb 2008 08:53:25 +0000 http://www.ziserman.com/blog/2008/02/04/organiser-les-developpements/#comment-17056 Je trouve cet article peu succinct, surtout qu'il y a matière à développer dans ce domaine. Déçu. Je trouve cet article peu succinct, surtout qu’il y a matière à développer dans ce domaine. Déçu.

]]>