Comment Microsoft fournit des logiciels avec DevOps

Microsoft possède des décennies d’expérience dans la fourniture de services hautement évolutifs aux environnements de production. À mesure que les services et environnements Microsoft ont développé, leurs pratiques de livraison ont également évolué au fil du temps. De nombreux clients Microsoft ont également adopté et bénéficient de ces pratiques de livraison efficaces. Les principaux principes et processus DevOps suivants peuvent s’appliquer à n’importe quel effort de livraison de logiciels moderne.

Pour implémenter des processus de livraison DevOps, Microsoft a adopté les initiatives suivantes :

• Axer l’état d’esprit organisationnel et la cadence sur la livraison.
• Former des équipes autonomes et responsables qui possèdent, testent et fournissent des fonctionnalités.
• Passez directement aux tests et surveillez les systèmes en production.

Concentration sur la livraison

L’expédition plus rapide est un avantage évident que les organisations et les équipes peuvent facilement mesurer et apprécier. La cadence DevOps classique implique des cycles de sprint courts avec des déploiements réguliers en production.

Craignant un manque de stabilité du produit avec des sprints courts, certaines équipes avaient compensé avec des périodes de stabilisation à la fin de leurs cycles de sprint. Les ingénieurs voulaient expédier autant de fonctionnalités que possible pendant le sprint, de sorte qu’ils ont contracté une dette d'essai qu’ils ont dû rembourser pendant la stabilisation. Les équipes qui ont géré leur dette pendant le sprint ont ensuite dû soutenir les équipes qui ont accumulé de la dette. Les coûts supplémentaires ont joué par le biais des pipelines de livraison et en production.

La suppression de la période de stabilisation a rapidement amélioré la façon dont les équipes ont géré leur dette. Au lieu de reporter les travaux de maintenance clés à la période de stabilisation, les équipes qui se sont endettées ont dû consacrer le sprint suivant à rattraper leurs objectifs d'endettement. Les équipes ont rapidement appris à gérer leur dette d'essai pendant les sprints. Les fonctionnalités sont efficaces lorsqu'elles ont fait leurs preuves et qu'elles valent le coût du déploiement.

Automatiser entièrement les pipelines

Une grande partie de l’amélioration que les équipes peuvent gagner immédiatement consiste à automatiser entièrement les pipelines du dépôt de code jusqu'à la production. L'automatisation comprend des pipelines de mise en production avec intégration continue (CI), tests automatisés, et livraison continue (CD).

Les équipes peuvent éviter le déploiement, car c'est difficile, mais moins elles se déploient fréquemment, plus c'est difficile. Plus il y a de temps entre les déploiements, plus les problèmes s'accumulent. Si le code n’est pas récent, il y a une dette de déploiement.

Il est plus facile de travailler en blocs plus petits en déployant fréquemment. Cette idée peut sembler évidente avec du recul, mais sur le moment elle peut sembler contre-intuitive. Les déploiements fréquents encouragent également les équipes à hiérarchiser la création d’outils et de pipelines de déploiement plus efficaces et fiables.

Utiliser des outils internes

Microsoft utilise le système de gestion des versions qu’ils créent et l'expédie aux clients. Un investissement unique améliore la productivité de l’équipe et les produits Microsoft. L’utilisation d’un système secondaire siphonnerait la vitesse de développement et de livraison.

Autonomie et responsabilisation de l’équipe

Aucun indicateur de progrès clé (KPI) spécifique ne mesure la productivité ou les performances de l’équipe, ou si une fonctionnalité est sur la bonne voie. Les équipes doivent être en mesure de gérer leurs propres plans et retards, tout en recherchant un moyen de s’aligner sur les objectifs organisationnels.

Il est important de communiquer directement avec les équipes pour suivre les progrès. Les outils doivent faciliter la communication, mais la conversation est le moyen le plus transparent de communiquer.

Hiérarchiser les fonctionnalités

Un objectif important est de se concentrer sur la fourniture de fonctionnalités. Les planifications peuvent évaluer ce que les équipes et les individus peuvent raisonnablement accomplir sur une période donnée, mais certaines fonctionnalités seront livrées plus tôt et d'autres viendront plus tard. Les équipes peuvent hiérarchiser le travail afin que les fonctionnalités les plus importantes parviennent à la production.

Utiliser des microservices

Les microservices offrent différents avantages techniques qui améliorent et simplifient la livraison. Les microservices fournissent également des limites naturelles à la propriété de l’équipe. Lorsqu’une équipe dispose d’une autonomie quant à l’investissement dans un microservice, elle peut hiérarchiser la façon de mettre en œuvre les fonctionnalités et de gérer la dette. Les équipes peuvent se concentrer sur les plans de facteurs tels que le contrôle de version, indépendamment des services globaux qui dépendent du microservice.

