Développement de Microsoft avec DevOps

Microsoft s’efforce d’utiliser One Engineering System pour créer et déployer tous les produits Microsoft avec un processus DevOps solide centré sur un flux de branchement et de mise en production Git. Cet article met en évidence l’implémentation pratique, la mise à l’échelle du système entre les petits services et les besoins massifs de développement de plateforme et les leçons tirées de l’utilisation du système dans différentes équipes Microsoft.

L’adoption d’un processus de développement standardisé est une entreprise ambitieuse. Les exigences de différentes organisations Microsoft varient considérablement, et les exigences des différentes équipes au sein des organisations augmentent en fonction de leur taille et de leur complexité. Pour répondre à ces besoins variés, Microsoft utilise une stratégie de branchement basée sur les jonctions pour aider à développer rapidement des produits, à les déployer régulièrement et à fournir des modifications en toute sécurité en production.

Microsoft utilise également des principes d’ingénierie de plateforme dans le cadre de son système One Engineering.

Flux de publication Microsoft

Chaque organisation doit s’installer sur un processus de mise en production de code standard pour garantir la cohérence entre les équipes. Le flux de publication Microsoft intègre les processus DevOps du développement à la mise en production. Les étapes de base du flux de mise en production se composent de branchement, d'envoi (push), de requête de tirage (pull request) et de fusion.

Branch

Pour résoudre un bogue ou implémenter une fonctionnalité, un développeur crée une branche hors de la branche d’intégration principale. Le modèle de branchement léger Git crée ces branches thématiques de courte durée pour chaque contribution de code. Les développeurs valident tôt et évitent les branches de fonctionnalités longues à l’aide d’indicateurs de fonctionnalité.

Envoi (push)

Lorsque le développeur est prêt à intégrer et à livrer des modifications au reste de l’équipe, il pousse sa branche locale vers une branche sur le serveur et ouvre une pull request. Les dépôts avec plusieurs centaines de développeurs travaillant dans de nombreuses branches utilisent une convention d’affectation de noms pour les branches de serveur afin de réduire la confusion et la prolifération des branches. Les développeurs créent généralement des branches nommées users/<username>/feature, où <username> se trouve leur nom de compte.

Demande de tirage

Les pull requests contrôlent la fusion des branches thématiques dans la branche principale et assurent que les stratégies de branche sont satisfaites. Le processus de demande de pull génère les modifications proposées et exécute une batterie de tests rapide. Les suites de tests de premier et deuxième niveau exécutent environ 60 000 tests en moins de cinq minutes. Ce n’est pas la matrice de test complète de Microsoft, mais cela suffit pour donner rapidement confiance dans les pull requests.

Ensuite, d’autres membres de l’équipe examinent le code et approuvent les modifications. La révision du code commence là où les tests automatisés s'arrêtent et est particulièrement utile pour repérer les problèmes d'architecture. Les révisions manuelles du code garantissent que d’autres ingénieurs de l’équipe ont une visibilité sur les modifications et que la qualité du code reste élevée.

Fusionner

Une fois que la pull request satisfait à toutes les stratégies de génération et que les réviseurs ont approuvé, la branche de sujet est fusionnée dans la branche d’intégration principale, et la pull request est terminée.

Après la fusion, d’autres tests d’acceptation s’exécutent qui prennent plus de temps. Ces tests post-checkin traditionnels effectuent une validation plus approfondie. Ce processus de test offre un bon équilibre entre avoir des tests rapides pendant la révision des demandes de tirage et avoir une couverture complète des tests avant la mise en production.

Différences par rapport à GitHub Flow

GitHub Flow est un flux de mise en production de développement basé sur des jonctions populaire pour que les organisations implémentent une approche évolutive de Git. Toutefois, certaines organisations trouvent qu'à mesure que leurs besoins augmentent, elles doivent s'écarter de certaines parties du workflow GitHub.

Par exemple, une partie souvent ignorée de GitHub Flow est que les pull requests doivent être déployées en environnement de production pour les tests avant de pouvoir fusionner dans la branche principale. Cela signifie que toutes les pull requests attendent dans la file d’attente de déploiement pour être fusionnées.

