Déploiement et tests de charges de travail stratégiques sur Azure

Les déploiements ayant échoué et les versions erronées sont des causes courantes de pannes d’application. Votre approche du déploiement et des tests joue un rôle essentiel dans la fiabilité globale d’une application stratégique.

Le déploiement et les tests doivent constituer la base de toutes les opérations d’application et d’infrastructure pour garantir des résultats cohérents pour les charges de travail stratégiques. Préparez-vous à déployer chaque semaine, tous les jours ou plus souvent. Concevez vos pipelines d’intégration continue et de déploiement continu (CI/CD) pour prendre en charge ces objectifs.

La stratégie doit implémenter :

• Tests préversion rigoureux. Les mises à jour ne doivent pas introduire de défauts, de vulnérabilités ou d’autres facteurs susceptibles de compromettre l’intégrité de l’application.

• Déploiements transparents. Il doit être possible de déployer des mises à jour à tout moment sans affecter les utilisateurs. Les utilisateurs doivent pouvoir poursuivre leurs interactions avec l’application sans interruption.

• Opérations hautement disponibles. Les processus et les outils de déploiement et de test doivent être hautement disponibles pour prendre en charge la fiabilité globale des applications.

• Processus de déploiement cohérents. Les mêmes artefacts et processus d’application doivent être utilisés pour déployer l’infrastructure et le code d’application dans différents environnements. L’automatisation de bout en bout est obligatoire. Les interventions manuelles doivent être évitées, car elles peuvent présenter des risques de fiabilité.

Cette zone de conception fournit des recommandations sur la façon d’optimiser les processus de déploiement et de test afin de réduire les temps d’arrêt et de maintenir l’intégrité et la disponibilité des applications.

Important

Cet article fait partie de la série de charges de travail stratégiques Azure Well-Architected Framework. Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par Qu’est-ce qu’une charge de travail stratégique ?.

Déploiement sans temps d’arrêt

Affichez la vidéo suivante pour obtenir une vue d’ensemble du déploiement sans temps d’arrêt.

La réalisation de déploiements sans temps d’arrêt est un objectif fondamental pour les applications stratégiques. Votre application doit être disponible tous les jours, tous les jours, même lorsque de nouvelles versions sont déployées pendant les heures d’ouverture. Investissez vos efforts à l’avant-plan pour définir et planifier des processus de déploiement afin de prendre des décisions de conception clés telles que le traitement des ressources comme éphémères.

Pour effectuer un déploiement sans temps d’arrêt, déployez une nouvelle infrastructure en regard de l’infrastructure existante, testez-la minutieusement, effectuez la transition du trafic utilisateur final, puis désactivez uniquement l’infrastructure précédente. D’autres pratiques, comme l’architecture d’unité d’échelle, sont également essentielles.

Les implémentations de référence connectées mission-critique et Azure Stratégique illustrent cette approche de déploiement, comme illustré dans ce diagramme :

Environnements d’application

Affichez la vidéo suivante pour obtenir une vue d’ensemble des recommandations pour les environnements d’application.

Vous avez besoin de différents types d’environnements pour valider et mettre en scène les opérations de déploiement. Les types ont des fonctionnalités et des cycles de vie différents. Certains environnements peuvent refléter l’environnement de production et être de longue durée, et d’autres peuvent être de courte durée et avoir moins de capacités que la production. La configuration de ces environnements au début du cycle de développement permet de garantir l’agilité, la séparation des ressources de production et de préproduction, ainsi que des tests approfondis des opérations avant la mise en production dans l’environnement de production. Tous les environnements doivent refléter l’environnement de production autant que possible, bien que vous puissiez appliquer des simplifications aux environnements inférieurs si nécessaire. Ce diagramme montre une architecture stratégique :

Il existe quelques considérations courantes :

• Les composants ne doivent pas être partagés entre les environnements. Les exceptions possibles sont des appliances de sécurité en aval telles que des pare-feu et des emplacements sources pour les données de test synthétiques.

