Partager via

Recommandations pour la conception d’une chaîne logistique de développement de charge de travail

  • Article

S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :

OE :06 Créez une chaîne d’approvisionnement de charges de travail qui favorise les modifications proposées via des pipelines prévisibles et automatisés. Les pipelines testent et favorisent ces modifications dans les environnements. Optimisez une chaîne d’approvisionnement pour rendre votre charge de travail fiable, sécurisée, rentable et performante.

Ce guide décrit les recommandations relatives à la conception d’une chaîne d’approvisionnement de développement de charge de travail basée sur des pipelines d’intégration continue et de livraison continue (CI/CD). Développez une chaîne d’approvisionnement afin de vous assurer de disposer d’une méthode prévisible et standardisée pour la maintenance de votre charge de travail. Les pipelines CI/CD sont la manifestation de la chaîne d’approvisionnement, mais vous devez avoir une seule chaîne d’approvisionnement. Et vous pouvez disposer de plusieurs pipelines suivant les mêmes processus et utilisant les mêmes outils.

Incorporez une chaîne d’approvisionnement pour protéger votre charge de travail contre les dommages qui peuvent se produire lorsque vous ne gérez pas correctement les modifications de charge de travail. N’oubliez pas l’état de votre charge de travail. Vous ne risquez donc pas de rencontrer un comportement imprévisible. Ce risque se compose si vous devez passer du temps critique à retracer les modifications lorsque des problèmes surviennent. Pour réduire ces risques, standardisez les processus et les outils qui définissent votre chaîne d’approvisionnement et assurez-vous que votre équipe de charge de travail s’engage entièrement à son utilisation.

Definition

Terme Définition
Chaîne d’approvisionnement Dans les charges de travail cloud, une chaîne d’approvisionnement est une suite standardisée d’outils et de processus que vous utilisez pour affecter l’infrastructure et le changement d’application dans les environnements.

Stratégies de conception

Remarque

Les recommandations de ce guide font référence aux environnements de charge de travail dans une chaîne de promotion de code. Le bac à sable ou d’autres environnements exploratoires et de preuve de concept nécessitent moins de rigueur et de structure.

Ensembles de cœurs

Les recommandations suivantes peuvent vous aider à définir les principes fondamentaux de votre chaîne d’approvisionnement.

Apportez des modifications de charge de travail proposées par le biais de processus et d’outils de chaîne logistique. Appliquez une stratégie stricte des déploiements automatisés basés sur des modèles. Cette méthode permet de s’assurer que la configuration de votre charge de travail dans tous les environnements est standardisée, bien définie et étroitement contrôlée. Pour les environnements d’une chaîne de promotion de code, n’effectuez pas de mises à jour à l’aide de processus manuels ou d’interactions humaines avec le plan de contrôle de la plateforme cloud, par exemple le portail ou une API. Incorporez toutes les modifications apportées à l’environnement via un pipeline en suivant les pratiques de déploiement que vous définissez. Pour vous aider à appliquer cette stratégie, envisagez de limiter l’accès en lecture seule en tant que valeur par défaut et d’utiliser une porte d’autorisation d’accès pour autoriser l’accès en écriture.

Un aspect important de ce tenet est que toutes les modifications sont proposées jusqu’à ce qu’elles soient déployées en production. Grâce à des tests automatisés, tels que les tests d’intégration et de fumée, vous activez votre chaîne d’approvisionnement pour rejeter automatiquement les modifications.

Déployez une infrastructure reproductible et immuable en tant que code (IaC). IaC est la gestion de l’infrastructure dans un modèle descriptif qui utilise un système de contrôle de version qui met en miroir le code source. Quand vous créez une application, le même code source devrait générer le même fichier binaire à chaque compilation. De la même manière, un modèle IaC génère le même environnement chaque fois qu’il est appliqué.

Incorporez IaC pour vous assurer que votre équipe suit un processus standard et bien établi. Certaines organisations désignent un seul ou petit groupe d’individus pour déployer et configurer l’infrastructure. Lorsque vous implémentez un processus entièrement automatisé, les déploiements d’infrastructure nécessitent moins de gestion des individus. La responsabilité est transférée au processus d’automatisation et aux outils. Les membres de l’équipe peuvent lancer des déploiements d’infrastructure pour maintenir la cohérence et la qualité.

