Comment Microsoft fournit des logiciels avec DevOps

Microsoft a 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 :

• Concentrez la mentalité organisationnelle et la cadence sur l'exécution.
• Former des équipes autonomes et responsables qui possèdent, testent et fournissent des fonctionnalités.
• Passez à droite pour tester et surveiller les systèmes en production.

Se concentrer 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é de produit avec des sprints courts, certaines équipes avaient compensé les périodes de stabilisation à la fin de leurs cycles de sprint. Les ingénieurs voulaient expédier autant de caractéristiques que possible pendant le sprint, de sorte qu’ils ont engagé une dette de test 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é la dette. Les coûts supplémentaires se sont répercutés à travers les pipelines de livraison jusqu'à la 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 ont accumulé de la dette ont dû consacrer le prochain sprint à atteindre leurs objectifs de réduction de dette. Les équipes ont rapidement appris à gérer leur dette de test pendant les sprints. Les fonctionnalités fournissent quand elles sont éprouvées et valent le coût du déploiement.

Automatiser entièrement les pipelines

Une grande partie des améliorations que les équipes peuvent réaliser immédiatement consiste à automatiser entièrement les pipelines depuis le référentiel de code jusqu'à la production. Automation inclut des pipelines de mise en production avec intégration continue (CI), des tests automatisés et une livraison continue (CD).

Les équipes peuvent éviter le déploiement, car il est difficile, mais moins elles déploient fréquemment, plus cela devient difficile. Plus il y a de temps entre les déploiements, plus les problèmes se accumulent. Si le code n'est pas à jour, 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 dans le recul, mais au moment où 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’envoie aux clients. Un investissement unique améliore la productivité de l’équipe et les produits Microsoft. L’utilisation d’un système secondaire désactive le développement et la vitesse de livraison.

Autonomie et responsabilité de l’équipe

Aucun indicateur de progression clé (KPI) ne mesure la productivité ou les performances de l’équipe, ou si une fonctionnalité est en cours. Les équipes doivent être en mesure de gérer leurs propres plans et backlogs, tout en recherchant un moyen de s’aligner sur les objectifs de l’organisation.

Il est important de communiquer directement avec les équipes pour suivre la progression. 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 plannings peuvent évaluer combien de travail 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 seront disponibles plus tard. Les équipes peuvent hiérarchiser le travail pour que les fonctionnalités les plus importantes arrivent en production.

Utiliser des microservices

Les microservices offrent différents avantages techniques qui améliorent et simplifient la livraison. Les microservices fournissent également des frontières naturelles pour la responsabilité de l'équipe. Lorsqu’une équipe dispose d’une autonomie sur l’investissement dans un microservice, elle peut hiérarchiser la façon d’implémenter des fonctionnalités et de gérer la dette. Les équipes peuvent se concentrer sur les plans concernant des facteurs comme le versioning, indépendamment des services globaux dépendants du microservice.

Travailler dans le 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 les équipes et les ingénieurs y étaient, plus l’intégration est devenue importante.

Pour que l’intégration se produise plus rapidement, plus en continu et en petits segments, les ingénieurs travaillent désormais dans la branche principale. Une raison importante de passer à Git était les branches légères que propose Git. L’avantage de l’ingénierie interne était d’éliminer la hiérarchie des branches profondes et ses déchets. Tout le temps passé à intégrer est maintenant consacré à la livraison.

Utiliser des indicateurs de fonctionnalité

Certaines fonctionnalités ne sont pas entièrement terminées pour un déploiement sprint, mais peuvent toujours tirer parti des tests en production. Teams peut 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 à un test 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.

Tests et métriques d'instruments

Quel que soit l’emplacement de déploiement d’une application, il est important d’instrumenter tout. 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 les éléments à 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 de composant provoque l’échec des composants dépendants, et ainsi de suite jusqu’à ce que l’ensemble du système se décompose. 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. Teams peut ajouter ou modifier des métriques, mais comprendre l’objectif du début facilite ce processus.

Outre la base d’une métrique, les équipes considèrent ce qu’elles ont besoin 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 de prendre des décisions métier.

Utiliser des métriques pour guider le travail

Microsoft inclut des métriques au sein des évaluations aux niveaux de leadership les plus élevés. Toutes les six semaines, les organisations présentent leur performance en matière de santé, d'activités, d'analyses et de télémétrie client. Les organisations discutent des métriques avec les cadres et leurs équipes.

Les équipes de l'organisation examinent les métriques des utilisateurs engagés pour déterminer l'importance de leurs fonctionnalités. Teams n’offre pas seulement des fonctionnalités, mais cherche à déterminer si les utilisateurs les utilisent et comment ils les utilisent. Teams utilise ces métriques pour ajuster les backlogs et déterminer si les fonctionnalités ont besoin de plus de travail pour atteindre les objectifs.

Recommandations en matière de livraison

• Il n'est jamais question d'une ligne droite pour aller de A à B, et B n'est pas 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é consiste à se concentrer sur la fourniture de valeur, à la fois aux utilisateurs finaux et au processus de remise lui-même.