Travailler en principal

Les ingénieurs travaillaient dans des branches distinctes. La dette de fusion sur chaque branche a augmenté jusqu’à ce que l’ingénieur tente d’intégrer sa branche dans la branche principale. Plus il y avait d'équipes et d'ingénieurs, plus l’intégration devenait importante.

Pour que l’intégration se fasse plus rapidement, plus en continu et en plus petits blocs, les ingénieurs travaillent désormais dans la branche principale. L’une des principales raisons de passer à Git était les offres Git de branchement léger. L’avantage pour l’ingénierie interne était d’éliminer la hiérarchie profonde des branches et son gaspillage. Tout le temps autrefois consacré à l’intégration est désormais consacré à la livraison.

Utiliser des indicateurs de fonctionnalité

Certaines fonctionnalités ne sont pas complètement terminées pour un déploiement sprint, mais peuvent encore bénéficier de test en production. Les équipes peuvent fusionner et déployer ce code avec des indicateurs de fonctionnalité pour activer la fonctionnalité pour des utilisateurs spécifiques, tels que l’équipe de développement ou un petit segment d’utilisateurs précoces. Les indicateurs de fonctionnalité contrôlent l’exposition sans risquer des problèmes avec la base d’utilisateurs globale, et peuvent aider les équipes à déterminer si et comment terminer la fonctionnalité.

Test en production

Le passage direct aux tests en production permet de s’assurer que les tests de pré-production sont valides et que les environnements de production en constante évolution sont prêts à gérer les déploiements.

Instrumenter les tests et les métriques

Peu importe où une application est déployée, il est important de tout instrumenter. L’instrumentation permet non seulement d’identifier et de résoudre les problèmes, mais peut fournir des recherches précieuses sur l’utilisation et ce qu’il faut ajouter ensuite.

Tester les modèles de résilience

Un risque pour les déploiements complexes est des défaillances en cascade, dans lesquelles une défaillance d'un composant provoque la défaillance des composants dépendants, et ainsi de suite jusqu’à ce que l’ensemble du système tombe en panne. Il est important de comprendre où se trouvent les points de défaillance uniques (SPOF) et comment ils sont atténués, et de tester les processus d’atténuation, en particulier en production.

Choisir les métriques appropriées

La conception de métriques peut être difficile. Une erreur courante consiste à inclure trop de métriques pour éviter de manquer quoi que ce soit. Toutefois, cela peut entraîner l’ignorance ou la méfiance de la valeur des métriques qui ne répondent pas à un besoin spécifique. Au lieu de cela, les équipes Microsoft prennent du temps pour déterminer les données dont elles ont besoin pour mesurer la réussite. Les équipes peuvent ajouter ou modifier des métriques, mais comprendre l’objectif dès le début facilite ce processus.

Outre la base d’une métrique, les équipes considèrent ce que'elles veulent que la métrique mesure. Par exemple, la vitesse ou l’accélération des gains des utilisateurs peut être une métrique plus utile que le nombre total d’utilisateurs. Les métriques varient d’un projet à l’autre, mais les plus utiles sont celles qui ont le potentiel d'influencer les décisions métier.

Utiliser des métriques pour guider le travail

Microsoft inclut des métriques avec des révisions aux niveaux de leadership les plus élevés. Toutes les six semaines, les organisations présentent leurs résultats en matière d’intégrité, d'entreprise, de scénarios et de télémétrie client. Les organisations discutent des métriques avec les cadres et leurs équipes.

Les équipes de toute l’organisation examinent les métriques des utilisateurs engagés pour déterminer la signification de leurs fonctionnalités. Les équipes ne se contentent pas d’expédier des fonctionnalités, mais cherchent à voir si et comment les gens les utilisent. Les équipes utilisent ces métriques pour ajuster les retards et déterminer si les fonctionnalités ont besoin de plus de travail pour atteindre les objectifs.

Directives de livraison

• Ce n’est jamais une ligne droite pour aller de A à B, et B n’est pas non plus la fin.
• Il y aura toujours des revers et des erreurs.
• Considérez les revers comme des opportunités d’apprentissage pour changer les tactiques pour terminer une partie donnée du processus.
• Au fil du temps, chaque équipe évolue ses pratiques DevOps en s’appuyant sur l’expérience et en s’adaptant pour répondre aux besoins changeants.
• La clé est de se concentrer sur la création de valeur, à la fois pour les utilisateurs finaux et pour le processus de livraison lui-même.