Depuis maintenant plus de 6 mois j’ai quitté Ucaya pour rejoindre l’éditeur SPI, Septeo Pôle Immobilier. Notre offre est actuellement composée de plusieurs gammes produits couvrant différents métiers de l’immobilier, tous issus de technologies variées (.Net, Cobol, 4D, VB6…). Cette multitude de produits s’explique par les différentes fusions acquisitions à l’origine de SPI.
La gestion des patchs et des versions des produits implique diverses taches de gestion et de suivi :
- Gestion du contenu de la version
- Processus de livraison du produit
- Documentation
- Prise en compte de contraintes métiers (administratives et légales)
- Communications inter-service (Hotline, Formation, Commerce, Direction…)
Au service développement nous sommes organisés en SCRUM et chaque produit possède son product backlog. Le suivi des bugs et des évolutions se fait via les work items de type Bug et Product Backlog Item. Nous avons bien évidemment apporté des customisations à ces éléments afin de répondre à nos contraintes d’organisation. Plus récemment nous avons introduit la notion de Version dans TFS en créant un nouveau type de Work Item, le type Release. Cet élément nous permet de regrouper des Work Items de type Bug ou Product Backlog Item afin de représenter l’ensemble des correctifs ou évolutions d’une version spécifique d’un produit.
Un nouveau Work Item : Release
Ce Work Item possède une date de livraison estimée, un numéro de version, un état, une liste de Bug ou de PBI et des champs qui nous sont spécifiques, comme l’illustre l’image ci-dessous :
L’utilisation du Front de TFS à elle seule ne permet pas de satisfaire les besoins en terme d’organisation et de suivi des versions. Il est difficile de mettre en place des indicateurs d’alerte métier (contraintes de dates spécifiques au métier, aux produits, etc…), d’avoir un suivi global des gammes ou encore de partager l’information telle qu’elle sort de TFS.
En effet le partage d’informations provenant du service développement à destination des autres services (formation, hotline, etc…) est nécessaire. Mais ces informations, définies dans le contexte du service développement et issues de TFS, ne sont pas des plus compréhensibles par tous. Nous parlons de Work Item, de backlog, de build, de release, etc… Avec la direction, les services formation, hotline…. un vocabulaire beaucoup moins technique est utilisé. Donner un accès brut et sans artifice à TFS à des personnes extérieures au service développement n’est pas la solution de part la richesse de la plateforme et de son vocabulaire spécifique.
En travaillant sur la présentation de l’information nous pouvons réussir à donner un vrai paradigme métier à la gestion des versions. Tout en nous appuyant sur TFS, nous allons pouvoir gérer nos règles et nos contraintes métiers de planification et avoir un outil de gestion des documentations et/ou des livraisons centralisées.
Un outil de gestion des releases a donc été développé afin de répondre à ces différents besoins. Il s’inscrit entièrement dans l’univers de TFS et de son Team Web Access en reprenant ses couleurs d’accent et certains concepts ergonomiques.
Consultation des versions en liste
L’affichage des versions d’un produit offre une lecture rapide de la prochaine échéance, des suivantes et des anciennes grâce aux regroupements :
Consultation des versions en vue Planning
Une vue planning des versions inter-gamme permet de mieux juger de la chronologie des éléments :
Consultation d’une release – Groupé par Etat
La consultation du contenu d’une release, selon différentes dimensions (état, module, type…), s’appuie également sur des regroupements pour une lecture plus naturelle.
Ici la dimension d’état pour le suivi du réalisé, planifié… L’état des work items n’est pas présenté de manière brut, il est interprété. Par exemple, un travail est considéré comme planifié selon sa propriété Iteration Path et donc s’il est planifié dans un sprint :
Consultation d’une release – Groupé par Module
La dimension par module permet de consulter le contenu d’une version d’un point de vue fonctionnel. Un regroupement est effectué sur la propriété Area Path (le Root Path correspondant au nom du Team Project est supprimé de l’Area Path à l’affichage pour une meilleure lisibilité) :
Consultation d’une release – Groupé par Type
La dimension par Type permet de juger du caractère plutôt correctif ou évolutif de la version. Ici encore, le vocabulaire de TFS (Work Item de type Bug ou Product Backlog Item) a été masqué afin de privilégier un vocabulaire plus naturel :
Accès aux informations détaillées
La notion de Tooltip a été fortement utilisée afin d’obtenir des informations plus détaillées au survol des Work Items. Et pour un accès complet au formulaire d’un Work Item, il suffit d’un double-clic dessus pour ouvrir Team Web Access sur la page de l’élément :
Gestion de la documentation d’une Release
Nous avons également enrichit nos Work Item avec des champs de documentation; documentation pouvant être à destination des clients ou des services internes :
Ceci nous permet depuis l’outil de gestion de versions, lors de sa livraison, de générer automatiquement la documentation de la version en parcourant la liste des Work Items et en agrégeant le champ Notes. Les fichiers textes ainsi générés sont mis en pièces jointes du Work Item Release. Ainsi toutes les données sont stockées dans TFS :
Gestion du contenu d’une Release
La possibilité de modifier le contenu d’une version en ajoutant ou supprimant des Bugs ou Product Backlog Item :
Et une vue de recherche avancée des éléments à livrer. Par exemple, ci-dessous on recherche les éléments d’un sprint spécifique :
Livraison d’une Release
Et pour terminer, pour l’un de nos produits, entièrement gérer avec TFS et Visual Studio (gestion des sources, des builds, etc…) nous avons également inclus le processus complet de déploiement d’une version :
Conclusion
Cet outil va nous permettre de mieux gérer et de mieux suivre les mises à jour de nos gammes produit tout en gardant TFS comme référentiel, grâce à ses API et ses possibilités d’extensions.
Let There Be Code 