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

Les déploiements ayant échoué et les mises en production 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 afin de 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 rigoureux en préversion. Mises à jour ne doit 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 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 dans le but 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 critiques 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

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

Atteindre des déploiements sans temps d’arrêt est un objectif fondamental pour les applications stratégiques. Votre application doit être disponible toute la journée, tous les jours, même lorsque de nouvelles versions sont déployées pendant les heures d’ouverture. Déployez vos efforts à l’avance pour définir et planifier des processus de déploiement afin de prendre des décisions de conception clés, telles que le fait de traiter les ressources comme éphémères.

Pour obtenir un déploiement sans temps d’arrêt, déployez une nouvelle infrastructure à côté de l’infrastructure existante, testez-la minutieusement, effectuez la transition du trafic des utilisateurs finaux, puis désaffectez l’infrastructure précédente. D’autres pratiques, telles que l’architecture d’unité d’échelle, sont également essentielles.

Les implémentations de référence Mission-Critical Online et Azure Mission-Critical Connected illustrent cette approche de déploiement, comme illustré dans ce diagramme :

Environnements d’application

Regardez 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, tandis que d’autres peuvent être de courte durée et avoir moins de fonctionnalité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 autant que possible l’environnement de production, 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 les appliances de sécurité en aval comme les pare-feu et les emplacements sources pour les données de test synthétiques.

• Tous les environnements doivent utiliser des artefacts d’infrastructure en tant que code (IaC) comme Terraform ou des modèles Azure Resource Manager (ARM).

Environnements de développement

Regardez 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.

Remarques relatives à la conception

• Fonctionnalités. Des exigences plus faibles 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. Des cycles de vie plus courts permettent d’éviter la dérive de la configuration à partir 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 bogues en production. Les tests appropriés pour une charge de travail stratégique sont décrits dans la section Validation et test continus .

Remarques relatives à 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 d’une charge de production, utilisez une charge utilisateur synthétique pour fournir des métriques réalistes et des entrées de modélisation d’intégrité précieuses.

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

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

Notes

Les applications stratégiques doivent être soumises à des tests rigoureux.

Vous pouvez effectuer différentes fonctions de test dans un même environnement, et dans certains cas, vous en aurez besoin. 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 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 permettre le test et la validation de type production. La capacité au sein de cet environnement peut être flexible 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 sur l’un des environnements.

  Notes

  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.

Les environnements de production

Remarques relatives à la conception

• Fonctionnalités. Les niveaux de fiabilité, de capacité et de fonctionnalités 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, y compris la surveillance et la journalisation, ont besoin d’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 aux besoins de différents clients, utilisateurs ou fonctionnalités métier.

Recommandations de conception

Avoir 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 les 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 bleu/vert éphémères

Un modèle de déploiement bleu/vert nécessite au moins deux déploiements identiques. Le déploiement bleu est celui 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 vers le 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, celui-ci peut être abandonné et le trafic peut rester dans l’ancien déploiement bleu ou y être redirigé.

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 sur l’infrastructure et l’application de bout en bout avant de rediriger le trafic utilisateur vers celle-ci. L’approche augmente la confiance dans la publication des modifications et permet des mises à niveau sans temps d’arrêt, car les compatibilités avec des dépendances en aval telles que la plateforme Azure, les fournisseurs de ressources et les modules IaC peuvent être validées.

Remarques relatives à 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 pod 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 que tous les composants ne fonctionnent pas comme prévu remplace les problèmes de temps.