• Tous les environnements doivent utiliser l’infrastructure en tant qu’artefacts de code (IaC), tels que Terraform ou Azure Resource Manager (ARM).

Environnements de développement

Consultez la vidéo suivante pour plus d’informations sur les environnements de développement éphémères et la validation automatisée des fonctionnalités.

Considérations sur la conception

• Fonctionnalités. Les exigences inférieures en matière de fiabilité, de capacité et de sécurité sont acceptables pour les environnements de développement.

• Cycle de vie. Les environnements de développement doivent être créés en fonction des besoins et exister pendant une courte période. Les cycles de vie plus courts permettent d’empêcher la dérive de la configuration de la base de code et de réduire les coûts. Par ailleurs, les environnements de développement partagent souvent le cycle de vie d’une branche de fonctionnalités.

• Densité. Teams a besoin de plusieurs environnements pour prendre en charge le développement de fonctionnalités parallèles. Ils peuvent coexister au sein d’un seul abonnement.

Recommandations de conception

• Conservez l’environnement dans un abonnement dédié avec un contexte défini à des fins de développement.

• Utilisez un processus automatisé pour déployer du code à partir d’un branche de fonctionnalité dans un environnement de développement.

Environnements de test ou de préproduction

Ces environnements sont utilisés pour les tests et la validation. De nombreux cycles de test sont effectués pour garantir un déploiement sans bogue en production. Les tests appropriés pour une charge de travail stratégique sont décrits dans la section Validation et test continus.

Considérations sur la conception

• Fonctionnalités. Ces environnements doivent refléter l’environnement de production pour la fiabilité, la capacité et la sécurité. En l’absence de charge de production, utilisez une charge utilisateur synthétique pour fournir des métriques réalistes et une entrée de modélisation d’intégrité précieuse.

• Cycle de vie. Ces environnements sont de courte durée. Elles doivent être détruites une fois les validations de test terminées.

• Densité. Vous pouvez exécuter de nombreux environnements indépendants dans un abonnement. Vous devez également envisager d’utiliser plusieurs environnements, chacun dans un abonnement dédié.

Remarque

Les applications critiques doivent être soumises à des tests rigoureux.

Vous pouvez effectuer différentes fonctions de test dans un seul environnement, et dans certains cas, vous devrez le faire. Par exemple, pour que les tests de chaos fournissent des résultats significatifs, vous devez d’abord placer l’application sous charge afin de comprendre comment l’application répond aux erreurs injectées. C’est pourquoi les tests de chaos et les tests de charge sont généralement effectués en parallèle.

Recommandations de conception

• Assurez-vous qu’au moins un environnement intermédiaire reflète entièrement la production pour activer les tests et la validation de type production. La capacité au sein de cet environnement peut s’adapter en fonction de l’exécution des activités de test.

• Générez une charge utilisateur synthétique pour fournir un cas de test réaliste pour les modifications apportées à l’un des environnements.

  Remarque

  L’implémentation de référence Mission Critical Online fournit un exemple de générateur de charge utilisateur.

• Définissez le nombre d’environnements intermédiaires et leurs objectifs dans le cycle de développement et de mise en production.

Environnements de production

Considérations sur la conception

• Fonctionnalités. Les niveaux de fiabilité, de capacité et de sécurité les plus élevés pour l’application sont requis.

• Cycle de vie. Bien que le cycle de vie de la charge de travail et de l’infrastructure reste le même, toutes les données, notamment la surveillance et la journalisation, nécessitent une gestion spéciale. Par exemple, la gestion est requise pour la sauvegarde et la récupération.

• Densité. Pour certaines applications, vous pouvez envisager d’utiliser différents environnements de production pour répondre à différents clients, utilisateurs ou fonctionnalités métier.

Recommandations de conception

