Avec un peu de retard (1 petite semaine de vacances en roulotte au bord de la Charente … c’était vraiment super), et en réponse à Bruno et Manu, je rédige un petit article sur ma perception de comment générer du code déployable.
En fait je ne vois qu’une seule solution, et elle est basique, c’est de faire tourner le code sur des serveurs de production (ou similaire) pour s’assurer qu’il est bien déployable.
Sur un de nos anciens projets (abandonnés depuis) nous avions mis en place un test de nuit qui consistait à:
- Builder la dernière version (fichiers dans le tronc commun)
- Déployer automatiquement le build sur des serveurs de tests,
- Jouer un certains nombres de tests de non-régression
- Nettoyer le serveur.
Tous les matins, l’équipe avait donc une information sur la « deployabilité » ou non du build généré. Bien entendu, cela nous avait demandé un investissement pour mettre en place cette infrastructure mais on a rien sans rien.
Certains projets en Asie ont mis en place une notion de « Feature Freeze »que je préconise en interne, cela n’a rien à voir avec le Code Freeze qui est une totale abhération et que pourtant je vois encore pratiquée. Cette notion consiste à figer quelques jours avant la fin du sprint les features qui l’ont considère comme « chippables » (donc DONE) afin d’avoir le temps de jouer quelques tests plus complexes (comme des tests de performance) sur un build stable avant la fin du sprint. Durant cette période, les développeurs peuvent continuer à travailler sur les features restantes afin de respecter leur engagement de début de sprint et de les démontrer en revue de fin, mais elles ne seront pas considérées comme shippable pour ce sprint. Je suis conscient que c’est une entorse à la méthode (pas taper Jeff, pas taper) mais c’est pour l’instant la meilleure solution que j’ai trouvé pour tenir compte des contraintes de la vie réelle.
PS: Joseph, je suis désolé, mais je n’ai pas de solution toute faite pour débuter avec l’agilité, mais un des sites que j’apprécie paticulièrement est le blog de Claude Aubry qui contient beaucoup d’information (y compris la traduction en Français des slides de Mike Cohn de présentation de Scrum).