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 d’excellence opérationnelle Azure Well-Architected Framework :

OE :06 Créez une chaîne d’approvisionnement de charge de travail qui pilote les modifications proposées via des pipelines prédictibles et automatisés. Les pipelines testent et font la promotion de 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 pour la conception d’une chaîne logistique 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 pour vous assurer que vous disposez d’une méthode prévisible et standardisée de 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 avoir plusieurs pipelines qui suivent les mêmes processus et utilisent 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. Soyez toujours conscient de l’état de votre charge de travail, de sorte que vous ne risquez pas d’avoir un comportement imprévisible. Ce risque s’aggrave si vous devez passer un temps critique à retracer les modifications non comptabilisées lorsque des problèmes surviennent. Pour réduire ces risques, normalisez 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 à les utiliser.

Définition

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 le changement d’infrastructure et d’application entre les environnements.

Stratégies de conception

Notes

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.

Principes principaux

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

Apportez des modifications de charge de travail proposées par le biais de processus et d’outils de la chaîne logistique. Appliquez une stratégie stricte de déploiements automatisés basés sur des modèles. Cette méthode permet de garantir 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 du code, n’effectuez pas de mises à jour à l’aide de processus manuels ou d’une interaction humaine 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 faciliter l’application de cette stratégie, envisagez de limiter l’accès en lecture seule 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 principe est que toutes les modifications sont proposéesjusqu’à ce qu’elles soient déployées en production. Grâce aux tests automatisés, tels que les tests d’intégration et de détection de fumée, vous autorisez votre chaîne logistique à rejeter automatiquement les modifications.

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

Incorporez l’IaC pour vous assurer que votre équipe suit un processus standard et bien établi. Certaines organisations désignent un seul individu ou un 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 de la part 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 comme un groupe logique de composants que vous pouvez regrouper en un seul modèle pour rendre les déploiements faciles et reproductibles. Vous pouvez considérer ces faisceaux comme des empreintes ou desunités d’échelle. Pour plus d’informations, consultez Modèle d’empreintes de déploiement. Lorsque vous devez déployer votre charge de travail pour effectuer un scale-out dans une autre région ou zone de la même région, déployez un tampon à l’aide d’un pipeline. Selon la façon dont vous concevez vos empreintes, 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 empreintes de déploiement se connectent automatiquement aux ressources existantes.

Pour optimiser votre pipeline IaC pour 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 de l’étendue sont remplacés par la configuration mise à jour simultanément et de manière identique à chaque déploiement.

Utilisez un ensemble de ressources de code et d’artefacts dans tous les environnements et pipelines. Un problème 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 puissent 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 d’infrastructure et les ajuster pour répondre aux exigences de chaque environnement.

Pour contrôler les coûts, il existe généralement une variation entre les environnements de production et les environnements hors production. Souvent, vous n’avez 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 d’un environnement à l’autre. Assurez-vous de contrôler et de comprendre la variance à l’aide de paramètres standardisés pour vous aider à maintenir la prévisibilité à mesure que vous apportez des modifications.

Refléter votre structure organisationnelle dans vos conceptions de chaîne d’approvisionnement et de pipeline. Vos organization peuvent être en silo entre les équipes. Chaque équipe peut gérer une partie de la chaîne d’approvisionnement. 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 distinctes des équipes de développement qui gèrent le développement, les tests et les déploiements d’applications. Dans certaines organisations, les équipes de développement et d’infrastructure sont incorporées dans des é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 la collaboration transparente de toutes les équipes. Assurez-vous que toutes les équipes suivent des processus standard et utilisent des outils standard pour rendre la chaîne logistique 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.

Normalisez votre méthode de déploiement. Parlez au propriétaire du produit de la quantité acceptable de temps d’arrêt de production pour votre charge de travail. Selon la quantité, le cas échéant, 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 pendant une fenêtre de maintenance pour réduire la complexité et les risques. 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’introduire des bogues non détectés dans l’ensemble de vos clients. Également appelées déploiements canary, cette méthode se déploie sur des groupes d’utilisateurs contrôlés 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 une certaine quantité de comportements inattendus et fournir des commentaires. Ou il peut s’agir d’un groupe d’utilisateurs internes, 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 qui consiste à déployer uniquement la plus petite modification viable dans chaque déploiement. En fonction de 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, le plus petit changement viable est généralement le déploiement de ressources avec la configuration la plus récente 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 de base doivent rester statiques pendant la majeure partie 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 pipelines différents pour effectuer des modifications au niveau de chaque couche.

Une zone d’atterrissage se trouve à 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 aux équipes d’opérations centrales, ou aux équipes de plateforme, 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 pour modifier un déploiement en fonction de vos besoins de conception. Les principes de conception de la zone d’atterrissage Azure fournissent des pratiques recommandées basées sur la gouvernance basée sur des stratégies et 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.

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, elles 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. L’un des principes fondamentaux de la fiabilité du système est le principe de décalage vers la gauche . Le développement et le déploiement d’une application sont un processus qui se présente sous la forme d’une série d’étapes allant de gauche à droite. Vous ne devez pas limiter les tests à la fin du processus. Dans la mesure du 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. Elles peuvent être coûteuses ou impossibles à corriger ultérieurement 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 version et déployé via les mêmes mécanismes que le code d’application. Vous pouvez tester et valider l’environnement en utilisant les 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 tests suivants dans votre conception de 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 exhaustifs 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 de code individuels fonctionnent comme ils le devraient, par exemple en produisant 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 mise en place dans un environnement de test et fonctionne comme prévu. Les tests de détection de fumée ne vérifient pas l’interopérabilité des composants.

    Les tests de détection de fumée vérifient que la méthodologie de déploiement pour l’infrastructure et 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 de l’application fonctionnent individuellement, puis déterminent si les composants peuvent interagir entre eux comme ils le devraient.

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

    Vous pouvez exécuter des processus de test de longue durée à intervalles réguliers 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 bénéficient d’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é. Les tests d’acceptation déterminent si le système logiciel répond aux spécifications requises.

    L’objectif main de ce test est d’évaluer la conformité du système aux exigences de l’entreprise et de déterminer si le système répond aux critères requis pour la livraison 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 les tests, et vers le haut dans des environnements plus élevés, comme 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 soient apportées à la production. Les exigences de votre entreprise déterminent le focus de vos portes de qualité. Tenez également compte des principes fondamentaux Well-Architected Framework : sécurité, fiabilité et efficacité des performances.

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

Animation 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 workflows qui créent et testent chaque demande de tirage dans votre dépôt, 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. Selon vos besoins et la familiarité de votre équipe avec les outils, vous pouvez utiliser un ou plusieurs de ces outils pour vos déploiements et la gestion des ressources.

Alignement organisationnel

Cloud Adoption Framework fournit des conseils aux équipes centrales pour fournir des zones d’atterrissage de charge de travail. Les zones d’atterrissage de la charge de travail sont l’endroit où la chaîne d’approvisionnement personnalisée de la charge de travail déploie des applications.

Pour plus d’informations, consultez Zones d’atterrissage et principes de conception de zone d’atterrissage Azure.

Exemple

Pour obtenir un exemple montrant comment utiliser Azure Pipelines pour créer un pipeline CI/CD, consultez 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 de l’excellence opérationnelle