Laurent a publié un commentaire, suite à mon billet sur l’organisation des développements.
J’ai pensé que ce commentaire « méritait » d’être « remonté » au niveau billet.
Voici donc les recommandations d’Ysance pour organiser les développements :
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