Concevez votre charge de travail en tant que groupe logique de composants que vous pouvez regrouper dans un modèle pour faciliter et répéter les déploiements. Vous pouvez considérer ces ensembles comme des tampons ou des unités d’échelle. Pour plus d’informations, consultez le modèle Empreintes de déploiement. Lorsque vous devez déployer votre charge de travail pour effectuer un scale-out dans une autre région ou une zone au sein de la même région, déployez un tampon à l’aide d’un pipeline. Selon la façon dont vous concevez vos tampons, vous pouvez déployer un sous-ensemble de votre charge de travail au lieu de la charge de travail entière. Incluez des composants réseau dans vos pipelines IaC pour vous assurer que vos tampons de déploiement se connectent automatiquement aux ressources existantes.

Pour optimiser votre pipeline IaC pour assurer la cohérence et l’efficacité, concevez une infrastructure immuable plutôt qu’une infrastructure mutable. Implémentez une infrastructure immuable pour vous assurer que tous les systèmes dans l’étendue sont remplacés simultanément par la configuration mise à jour et de manière identique avec chaque déploiement.

Utilisez un ensemble de ressources et d’artefacts de code dans tous les environnements et pipelines. Un point de douleur courant pour les organisations est lorsque les environnements de non-production sont différents des environnements de production. La création manuelle d’environnements de production et de non-production peut entraîner des configurations incompatibles entre les environnements. Cette incompatibilité ralentit les tests et rend plus probable que les modifications risquent de nuire à un système de production. Une approche IaC réduit ces problèmes. Lorsque vous utilisez l’automatisation IaC, vous pouvez utiliser les mêmes fichiers de configuration d’infrastructure pour tous les environnements afin de produire des environnements presque identiques. Vous pouvez ajouter des paramètres aux fichiers de configuration de l’infrastructure et les ajuster pour répondre aux exigences de chaque environnement.

Pour contrôler les coûts, il existe généralement une variance entre les environnements de production et de non-production. Vous n’avez souvent pas besoin du même degré de redondance et de performances dans les environnements hors production que vous le faites en production. Le nombre et la référence SKU de vos ressources peuvent différer entre les environnements. Assurez-vous que vous contrôlez et comprenez la variance à l’aide de paramètres standardisés pour vous aider à maintenir la prévisibilité à mesure que vous apportez des modifications.

Reflètez votre structure organisationnelle dans vos conceptions de chaîne d’approvisionnement et de pipeline. Votre organisation peut être siloée entre les équipes. Chaque équipe peut gérer une partie de la chaîne logistique. Par exemple, de nombreuses organisations ont des équipes qui gèrent des domaines d’infrastructure, tels que la mise en réseau, les données et les ressources de calcul. Ces équipes sont séparées des équipes de développement qui gèrent le développement, le test et les déploiements d’applications. Dans certaines organisations, les équipes de développement et d’infrastructure sont intégrées aux équipes DevOps qui gèrent collectivement tous les déploiements d’infrastructure et d’application. Il existe de nombreuses façons d’organiser les équipes impliquées dans une chaîne d’approvisionnement. Votre chaîne d’approvisionnement s’appuie sur toutes les équipes en toute transparence. Assurez-vous que toutes les équipes suivent les processus standard et utilisent des outils standard pour rendre la chaîne d’approvisionnement aussi efficace que possible.

Votre chaîne d’approvisionnement peut s’appuyer sur des fournisseurs tiers si vous externalisez des parties du cycle de vie de la charge de travail. Ces fournisseurs sont tout aussi essentiels au succès de votre chaîne d’approvisionnement que les ressources internes. Assurez-vous qu’il existe un accord mutuel entre toutes les équipes sur les processus et les outils que vous utilisez.

Normaliser votre méthode de déploiement. Parlez au propriétaire du produit concernant la quantité acceptable de temps d’arrêt de production pour votre charge de travail. Selon la quantité de temps d’arrêt acceptable, vous pouvez choisir la méthode de déploiement adaptée à vos besoins. Dans l’idéal, vous devez effectuer des déploiements lors d’une fenêtre de maintenance pour réduire la complexité et le risque. Si aucun temps d’arrêt n’est acceptable, utilisez une méthode de déploiement bleu-vert.