Disposez d’une limite de gouvernance claire pour les environnements de production et les environnements inférieurs. Placez chaque type d’environnement dans un abonnement dédié pour atteindre cet objectif. Cette segmentation garantit que l’utilisation des ressources dans des environnements inférieurs n’affecte pas les quotas de production. Les abonnements dédiés définissent également des limites d’accès.

Déploiements bleus/verts éphémères

Un modèle de déploiement bleu/vert nécessite au moins deux déploiements identiques. Le déploiement bleu est le déploiement actif qui sert le trafic utilisateur en production. Le déploiement vert est le nouveau qui est préparé et testé pour recevoir le trafic. Une fois le déploiement vert terminé et testé, le trafic est progressivement dirigé du bleu au vert. Si le transfert de charge réussit, le déploiement vert devient le nouveau déploiement actif. L’ancien déploiement bleu peut ensuite être désactivé via un processus par phases. Toutefois, s’il existe des problèmes dans le nouveau déploiement, il peut être abandonné et le trafic peut rester dans l’ancien déploiement bleu ou être redirigé vers celui-ci.

Azure Mission-Critical recommande une approche de déploiement bleu/vert où l’infrastructure et les applications sont déployées ensemble dans le cadre d’un tampon de déploiement. Par conséquent, le déploiement d’une modification de l’infrastructure ou de l’application entraîne toujours un déploiement vert qui contient les deux couches. Cette approche vous permet de tester et de valider entièrement l’effet de la modification par rapport à l’infrastructure et à l’application de bout en bout avant de rediriger le trafic utilisateur vers celui-ci. L’approche augmente la confiance en la libération des modifications et active les mises à niveau sans temps d’arrêt, car les compatibilités avec les dépendances en aval telles que la plateforme Azure, les fournisseurs de ressources et les modules IaC peuvent être validées.

Considérations sur la conception

• Fonctionnalités technologiques. Tirez parti des fonctionnalités de déploiement intégrées dans les services Azure. Par exemple, Azure App Service fournit des emplacements de déploiement secondaires qui peuvent être échangés après un déploiement. Avec Azure Kubernetes Service (AKS), vous pouvez utiliser un déploiement de pods distinct sur chaque nœud et mettre à jour la définition du service.

• Durée du déploiement. Le déploiement peut prendre plus de temps, car l’empreinte contient l’infrastructure et l’application plutôt que simplement le composant modifié. Toutefois, cela est acceptable, car le risque de tous les composants ne fonctionne pas comme prévu remplace les problèmes de temps.

• Impact sur les coûts. Il existe un coût supplémentaire en raison des deux déploiements côte à côte, qui doivent coexister jusqu’à ce que le déploiement soit terminé.

• Transition du trafic. Une fois le nouveau déploiement validé, le trafic doit être passé de l’environnement bleu à l’environnement vert. Cette transition nécessite l’orchestration du trafic utilisateur entre les environnements. La transition doit être entièrement automatisée.

• Cycle de vie. Les tampons de déploiement stratégiques doivent être considérés comme éphémères. L’utilisation de tampons de courte durée crée un nouveau démarrage chaque fois, avant que les ressources ne soient approvisionnées.

Recommandations de conception

• Adoptez une approche de déploiement bleu/vert pour libérer toutes les modifications de production. Déployez toutes les infrastructures et l’application chaque fois, pour tout type de modification, afin d’obtenir un état cohérent et zéro temps d’arrêt. Bien que vous puissiez réutiliser des environnements, nous ne le recommandons pas pour les charges de travail stratégiques. Traitez chaque tampon de déploiement régional comme éphémère avec un cycle de vie lié à celui d’une seule version.

• Utilisez un équilibreur de charge global, comme Azure Front Door, pour orchestrer la transition automatisée du trafic utilisateur entre les environnements bleu et vert.