Certaines équipes ont plusieurs centaines de développeurs travaillant constamment dans un référentiel unique, qui peut effectuer plus de 200 demandes de tirage dans la branche principale par jour. Si chaque pull request nécessite un déploiement dans plusieurs centres de données Azure à travers le monde pour les tests, les développeurs passent du temps à attendre la fusion des branches, au lieu de développer des logiciels.

Au lieu de cela, les équipes Microsoft continuent de développer dans la branche principale et de regrouper les déploiements en versions chronométrées, généralement alignées sur une cadence de sprint de trois semaines.

Détails de l’implémentation

Voici quelques détails d’implémentation clés du flux de publication De Microsoft :

Stratégie de dépôt Git

Différentes équipes ont des stratégies différentes pour gérer leurs dépôts Git. Certaines équipes conservent la majorité de leur code dans un dépôt Git. Le code est divisé en composants, chacun dans son propre dossier de niveau racine. Les composants volumineux, en particulier les composants plus anciens, peuvent avoir plusieurs sous-composants qui ont des sous-dossiers distincts au sein du composant parent.

Référentiels auxiliaires

Certaines équipes gèrent également les dépôts auxiliaires. Par exemple, les agents de génération et de mise en production et les tâches, l’extension VS Code et les projets open source sont développés sur GitHub. Les modifications de configuration s’archivent dans un référentiel distinct. D’autres packages dont dépend l’équipe proviennent d’autres endroits et sont consommés via NuGet.

Dépôt mono ou multi-dépôts

Bien que certaines équipes choisissent d’avoir un référentiel monolithique , les autres produits Microsoft utilisent une approche multi-répo. Skype, par exemple, a des centaines de petits référentiels qui se rassemblent dans différentes combinaisons pour créer de nombreux clients, services et outils différents. En particulier pour les équipes qui adoptent les microservices, le multipo peut être la bonne approche. En règle générale, les produits plus anciens qui ont commencé comme monolithes considèrent l'approche monorepo comme la transition la plus simple vers Git, et leur organisation de code le reflète.

Branches de mise en production

Le flux de publication de Microsoft conserve la branche principale en état d'être générée à tout moment. Les développeurs travaillent dans des branches thématiques de courte durée qui sont fusionnées dans main. Lorsqu'une équipe est prête à faire une livraison, que ce soit à la fin d'un sprint ou pour une mise à jour majeure, elle démarre une nouvelle branche de release à partir de la branche principale. Les branches de mise en production ne se fusionnent jamais vers la branche principale, de sorte qu’elles peuvent nécessiter des modifications importantes de sélection de cerises .

Le diagramme suivant montre les branches de courte durée en bleu et en branches de libération en noir. Une branche, comportant un commit qui doit être cherry-pickée, apparaît en rouge.

Stratégies et autorisations de branche

Les stratégies de branche Git aident à appliquer la structure de branche de mise en production et à garder la branche principale propre. Par exemple, les stratégies de branche peuvent empêcher les push directs vers la branche principale.

Pour conserver la hiérarchie des branches, les équipes utilisent des autorisations pour bloquer la création de branche au niveau racine de la hiérarchie. Dans l’exemple suivant, tout le monde peut créer des branches dans des dossiers tels que des utilisateurs/, des fonctionnalités/et des équipes/. Seuls les gestionnaires de versions ont l’autorisation de créer des branches sous versions/, et certains outils d’automatisation ont l’autorisation d’accéder au dossier /intégrations .

Flux de travail du référentiel Git

Dans le référentiel et la structure de branche, les développeurs effectuent leur travail quotidien. Les environnements de travail varient considérablement par équipe et par individu. Certains développeurs préfèrent la ligne de commande, d’autres comme Visual Studio et d’autres fonctionnent sur différentes plateformes. Les structures et les stratégies en place sur les référentiels Microsoft garantissent une base solide et cohérente.

Un workflow classique implique les tâches courantes suivantes :

Créer une nouvelle fonctionnalité

La création d’une nouvelle fonctionnalité est le cœur du travail d’un développeur de logiciels. Les parties non Git du processus incluent l’analyse des données de télémétrie, la conception et une spécification, et l’écriture du code réel. Ensuite, le développeur commence à utiliser le référentiel en se synchronisant avec la dernière validation sur main. La branche principale est toujours buildable, donc elle est garantie d’être un bon point de départ. Le développeur extrait une nouvelle branche dédiée aux fonctionnalités, apporte des modifications au code, valide, pousse sur le serveur et démarre une nouvelle pull request.