Utilisez une approche d’exposition progressive pour réduire le risque d’introduction de bogues non détectés à vos clients en grande partie. Également appelées déploiements canary, cette méthode se déploie sur des groupes contrôlés d’utilisateurs dans une séquence progressive. Il intercepte les problèmes avant qu’ils n’affectent davantage d’utilisateurs. Le groupe de déploiement initial peut être une sous-section de vos clients qui connaissent la stratégie de déploiement. Cette sous-section des clients peut tolérer un comportement inattendu et fournir des commentaires. Ou il peut s’agir d’un groupe d’utilisateurs internes, ce qui permet de contenir le rayon d’explosion des bogues pendant le déploiement.

Lorsque vous définissez votre méthode de déploiement, adoptez une stratégie standard de déploiement uniquement pour déployer la plus petite modification viable dans chaque déploiement. Selon les facteurs tels que la criticité de la charge de travail et la complexité des composants, déterminez le plus petit changement viable. Si vous utilisez une infrastructure immuable, la plus petite modification viable est généralement le déploiement de ressources par la dernière configuration pour remplacer les ressources qui exécutent la version précédente. Si vous utilisez une infrastructure mutable, vous pouvez décider que la plus petite modification viable n’est qu’une seule mise à jour sur le groupe de ressources dans l’étendue.

Suivez une approche en couches pour refléter différents cycles de vie. Les couches fondamentales doivent rester statiques tout au long du cycle de vie de la charge de travail, et les couches d’application changent fréquemment. Pour tenir compte de ces différences, vous devez disposer de différents pipelines pour appliquer des modifications à chaque couche.

Une zone d’atterrissage est au niveau de la couche la plus basse. Une zone d’atterrissage est un regroupement logique d’éléments fondamentaux, tels que les abonnements, les groupes d’administration, les groupes de ressources, les fonctions de gouvernance et la topologie de mise en réseau. Une zone d’atterrissage vous permet de déployer et de gérer facilement votre charge de travail, et fournit des équipes d’opérations centrales ou des équipes de plateforme, avec une approche reproductible d’une configuration environnementale. Pour fournir des environnements cohérents, toutes les zones d’atterrissage Azure fournissent un ensemble de zones de conception communes, une architecture de référence, une implémentation de référence et un processus de modification d’un déploiement pour répondre à vos besoins de conception. Les principes de conception des zones d’atterrissage Azure fournissent des pratiques recommandées basées sur la gouvernance basée sur des stratégies, ainsi que la démocratisation des abonnements. Une zone d’atterrissage doit nécessiter des modifications minimales au cours du cycle de vie de votre charge de travail. Pour voir un exemple de zone d’atterrissage, consultez Qu’est-ce qu’une zone d’atterrissage Azure. Cette architecture conceptuelle fournit un ensemble d’opinions recommandées pour Azure.

Votre infrastructure et vos fonctions principales, telles que les contrôleurs réseau d’entrée et de sortie, l’équilibrage de charge, les solutions de routage réseau, la gestion DNS et les serveurs principaux, doivent également nécessiter des modifications majeures peu fréquentes. Toutefois, ils peuvent nécessiter des mises à jour de configuration fréquentes.

Votre application et votre couche de données nécessitent des mises à jour de configuration fréquentes et des modifications fréquentes de l’infrastructure. Ces composants doivent avoir les pipelines les plus dynamiques.

Planifiez une stratégie de test holistique. Le principe principal de fiabilité du système est le principe de décalage vers la gauche . Le développement et le déploiement d’une application est un processus qui est représenté sous la forme d’une série d’étapes allant de gauche à droite. Vous ne devez pas limiter les tests à la fin du processus. Autant que possible, déplacez les tests vers le début ou vers la gauche. Les erreurs sont moins coûteuses à réparer lorsque vous les interceptez tôt. Ils peuvent être coûteux ou impossibles à corriger plus tard dans le cycle de vie de l’application.

Testez tout le code, y compris le code d’application, les modèles d’infrastructure et les scripts de configuration. L’environnement qui exécute des applications doit être contrôlé par la version et déployé via les mêmes mécanismes que le code d’application. Vous pouvez tester et valider l’environnement à l’aide des mêmes paradigmes de test que vos équipes utilisent déjà pour le code d’application.

