Quand on développe un site marchand, il est très important de bien organiser les développements.
En particulier, il faut très rapidement aller vers plusieurs plate-formes informatiques :
La plate-forme de développement
C’est sur cette plate-forme que les développeurs… développent.
Après avoir testé le bout de service qu’ils développent en local, sur leur machine, ils peuvent migrer le nouveau programme sur la plate-forme de développement et faire des tests, avec les programmes des autres.
La plate-forme de production
C’est la plate-forme en ligne, celle qui est visible par les clients, les Internautes.
La plate-forme de pré-production
C’est un sas, entre le développement et la production.
Cette plate-forme est tout à fait fondamentale, car elle permet de garantir que les nouveaux développements n’impliquent pas de régression.
Quand l’équipe estime que la version courante de développement est stable, on fait une migration, vers la pré-production, pour tout tester, dans tous les sens. Si les tests passent, on peut alors migrer, de la plate-forme de « pré-prod » vers la prod.
Simple, non ?
Oui, c’est comme ça qu’il faut s’organiser. Pas compliqué à mettre en place. Mais à maintenir c’est beaucoup plus pénible.
Tu as déjà vu des outils qui permettent de gerer ça automatiquement (surtout les bascules de l’un vers l’autre…).
Je n’ai pas encore eu le courage de faire les scripts pour ça….
J’utilise pour notre boutique, subversion, il nous permet de mettre en place exactement ce que tu as décrit.
C’est un peu difficile pour la première fois mais tous le monde après ne jure que par ça.
Je trouve cet article peu succinct, surtout qu’il y a matière à développer dans ce domaine. Déçu.
On peut même ajouter:
+ 1 plate forme de feedback client (type feedback2.0)
+ 1 blog de projet pour cristalliser les idées (Bluekiwi)
Pour une bonne collaboration sur un projet de développement, je recommande vivement l’outil trac : trac.edgewall.org
@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.
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…
Au niveau des outils, je recommande pour ma part Selenium pour les tests de non régression ; simple, efficace : totalement indispensable !
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, …)
@Laurent> Merci pour ces infos : tellement bien que je vais le publier !
François
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 ^^