Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Oui, j’ai bien conscience que le fait d’utiliser le mot "toujours" dans ce titre va m’attirer des problèmes. S‘il vous plait, prenez bien le temps de lire l'article en entier afin de comprendre le raisonnement qui m’a conduit à choisir ce titre.

J’ai beau être développeur .net depuis longtemps, je n’ai pas toujours utilisé Azure DevOps et ses prédécesseurs. Durant les années où je faisais du consulting, ceci était une véritable force.

Au fil du temps, j’ai été amené à faire un constat que je n’attendais pas. Il y a un problème qui finit toujours par se produire une fois la migration terminée : Azure DevOps s’adapte plus rapidement aux tendances du marché. Il intègre rapidement de nouveaux produits tiers, de nouvelles méthodes de travail, et de nouvelles fonctionnalités.

La belle plateforme que l’on a choisie devient alors un frein. Il faut savoir rester lucide et honnête. J’ai rencontré des décideurs qui ne voulaient pas admettre que leur solution d’ALM, DevOps, ou gestion de projet / ticketing était dépassée. Bien souvent, ce sont les mêmes qui ne voient pas l’intérêt de déployer les mises à jour, ou d’effectuer les migrations des produits qu’ils ont eu même choisis (qui a dit Log4J?).

Si l’on a de la chance, notre produit s’adapte. Mais ce n’est pas toujours le cas, et cela peut être long.

Après 2012, chaque génération d’Azure DevOps a représenté un challenge pour ses coururent. Les versions de TFS 2013, 2015, 2017 ont bousculé la gestion de projet. À chaque version, les prédécesseurs d’Azure Board gagnaient en fonctionnalité, facilitée d’usage, et voyaient leur ergonomie s’adapter à l’air du temps. Encore aujourd’hui, il y a des produits qui n’ont pas de Dashboards personnalisable, widgets paramétrables, vus adaptables et filtrables, ou de segmentation des équipes dans un même projet. Pire certains produits restent sur la gestion des tâches/bugs/user stories par états. On a un bon gros workflow et dès qu’une personne a un besoin, il faut se réunir pour ajouter des états et étudier les conditions amenant à celui-ci. Là où Azure DevOps permet d’agrémenter ses éléments avec des tags, de segmenter des colonnes dans les Taskboards, etc. …

À partir de 2015, ce sont les solutions de CI/CD qui on vraiment souffert.

Après 2017, le rythme est devenu insoutenable.

Ne parlons pas de la situation depuis l'arrivée de GitHub dans le giron de Microsoft. Les deux solutions sont devenues de véritables bulldozers dans leurs marchés respectifs.

Vous ne voyez pas de quoi je parle ?

Prenons quelques exemples de produits qui sont aujourd’hui en décalage (UI,UX, fonctionnalités):

• Mantis
• Bugzilla
• Jenkins (ex : builds YAML en mode expérimental depuis 2020)
• Redmine

Il y a aussi des produits qui savent s’adapter, mais plus lentement :

• Jira (très lent à adopter les tendances, et toujours pénible côté UX)
• GLPI

Et quelques produits qui gardent un bon rythme (mais je n’ai pas beaucoup d’exemples en tête)

• Wrike
• TeamCity

Moralité

Aujourd’hui, je n’ai toujours pas vu de solution s’adapter aussi vite qu’Azure DevOps.

Si vous envisagez de quitter Azure DevOps pour une autre solution, regardez bien à quel rythme le produit évolue, et est patché (qui a dit à nouveau Log4J ?). Si une reoadmap est disponible, consultez là pour éviter d’être déçus (je connais les devs qui attendent un véritable support des builds YAML dans Jenkins depuis des lustres).

Attention : si vous travaillez sur des solutions on-premise, il faut se souvenir que la progression est encore plus lente. Même Azure DevOps Server arrive à rester dans la course avec Azure DevOps (les quelques mois de décalage ne sont pas gênants).