Si possible, utilisez des tests automatisés pour garantir la cohérence. Incluez les types de test suivants dans votre conception de la chaîne logistique.

  • Tests unitaires : les tests unitaires sont généralement exécutés dans le cadre d’une routine d’intégration continue. Les tests unitaires doivent être complets et rapides. Elles doivent idéalement couvrir 100 % du code et s’exécuter en moins de 30 secondes.

    Implémentez des tests unitaires pour vérifier que la syntaxe et les fonctionnalités des modules individuels du code fonctionnent de la façon dont ils doivent, par exemple produire une sortie définie pour une entrée connue. Vous pouvez également utiliser des tests unitaires pour vérifier que les ressources IaC sont valides.

    Appliquez des tests unitaires à toutes les ressources de code, y compris les modèles et les scripts.

  • Test de fumée : les tests de fumée vérifient qu’une charge de travail peut être debout dans un environnement de test et s’effectue comme prévu. Les tests de fumée ne vérifient pas l’interopérabilité des composants.

    Les tests de fumée vérifient que la méthodologie de déploiement de l’infrastructure et de l’application fonctionne, et que le système répond comme prévu une fois le processus terminé.

  • Tests d’intégration : les tests d’intégration garantissent que les composants d’application fonctionnent individuellement, puis déterminent si les composants peuvent interagir entre eux comme ils le devraient.

    L’exécution d’une grande suite de tests d’intégration peut prendre beaucoup de temps. C’est pourquoi il est préférable d’incorporer le principe de décalage gauche et d’effectuer des tests au début du cycle de vie du développement logiciel. Réservez des tests d’intégration pour les scénarios que vous ne pouvez pas tester avec un test de fumée ou un test unitaire.

    Vous pouvez exécuter des processus de test de longue durée à intervalle régulier si nécessaire. Un intervalle régulier offre une bonne compromission et détecte les problèmes d’interopérabilité entre les composants d’application au plus tard un jour après leur introduction.

    Certains scénarios de test tirent parti des exécutions manuelles. Utilisez des tests manuels lorsque vous devez introduire des éléments d’interactivité humaine dans des tests.

  • Test d’acceptation : selon le contexte, vous pouvez effectuer manuellement des tests d’acceptation. Il peut être partiellement ou entièrement automatisé. Le test d’acceptation détermine si le système logiciel répond aux spécifications requises.

    L’objectif principal de ce test est d’évaluer la conformité du système aux exigences métier et de déterminer si le système répond aux critères requis pour la remise aux utilisateurs finaux.

Implémentez des portes de qualité tout au long de votre processus de promotion du code via des tests. Déployez votre code dans des environnements inférieurs, tels que le développement et le test, et vers le haut via des environnements plus élevés, tels que la préproduction et la production. À mesure que votre déploiement passe par des portes de qualité, assurez-vous qu’il répond à vos objectifs de qualité avant que les modifications ne passent en production. Vos besoins métier déterminent le focus de vos portes de qualité. Considérez également les principes fondamentaux du framework bien conçu : sécurité, fiabilité et efficacité des performances.

Intégrez également des flux de travail d’approbation dans vos portes de qualité. Définissez et automatisez clairement les flux de travail d’approbation le cas échéant. Définissez les critères d’acceptation de la qualité dans votre automatisation, afin de pouvoir parcourir vos portes efficacement et en toute sécurité.

Facilitation Azure

Azure DevOps est une collection de services qui vous aident à créer une pratique de développement collaborative, efficace et cohérente.

Azure Pipelines fournit des services de génération et de mise en production pour prendre en charge CI/CD dans vos applications.

GitHub Actions pour Azure s’intègre à Azure pour simplifier les déploiements. Utilisez GitHub Actions pour automatiser les processus CI/CD. Vous pouvez créer des flux de travail qui créent et testent chaque demande de tirage sur votre référentiel, ou déployer des demandes de tirage fusionnées en production.

Vous pouvez utiliser Terraform, Bicep et Azure Resource Manager pour les déploiements IaC. En fonction de vos besoins et de la connaissance des outils de votre équipe, vous pouvez utiliser un ou plusieurs de ces outils pour vos déploiements et la gestion des ressources.

Exemple

Pour obtenir un exemple montrant comment utiliser Azure Pipelines pour créer un pipeline CI/CD, consultez l’architecture de base d’Azure Pipelines.

Liste de contrôle De l’excellence de l’opération

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle d’excellence opérationnelle