• Pour passer du trafic, ajoutez un point de terminaison back-end vert qui utilise un trafic faible pour le poids du volume, comme 10 %. Après avoir vérifié que le volume de trafic faible sur le déploiement vert fonctionne et fournit l’intégrité de l’application attendue, augmentez progressivement le trafic. Dans ce cas, appliquez une courte période de montée en puissance pour intercepter les erreurs qui peuvent ne pas être immédiatement apparentes.

  Une fois que tout le trafic est passé, supprimez le back-end bleu des connexions existantes. Par exemple, supprimez le back-end du service d’équilibreur de charge global, drainez les files d’attente et détachez d’autres associations. Cela permet d’optimiser le coût de maintenance de l’infrastructure de production secondaire et de s’assurer que de nouveaux environnements sont exempts de dérive de configuration.

  À ce stade, désaffectez l’ancien environnement bleu inactif. Pour le déploiement suivant, répétez le processus avec le bleu et le vert inversé.

Déploiement dans l’étendue de l’abonnement

Selon les exigences de mise à l’échelle de votre application, vous devrez peut-être utiliser plusieurs abonnements de production pour servir d’unités d’échelle.

Consultez la vidéo suivante pour obtenir une vue d’ensemble des recommandations relatives aux abonnements d’étendue pour une application stratégique.

Considérations sur la conception

• Scalabilité. Pour les scénarios d’application à grande échelle avec des volumes importants de trafic, concevez la solution pour effectuer une mise à l’échelle sur plusieurs abonnements Azure afin que les limites d’échelle d’un seul abonnement ne limitent pas l’extensibilité.

  Important

  L’utilisation de plusieurs abonnements nécessite une complexité CI/CD supplémentaire, qui doit être gérée de manière appropriée. Par conséquent, nous recommandons plusieurs abonnements uniquement dans des scénarios à grande échelle, où les limites d’un seul abonnement sont susceptibles de devenir une limitation.

• Limites de l’environnement. Déployez des environnements de production, de développement et de test dans des abonnements distincts. Cette pratique garantit que les environnements inférieurs ne contribuent pas aux limites de mise à l’échelle. Elle réduit également le risque de mises à jour de l’environnement inférieur en fournissant une gestion claire et une limite d’identité.

• Gouvernance. Lorsque vous avez besoin de plusieurs abonnements de production, envisagez d’utiliser un groupe d’administration d’applications dédié pour simplifier l’attribution de stratégie via une limite d’agrégation de stratégie.

Recommandations de conception

• Déployez chaque tampon de déploiement régional dans un abonnement dédié pour vous assurer que les limites d’abonnement s’appliquent uniquement dans le contexte d’un tampon de déploiement unique et non dans l’ensemble de l’application. Le cas échéant, vous pouvez envisager d’utiliser plusieurs tampons de déploiement dans une seule région, mais vous devez les déployer dans des abonnements indépendants.

• Placez des ressources partagées globales dans un abonnement dédié pour permettre un déploiement d’abonnement régional cohérent. Évitez d’utiliser un déploiement spécialisé pour la région primaire.

Validation et test continus

Le test est une activité critique qui vous permet de valider entièrement l’intégrité du code et de l’infrastructure de votre application. Plus précisément, les tests vous permettent de répondre à vos normes pour la fiabilité, les performances, la disponibilité, la sécurité, la qualité et la mise à l’échelle. Les tests doivent être bien définis et appliqués dans le cadre de la conception de votre application et de votre stratégie DevOps. Le test est un problème clé pendant le processus de développement local (la boucle interne) et dans le cadre du cycle de vie DevOps complet (boucle externe), c’est-à-dire lorsque le code démarre sur le chemin d’accès des processus de pipeline de mise en production vers l’environnement de production.

Affichez la vidéo suivante pour obtenir une vue d’ensemble de la validation et des tests continus.

Cette section se concentre sur les tests de boucle externe. Il décrit différents types de tests.