• Impact sur les coûts. Il y a 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 empreintes de déploiement stratégiques doivent être considérées comme éphémères. L’utilisation d’empreintes de courte durée crée un nouveau départ à 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 l’ensemble de l’infrastructure et l’application à chaque fois, pour n’importe quel type de modification, afin d’obtenir un état cohérent et aucun 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 empreinte 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 effectuer la transition du trafic, ajoutez un point de terminaison principal vert qui utilise un faible trafic au poids du volume, par exemple 10 %. Une fois que vous avez vérifié que le faible volume de trafic sur le déploiement vert fonctionne et fournit l’intégrité attendue de l’application, 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.

  Après la transition de tout le trafic, supprimez le back-end bleu des connexions existantes. Pour instance, supprimez le back-end du service d’équilibreur de charge global, videz les files d’attente et détachez les autres associations. Cela permet d’optimiser le coût de maintenance de l’infrastructure de production secondaire et de garantir que les nouveaux environnements sont exempts de dérives de configuration.

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

Déploiement étendu à l’abonnement

Selon les exigences de mise à l’échelle de votre application, vous pouvez avoir besoin de plusieurs abonnements de production pour servir d’unités de mise à l’échelle.

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

Remarques relatives à la conception

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

  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 d’échelle extrême, 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. Il réduit également le risque de pollution de la production par des mises à jour plus faibles de l’environnement en fournissant une limite claire de gestion et 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 empreinte 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 empreintes de déploiement dans une même région, mais vous devez les déployer sur 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 spécifiquement, les tests vous permettent de répondre à vos normes en matière de fiabilité, de performances, de disponibilité, de sécurité, de qualité et de 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 une préoccupation clé pendant le processus de développement local (la boucle interne) et dans le cadre du cycle de vie DevOps complet ( la 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.

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

Cette section se concentre sur le test 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.
Tests de l’interface utilisateur	Valide que les interfaces utilisateur d’application sont déployées et que les interactions d’interface utilisateur fonctionnent comme prévu. Vous devez utiliser les outils d’automatisation de l’interface utilisateur pour favoriser 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 atteindre un résultat prévu.
Test de charge	Valide la scalabilité et le fonctionnement de l’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 contrainte	Applique des activités qui surchargent les ressources existantes pour déterminer les limites de la solution et vérifier la capacité du système à récupérer correctement. L’objectif main est d’identifier les goulots d’étranglement des performances potentiels et les limites de mise à l’échelle. À l’inverse, effectuez un scale-down des ressources informatiques du système et surveillez son comportement sous charge et déterminez s’il peut être récupéré.
Tests de performances	Combine les aspects du test de charge et de contrainte pour valider les performances sous charge et établir des comportements de benchmark pour le fonctionnement de l’application.
Tests de chaos	Injecte des défaillances artificielles dans le système pour évaluer sa façon de réagir et pour 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 d’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 failles de sécurité. Les tests de sécurité peuvent inclure des dépendances de chaîne d’approvisionnement logicielle et de package de bout en bout, avec l’analyse et la surveillance des vulnérabilités et des expositions courantes (CVE).

Remarques relatives à la conception

• Automatisation. Les tests automatisés sont essentiels pour valider les modifications apportées à l’application ou à l’infrastructure de manière rapide et reproductible.

• Ordre de test. L’ordre dans lequel les tests sont effectués est un facteur critique en raison de diverses dépendances, telles que 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 matérielles 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. Le test de charge peut également être utile pour définir des 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, tels que les bases de données ou les composants réseau actifs/passifs, à une mise à l’échelle appropriée peut être restrictive. Les tests de contrainte peuvent aider à identifier les limitations.

• Analyse du mode d’échec. L’introduction d’erreurs dans l’application et l’infrastructure sous-jacente et l’évaluation de l’effet sont essentielles pour évaluer les mécanismes de redondance de la solution. Au cours de cette analyse, identifiez le risque, l’impact et l’ampleur 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 Risques de panne de 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 la précision et la couverture.

Recommandations de conception

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

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

• Traitez tous les artefacts de test comme du code. Elles doivent être conservées et contrôlées par version, ainsi que d’autres artefacts de code d’application.

• Alignez 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érabilité 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 de défaillance 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 réalisation d’expériences de chaos et l’injection d’erreurs dans les services Et les composants d’application Azure.

  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 rendez les données de test séparables du contenu utilisateur réel.

• Analysez et surveillez les dépendances de la chaîne d’approvisionnement logicielle et des packages de bout en bout pour les CVC connus.

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

Déploiements d’infrastructure en tant que 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 de l’IaC favorise la cohérence du code entre les environnements, élimine le risque d’erreur humaine pendant les déploiements automatisés et fournit la traçabilité et la restauration. Pour les déploiements bleu/vert, l’utilisation de l’IaC avec des déploiements entièrement automatisés est impérative.

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

Remarques relatives à la conception

• Infrastructure reproductible. Déployez des charges de travail stratégiques de manière à générer 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 aux erreurs.

Recommandations de conception

• Appliquez l’IaC, en vous assurant que toutes les ressources Azure sont 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 concerne les 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 conception globale de la fonction et de l’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.

Remarques relatives à la conception

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

  N’oubliez pas la complexité ajoutée lorsque vous utilisez plusieurs technologies. Évaluez un ensemble de fonctionnalités riche par rapport à la fiabilité globale.

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

  Par exemple, supposons que le trafic soit réparti sur deux régions : région 1 et région 2. La région 2 héberge les instance d’outils Azure DevOps. Supposons qu’il y ait une panne dans la région 2 et que le 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 fournir une expérience de basculement optimale. Mais il ne pourra pas le faire en raison de 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 manquer de fonctionnalités pour les tâches de déploiement complexes (déploiement continu). Étant donné l’ensemble complet de fonctionnalités d’Azure DevOps, nous le recommandons 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 assurez-vous de l’alignement avec les exigences de fiabilité des applications plus larges.

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

Stratégie de création de branches

Il existe de nombreuses approches valides pour la création de branches. 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.

Remarques relatives à la conception

• Réduire l’accès. Les développeurs doivent effectuer leur travail dans les branches feature/* et fix/* . 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 création de branches. Par exemple, autorisez uniquement les administrateurs à créer des branches de mise en production ou à appliquer des conventions de nommage pour les branches.

• Processus accéléré pour les situations d’urgence. La stratégie de branchement doit permettre de fusionner les correctifs logiciels dans main dès que possible. De cette façon, les versions ultérieures contiennent le correctif et la récurrence du problème est évitée. Utilisez ce processus uniquement pour les modifications mineures qui répondent à des problèmes urgents et utilisez-le avec retenue.

Recommandations de conception

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

  Important

  Créez une stratégie de branchement qui détaille au minimum le travail et les mises en production desfonctionnalités, 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 modifications de code contributions avant leur acceptation. Les membres de l’équipe doivent également passer en revue les modifications.

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

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

• Utilisez des branches de version/* dédiées créées à partir de la branche main et utilisées pour les déployer dans des environnements de production. Les branches release/* 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 branche de correctif/* pour une fusion ultérieure dans la branche de mise en production et un déploiement en production.

IA pour DevOps

Vous pouvez appliquer des méthodologies AIOps dans les pipelines CI/CD pour compléter les approches de test traditionnelles. Cela permet de détecter les régressions ou dégradations potentielles et d’arrêter les déploiements de manière préventive pour éviter les impacts négatifs potentiels.

Remarques relatives à 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 des tests et des résultats de déploiement aux données opérationnelles sur les composants de test des phases de déploiement composite.

• Scalabilité. Les approches traditionnelles de traitement des données telles que l’extraction, la transformation et la charge (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 ne nécessitent pas d’ETL et de déplacement de données, comme la virtualisation des données, pour permettre l’analyse continue par les modèles AIOps.

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

Recommandations de conception

• Définissez les données de processus DevOps à 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 intermédiaires, de test et de production à des fins d’analyse et de corrélation dans des modèles AIOps.

• Adoptez le workflow MLOps.

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

• Opérationnalisez les modèles en inscrivant et en déployant les modèles les mieux entraînés dans des pipelines de déploiement.

Étape suivante

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

Sécurité