Utiliser des stratégies de branche et des vérifications

Lors de la création d'une pull request, les systèmes automatisés vérifient que le nouveau code se construit, ne casse rien et ne viole aucune politique de sécurité ou de conformité. Ce processus ne empêche pas d’autres tâches de se produire en parallèle.

Les stratégies de branche et les vérifications peuvent nécessiter une build réussie incluant des tests ayant réussi, la signature par les propriétaires de tout code touché et plusieurs vérifications externes pour vérifier les politiques d’entreprise avant qu'un pull request puisse être complété.

Intégration avec Microsoft Teams

De nombreuses équipes configurent l’intégration à Microsoft Teams, qui annonce la nouvelle pull request aux collègues développeurs. Les propriétaires de tout code touché sont automatiquement ajoutés en tant que réviseurs. Les équipes Microsoft utilisent souvent des réviseurs facultatifs pour le code que de nombreuses personnes touchent, comme la génération de clients REST et les contrôles partagés, pour obtenir des yeux d’experts sur ces modifications.

Déployer avec des indicateurs de fonctionnalité

Une fois que les réviseurs, les propriétaires de code et l’automatisation sont satisfaits, le développeur peut finaliser le pull request. S’il existe un conflit de fusion, le développeur obtient des instructions sur la synchronisation avec le conflit, la corriger et envoyer à nouveau les modifications. L’automatisation s’exécute à nouveau sur le code fixe, mais les humains n’ont pas à se reconnecter.

La branche se fusionne dans main, et le nouveau code se déploie dans le sprint ou la version majeure suivante. Cela ne signifie pas que la nouvelle fonctionnalité s’affiche immédiatement. Microsoft dissocie le déploiement et l’exposition de nouvelles fonctionnalités à l’aide d’indicateurs de fonctionnalité.

Même si la fonctionnalité a besoin d'un peu plus de travail avant qu'elle ne soit prête à être démontrée, il est sûr d'aller à main si le produit se compile et se déploie. Une fois dans main, le code fait partie d’une version officielle, où il est à nouveau testé, confirmé pour répondre à la politique et signé numériquement.

Déplacer vers la gauche pour détecter les problèmes tôt

Ce flux de travail Git offre plusieurs avantages. Tout d’abord, l’utilisation d’une seule branche principale élimine virtuellement la dette de fusion. Deuxièmement, le flux de pull request fournit un point commun pour l'application des tests, la révision du code et la détection des erreurs en amont du pipeline. Cette stratégie de décalage gauche permet de raccourcir le cycle de commentaires aux développeurs, car il peut détecter les erreurs en minutes, pas en heures ou en jours. Cette stratégie donne également confiance en la refactorisation, car toutes les modifications sont testées constamment.

Actuellement, un produit avec 200+ demandes de tirage peut produire 300+ builds d’intégration continue par jour, ce qui équivaut à 500+ exécutions de tests par jour. Ce niveau de test serait impossible sans le flux de travail de branchement et de mise en production basés sur la jonction.

Mise en production lors des étapes de sprint

À la fin de chaque sprint, l’équipe crée une branche de mise en production à partir de la branche principale. Par exemple, à la fin du sprint 129, l’équipe crée une nouvelle branche releases/M129de mise en production. L’équipe place ensuite la branche sprint 129 en production.

Après la création de la branche de release, la branche principale reste ouverte aux développeurs pour fusionner les modifications. Ces modifications seront déployées trois semaines plus tard dans le prochain déploiement sprint.

Correctifs d'urgence

Parfois, les changements doivent passer rapidement en production. Microsoft n’ajoute généralement pas de nouvelles fonctionnalités au milieu d’un sprint, mais souhaite parfois apporter rapidement un correctif de bogue pour débloquer les utilisateurs. Les problèmes peuvent être mineurs, tels que les fautes de frappe ou suffisamment volumineuses pour provoquer un problème de disponibilité ou un incident de site en direct.

La correction de ces problèmes commence par le flux de travail normal. Un développeur crée une branche à partir de main, fait examiner le code, et termine la pull request pour la fusion. Le processus commence toujours par apporter la modification en main premier. Cela permet de créer rapidement et de valider le correctif localement sans avoir à basculer vers la branche de mise en production.