Test	Description
Test des unités	Confirme que la logique métier de l’application fonctionne comme prévu. Valide l’effet global des modifications de code.
Test de fumée	Identifie si les composants d’infrastructure et d’application sont disponibles et fonctionnent comme prévu. En règle générale, une seule session utilisateur virtuel est testée. Le résultat doit être que le système répond avec les valeurs et le comportement attendus. Les scénarios courants de test de fumée incluent l’atteinte du point de terminaison HTTPS d’une application web, l’interrogation d’une base de données et la simulation d’un flux utilisateur dans l’application.
Test de l’interface utilisateur	Valide que les interfaces utilisateur de l’application sont déployées et que les interactions avec l’interface utilisateur fonctionnent comme prévu. Vous devez utiliser les outils d’automatisation de l’interface utilisateur pour stimuler l’automatisation. Pendant un test d’interface utilisateur, un script doit imiter un scénario utilisateur réaliste et effectuer une série d’étapes pour exécuter des actions et obtenir un résultat prévu.
Test de charge	Valide l’évolutivité et l’opération d’application en augmentant la charge rapidement et/ou progressivement jusqu’à ce qu’un seuil prédéterminé soit atteint. Les tests de charge sont généralement conçus autour d’un flux utilisateur particulier pour vérifier que les exigences de l’application sont satisfaites sous une charge définie.
Test de stress	Applique les activités qui surchargent les ressources existantes pour déterminer les limites de solution et vérifier la capacité du système à récupérer correctement. L’objectif principal est d’identifier les goulots d’étranglement potentiels des performances et les limites de mise à l’échelle. À l’inverse, effectuez un scale-down des ressources informatiques du système et surveillez son comportement sous la charge et déterminez s’il peut récupérer.
Tests de performances	Combine les aspects des tests de charge et de contrainte pour valider les performances en cours de charge et établir des comportements d’évaluation pour l’opération d’application.
Test de chaos	Injecte des défaillances artificielles dans le système pour évaluer sa réaction et valider l’efficacité des mesures de résilience, des procédures opérationnelles et des atténuations. L’arrêt des composants d’infrastructure, la dégradation des performances et l’introduction des erreurs d’application sont des exemples de tests qui peuvent être utilisés pour vérifier que l’application réagira comme prévu lorsque les scénarios se produisent réellement.
Test de pénétration	Garantit qu’une application et son environnement répondent aux exigences d’une posture de sécurité attendue. L’objectif est d’identifier les vulnérabilités de sécurité. Les tests de sécurité peuvent inclure la chaîne d’approvisionnement logicielle de bout en bout et les dépendances de package, avec l’analyse et la surveillance des vulnérabilités et des expositions courantes connues (CVE).

Considérations sur la conception

• Automatisation. Les tests automatisés sont essentiels pour valider les modifications d’application ou d’infrastructure en temps voulu et reproductibles.

• Ordre de test. L’ordre dans lequel les tests sont effectués est une considération critique en raison de diverses dépendances, comme la nécessité d’avoir un environnement d’application en cours d’exécution. La durée du test influence également l’ordre. Les tests avec des temps d’exécution plus courts doivent s’exécuter plus tôt dans le cycle lorsque cela est possible pour augmenter l’efficacité des tests.

• Limites de scalabilité. Les services Azure ont des limites souples et difficiles différentes. Envisagez d’utiliser des tests de charge pour déterminer si un système risque de les dépasser pendant la charge de production attendue. Les tests de charge peuvent également être utiles pour définir les seuils appropriés pour la mise à l’échelle automatique. Pour les services qui ne prennent pas en charge la mise à l’échelle automatique, les tests de charge peuvent vous aider à affiner les procédures opérationnelles automatisées.

  L’incapacité des composants système, comme les composants réseau actifs/passifs ou les bases de données, à mettre à l’échelle de manière appropriée peut être restrictive. Les tests de stress peuvent aider à identifier les limitations.

