Comment Microsoft a transformé sa R&D avec le Devops

Lors de Devops REX, un événement organisé en ce début de semaine à Paris, Samuel Métias, le responsable des offres agile et devops de Microsoft France, est revenu sur la transformation des équipes de développement du premier éditeur mondial. « On est passé de cycles de vie se chiffrant en années à des sprints courant sur 2 ou 3 semaines. A l’échelle d’un Microsoft, c’est une vraie révolution », explique le co-auteur de l’ouvrage Découvrir Devops, paru chez Dunod.

Une transformation qui est évidemment venue se greffer sur des pratiques existantes, les méthodes agiles étant déjà largement diffusées au sein des communautés de développeurs. « Chaque équipe avait sa propre définition du Devops. Il a d’abord fallu trouver une définition commune », raconte Samuel Métias. Autrement dit, celle d’une démarche impliquant tant les développeurs que les équipes d’exploitation mais aussi les métiers, et qui couvre l’ensemble du cycle de vie d’un produit, du design au support.

Autonomie et responsabilisation des feature teams

Pour Samuel Métias, la mise en place du Devops s’appuie sur 3 piliers. Une culture d’abord. « Car il s’agit avant tout de créer de la confiance. Rien ne sert d’automatiser un processus qui ne fonctionne pas. » Exemples emblématiques de cette approche qui doit privilégier les pratiques sur l’outillage, selon le spécialiste : la stratégie de tests ou encore les métriques. Bien sûr, dans un second temps, la diffusion des pratiques Devops dépend aussi d’outils d’automatisation, afin de « pérenniser cette confiance ». S’y greffe enfin un processus de continuous delivery, intégrant les tests automatiques et des déploiements progressifs.

A l’appui de sa démonstration, Samuel Métias se base sur l’exemple du groupe produit Visual Studio, le premier à se conformer aux nouvelles pratiques et le « porte-étendard » de cette transformation au sein des équipes R&D de la firme de Redmond. « L’approche est basée sur un principe : fournir de l’autonomie aux équipes et les responsabiliser », résume le responsable. Cette autonomie vient toutefois s’articuler avec une démarche d’alignement stratégique, assurée par la division où est intégré le groupe produit. Cette dernière fournit les grandes directions ainsi que des scénarios à 18 mois. « Au sein de ces scénarios, les équipes (organisée en feature teams pluridisciplinaires, NDLR) sont autonomes pour définir des fonctions proposées au marché », reprend Samuel Métias. La transformation aboutit à des cycles de 3 + 1 semaines, où la dernière semaine est consacrée à la mise en production et au démarrage, en parallèle, du cycle suivant. Notons qu’une itération toutes les 6 est consacrée à la réduction de la dette technique, autrement dit à la correction de bogues. Comme les versions online et serveur de Visual Studio évoluent à des rythmes différents (respectivement 3 semaines et 3 mois), les équipes doivent également veiller à la convergence du code entre les deux ‘branches’ de développement.

Tests 100 % automatisés

Le déploiement des nouvelles versions est assurée par cercles concentriques, avec pour démarrer le groupe produit lui-même, puis l’ensemble des ingénieurs de Microsoft et enfin les clients. « Si tout se passe bien, le déploiement se poursuit de façon automatique. A l’inverse, si un problème apparaît, une procédure de retour à la version antérieure est enclenchée », précise l’expert, qui ajoute que ce roll-back n’a pour l’instant été activé qu’une seule fois. Et ce, dès le déploiement au niveau du groupe produit. S’y ajoute une stratégie consistant à contrôler l’activation des nouvelles fonctionnalités via des ‘Feature Flags’ : « l’ancien code est supprimé uniquement quand le nouveau est pleinement testé », dit Samuel Métias.

Cette généralisation de l’automatisation est également totale au niveau des tests. Selon l’expert de Microsoft, passer au banc d’essai une nouvelle fonctionnalité demande moins de 5 secondes sur les tests techniques, mois de 5 minutes sur les tests fonctionnels et requiert jusqu’à une demi-heure pour les tests en production.

Si le Devops se traduit par la mise en place d’un pipeline automatisant toutes les étapes de la vie de l’application, il est aussi et peut-être avant tout synonyme de réorganisation des équipes. « Nous sommes passés d’une organisation très hiérarchisée à une organisation transverse », résume Samuel Métias, même si, dans le modèle Microsoft, les ops (la production informatique) ne sont pas à proprement parler intégrés aux feature team. Mais travaillent plutôt sur le modèle d’un hub de ressources fournissant un point de contact aux équipes de développement, tout en étant les garants du bon fonctionnement du produit.

A lire aussi :

Fnac : le Devops ne se limite pas à des outils

Tests applicatifs : les approches DevOps et agiles gagnent du terrain

Les 3 grandes étapes de la mise en place du DevOps

Photo credit: Thomas Hawk via Visualhunt.com / CC BY-NC