Suivre ce processus garantit également que la modification est intégrée dans main, ce qui est essentiel. La correction d'un bogue dans la branche de mise en production sans ramener la modification en arrière main signifierait que le bogue réapparaîtrait pendant le déploiement suivant, lorsque les branches de version du sprint 130 partiront de main. Il est facile d’oublier de mettre à jour main pendant la confusion et le stress qui peut survenir pendant une panne. Le fait d’apporter des modifications main au préalable signifie toujours avoir les modifications dans la branche principale et dans la branche de mise en production.

La fonctionnalité Git active ce flux de travail. Pour apporter immédiatement des modifications en production, une fois qu’un développeur fusionne une pull requestmain, il peut utiliser la page de pull request pour prélever les modifications dans la branche de mise en production. Ce processus crée une nouvelle demande de tirage qui cible la branche de mise en production, en rétroportant le contenu qui vient d’être fusionné dans main.

L'utilisation de la fonctionnalité cherry-pick ouvre rapidement une requête de fusion, en fournissant la traçabilité et la fiabilité des politiques de branche. Le cherry-picking peut être effectué sur le serveur, sans avoir à télécharger la branche de version sur un ordinateur local. Apporter des modifications, résoudre des conflits de fusion ou apporter des modifications mineures en raison des différences entre les deux branches peut se produire sur le serveur. Les équipes peuvent apporter des modifications directement depuis l'éditeur de texte dans le navigateur ou via l’extension Pull Request Merge Conflict pour une expérience plus avancée.

Une fois qu'une pull request cible la branche de mise en production, l'équipe examine à nouveau le code, évalue les politiques de branche, teste la pull request et la fusionne. Après la fusion, le correctif est déployé sur le premier anneau de serveurs en minutes. À partir de là, l’équipe déploie progressivement le correctif sur davantage de comptes à l’aide d’anneaux de déploiement. À mesure que les modifications sont déployées sur d’autres utilisateurs, l’équipe surveille la réussite et vérifie que la modification corrige le bogue tout en n’introduisant pas de lacunes ou de ralentissements. Le correctif se déploie finalement sur tous les centres de données Azure.

Passer au sprint suivant

Au cours des trois prochaines semaines, l’équipe termine d’ajouter des fonctionnalités au sprint 130 et se prépare à déployer ces modifications. Ils créent la nouvelle branche de livraison à releases/M130 partir de main et déploient cette branche.

À ce stade, il y a en fait deux branches en production. Avec un déploiement en anneau pour apporter des modifications en production en toute sécurité, l’anneau rapide obtient les changements de la sprint 130 et les serveurs de l'anneau lent restent sur la sprint 129 alors que les nouvelles modifications sont validées dans l'environnement de production.

L'application d'un correctif au milieu d'un déploiement peut nécessiter l'application d'un correctif pour deux versions différentes, la version sprint 129 et la version sprint 130. L’équipe porte et déploie le correctif logiciel sur les deux branches de déploiement. La branche 130 est redéployée avec le correctif rapide sur les anneaux qui ont déjà été mis à niveau. La branche 129 se redéploie avec le correctif sur les anneaux externes qui n'ont pas encore été mis à niveau vers la version du prochain sprint.

Une fois que tous les anneaux sont déployés, l’ancienne branche sprint 129 est abandonnée, car toutes les modifications apportées à la branche sprint 129 en tant que correctif logiciel ont également été apportées dans main. Ainsi, ces modifications seront dans la branche releases/M130 également.

Résumé

Le modèle de flux de mise en production est au cœur de la façon dont Microsoft développe avec DevOps pour fournir des services en ligne. Ce modèle utilise une stratégie de branchement simple basée sur les jonctions. Mais au lieu de garder les développeurs bloqués dans une file d’attente de déploiement, en attendant de fusionner leurs modifications, le flux de publication Microsoft permet aux développeurs de continuer à travailler.

Ce modèle de mise en production permet également de déployer de nouvelles fonctionnalités dans des centres de données Azure à une cadence régulière, malgré la taille des bases de code Microsoft et le nombre de développeurs qui y travaillent. Le modèle permet également d’intégrer rapidement et efficacement les correctifs logiciels en production.