• Analyse du mode d’échec. L’introduction de pannes dans l’application et l’infrastructure sous-jacente et l’évaluation de l’effet est essentielle pour évaluer les mécanismes de redondance de la solution. Pendant cette analyse, identifiez le risque, l’impact et l’étendue de l’impact (panne partielle ou complète). Pour obtenir un exemple d’analyse qui a été créé pour l’implémentation de référence Mission Critical Online , consultez les risques de panne des composants individuels.

• Supervision. Vous devez capturer et analyser les résultats des tests individuellement et les agréger pour évaluer les tendances au fil du temps. Vous devez évaluer continuellement les résultats des tests pour obtenir une précision et une couverture.

Recommandations de conception

Consultez la vidéo suivante pour voir comment les tests de résilience peuvent être intégrés aux pipelines CI/CD Azure DevOps.

• Assurez-vous de la cohérence en automatisant tous les tests sur les composants d’infrastructure et d’application. Intégrez les tests dans les pipelines CI/CD pour orchestrer et les exécuter le cas échéant. Pour plus d’informations sur les options technologiques, consultez les outils DevOps.

• Traitez tous les artefacts de test comme du code. Ils doivent être gérés et contrôlés par version avec d’autres artefacts de code d’application.

• Aligner le contrat SLA de l’infrastructure de test avec le contrat SLA pour les cycles de déploiement et de test.

• Exécutez des tests de fumée dans le cadre de chaque déploiement. Exécutez également des tests de charge étendus, ainsi que des tests de contrainte et de chaos pour vérifier que les performances et l’opéraabilité des applications sont conservées.

  • Utilisez des profils de charge qui reflètent des modèles d’utilisation de pointe réels.
  • Exécutez des expériences de chaos et des tests d’injection d’échec en même temps que des tests de charge.

  Conseil

  Azure Chaos Studio est une suite native d’outils d’expérimentation de chaos. Les outils facilitent la conduite d’expériences de chaos et l’injection d’erreurs dans les services Azure et les composants d’application.

  Chaos Studio fournit des expériences de chaos intégrées pour les scénarios d’erreur courants et prend en charge les expériences personnalisées qui ciblent les composants d’infrastructure et d’application.

• Si des interactions de base de données, telles que la création d’enregistrements, sont requises pour les tests de charge ou de fumée, utilisez des comptes de test qui ont des privilèges réduits et séparent les données de test à partir du contenu réel de l’utilisateur.

• Analysez et surveillez la chaîne d’approvisionnement logicielle de bout en bout et les dépendances de package pour les cvEs connues.

  • Utilisez Dependabot pour les dépôts GitHub pour vous assurer que le référentiel est automatiquement à jour avec les dernières versions de packages et d’applications dont il dépend.

Infrastructure en tant que déploiements de code

L’infrastructure en tant que code (IaC) traite les définitions d’infrastructure comme du code source contrôlé par la version, ainsi que d’autres artefacts d’application. L’utilisation d’IaC favorise la cohérence du code entre les environnements, élimine le risque d’erreur humaine pendant les déploiements automatisés et assure la traçabilité et la restauration. Pour les déploiements bleus/verts, l’utilisation d’IaC avec des déploiements entièrement automatisés est impérative.

Un référentiel IaC critique a deux définitions distinctes mappées aux ressources globales et régionales. Pour plus d’informations sur ces types de ressources, consultez le modèle d’architecture principal.

Considérations sur la conception

• Infrastructure reproductible. Déployez des charges de travail stratégiques d’une manière qui génère le même environnement à chaque fois. IaC doit être le modèle principal.

• Automatisation. Tous les déploiements doivent être entièrement automatisés. Les processus humains sont sujets à des erreurs.

Recommandations de conception

• Appliquez IaC, en veillant à ce que toutes les ressources Azure soient définies dans des modèles déclaratifs et conservées dans un référentiel de contrôle de code source. Les modèles sont déployés et les ressources sont approvisionnées automatiquement à partir du contrôle de code source via des pipelines CI/CD. Nous vous déconseillons d’utiliser des scripts impératifs.

• Interdire les opérations manuelles sur tous les environnements. La seule exception est des environnements de développement entièrement indépendants.

Outils de DevOps

L’utilisation efficace des outils de déploiement est essentielle à la fiabilité globale, car les processus DevOps affectent la fonction globale et la conception d’application. Par exemple, les opérations de basculement et de mise à l’échelle peuvent dépendre de l’automatisation fournie par les outils DevOps. Les équipes d’ingénierie doivent comprendre l’effet de l’indisponibilité d’un service de déploiement par rapport à la charge de travail globale. Les outils de déploiement doivent être fiables et hautement disponibles.

Microsoft fournit deux ensembles d’outils natifs Azure, GitHub Actions et Azure Pipelines, qui peuvent déployer et gérer efficacement une application stratégique.

Considérations sur la conception

• Fonctionnalités technologiques. Les fonctionnalités de GitHub et d’Azure DevOps se chevauchent. Vous pouvez les utiliser ensemble pour obtenir le meilleur des deux. Une approche courante consiste à stocker des référentiels de code dans GitHub.com ou GitHub AE lors de l’utilisation d’Azure Pipelines pour le déploiement.

  Tenez compte de la complexité ajoutée lorsque vous utilisez plusieurs technologies. Évaluez un ensemble complet de fonctionnalités par rapport à la fiabilité globale.

• Disponibilité régionale. En termes de fiabilité maximale, la dépendance à une seule région Azure représente un risque opérationnel.

  Par exemple, supposons que le trafic est réparti sur deux régions : région 1 et région 2. La région 2 héberge l’instance d’outils Azure DevOps. Supposons qu’il existe une panne dans la région 2 et que l’instance n’est pas disponible. La région 1 gère automatiquement tout le trafic et doit déployer des unités d’échelle supplémentaires pour offrir une bonne expérience de basculement. Mais elle ne pourra pas être due à la dépendance Azure DevOps dans la région 2.

• Réplication des données. Les données, y compris les métadonnées, les pipelines et le code source, doivent être répliquées entre les régions.

Recommandations de conception

• Les deux technologies sont hébergées dans une seule région Azure, ce qui peut rendre votre stratégie de récupération d’urgence restrictive.

  GitHub Actions est bien adapté aux tâches de génération (intégration continue), mais peut ne pas avoir de fonctionnalités pour les tâches de déploiement complexes (déploiement continu). Étant donné l’ensemble de fonctionnalités riche d’Azure DevOps, nous vous recommandons de le faire pour les déploiements stratégiques. Toutefois, vous devez faire un choix après avoir évalué les compromis.

• Définissez un contrat SLA de disponibilité pour les outils de déploiement et vérifiez l’alignement avec des exigences de fiabilité d’application plus larges.

• Pour les scénarios multirégions qui utilisent une configuration de déploiement actif/passif ou actif/actif/actif, assurez-vous que les opérations d’orchestration et de mise à l’échelle de basculement peuvent continuer à fonctionner même si les ensembles d’outils de déploiement d’hébergement de région principale ne sont plus disponibles.

Stratégie de création de branches

Il existe de nombreuses approches valides pour la branchement. Vous devez choisir une stratégie qui garantit une fiabilité maximale. Une bonne stratégie permet le développement parallèle, fournit un chemin clair du développement à la production et prend en charge les versions rapides.

Considérations sur la conception

• Réduisez l’accès. Les développeurs doivent effectuer leur travail dans et fix/* les feature/* branches. Ces branches deviennent des points d’entrée pour les modifications. Les restrictions basées sur les rôles doivent être appliquées aux branches dans le cadre de la stratégie de branchement. Par exemple, autorisez uniquement les administrateurs à créer des branches de mise en production ou à appliquer des conventions d’affectation de noms pour les branches.

• Processus accéléré pour les urgences. La stratégie de branchement doit permettre la fusion main des correctifs logiciels dès que possible. Ainsi, les versions ultérieures contiennent le correctif et la périodicité du problème est évitée. Utilisez ce processus uniquement pour les modifications mineures qui traitent des problèmes urgents et utilisez-le avec contrainte.

Recommandations de conception

• Hiérarchiser l’utilisation de GitHub pour le contrôle de code source.

  Important

  Créez une stratégie de branche qui détaille le travail et les mises en production des fonctionnalités au minimum, et utilisez des stratégies et des autorisations de branche pour vous assurer que la stratégie est correctement appliquée.

• Déclenchez un processus de test automatisé pour valider les contributions aux modifications de code avant qu’elles ne soient acceptées. Les membres de l’équipe doivent également passer en revue les modifications.

• Traitez la branche comme une branche en constante progression et stable qui est principalement utilisée pour les main tests d’intégration.

  • Vérifiez que les modifications sont apportées main uniquement via des demandes de tirage. Utilisez une stratégie de branche pour interdire les validations directes.
  • Chaque fois qu’une demande de tirage est fusionnée main, elle doit lancer automatiquement un déploiement sur un environnement d’intégration.
  • La main branche doit être considérée comme stable. Il doit être sûr de créer une version à partir d’un main moment donné.

• Utilisez des branches dédiées release/* créées à partir de la main branche et utilisées pour le déploiement dans des environnements de production. release/* les branches doivent rester dans le référentiel et peuvent être utilisées pour corriger une version.

• Documentez un processus de correctif logiciel et utilisez-le uniquement si nécessaire. Créez des correctifs logiciels dans une fix/* branche pour la fusion ultérieure dans la branche release et le déploiement en production.

l’IA pour DevOps

Vous pouvez appliquer des méthodologies AIOps dans des pipelines CI/CD pour compléter les approches de test traditionnelles. Cela permet de détecter les régressions potentielles ou les dégradations et permet aux déploiements d’être préemptivement arrêtés pour empêcher les impacts négatifs potentiels.

Considérations sur la conception

• Volume de données de télémétrie. Les pipelines CI/CD et les processus DevOps émettent une grande variété de données de télémétrie pour les modèles Machine Learning. Les données de télémétrie vont des résultats de test et des résultats de déploiement aux données opérationnelles sur les composants de test à partir des phases de déploiement composite.

• Scalabilité. Les approches traditionnelles de traitement des données telles que Extract, Transform, Load (ETL) peuvent ne pas être en mesure de mettre à l’échelle le débit pour suivre la croissance des données de télémétrie de déploiement et d’observabilité des applications. Vous pouvez utiliser des approches d’analytique modernes qui n’ont pas besoin d’ETL et de déplacement de données, comme la virtualisation des données, pour activer l’analyse continue par les modèles AIOps.

• Modifications du déploiement. Les modifications apportées au déploiement doivent être stockées pour l’analyse automatisée et la corrélation avec les résultats du déploiement.

Recommandations de conception

• Définissez les données de processus DevOps pour collecter et comment les analyser. La télémétrie, comme les métriques d’exécution des tests et les données de série chronologique des modifications au sein de chaque déploiement, est importante.

  • Exposez les données d’observabilité des applications à partir d’environnements de préproduction, de test et de production pour l’analyse et la corrélation dans les modèles AIOps.

• Adoptez le flux de travail MLOps.

• Développez des modèles analytiques prenant en charge le contexte et prenant en charge les dépendances pour fournir des prédictions avec l’ingénierie automatisée des fonctionnalités pour traiter les changements de schéma et de comportement.

• Opérationnalisez les modèles en inscrivant et en déployant les modèles les mieux formés dans les pipelines de déploiement.

Étape suivante

Passez en revue les considérations de sécurité.

Sécurité