Partager via

Développement piloté par les tests pour les zones d’atterrissage Azure

  • Article

Le développement piloté par les tests (TDD) est un processus de développement logiciel et DevOps qui améliore la qualité des nouvelles fonctionnalités et des améliorations apportées aux solutions basées sur le code. TDD crée des cas de test unitaire avant de développer le code réel et teste le code par rapport aux cas de test. Cette approche s’oppose au développement de code en premier et à la création de cas de test ultérieurement.

Une zone d’atterrissage est un environnement permettant d’héberger des charges de travail préprovisionnée par le biais du code. Les zones d’atterrissage incluent des fonctionnalités fondamentales qui utilisent un ensemble défini de services cloud et de bonnes pratiques. Cet article décrit une approche qui utilise TDD pour déployer des zones d’atterrissage réussies tout en répondant aux exigences de qualité, de sécurité, d’exploitation et de gouvernance.

L’infrastructure cloud est la sortie de l’exécution du code. Le code bien structuré, testé et vérifié produit une zone d’atterrissage viable. L’infrastructure basée sur le cloud et son code source sous-jacent peuvent utiliser cette approche pour garantir que les zones d’atterrissage sont de haute qualité et répondent aux exigences principales.

Utilisez cette approche pour répondre aux demandes de fonctionnalités simples au cours du développement précoce. Plus loin dans le cycle de vie de l’adoption du cloud, vous pouvez utiliser ce processus pour répondre aux exigences de sécurité, d’exploitation, de gouvernance ou de conformité. Le processus est particulièrement utile pour développer et refactoriser les zones d’atterrissage dans un effort de développement parallèle.

Cycle de développement piloté par les tests

Le diagramme suivant montre le cycle de développement piloté par les tests pour les zones d’atterrissage Azure :

Diagramme du processus de développement piloté par les tests pour les zones d’atterrissage Azure.

  1. Créez un test. Définissez un test pour valider que les critères d’acceptation d’une fonctionnalité ont été remplis. Automatisez le test à mesure que vous développez, afin de réduire la quantité d’efforts de test manuels, en particulier pour les déploiements à l’échelle de l’entreprise.

  2. Testez la zone d’atterrissage. Exécutez le nouveau test et tous les tests existants. Si la fonctionnalité requise n’est pas incluse dans les offres du fournisseur de cloud et n’a pas été fournie par les efforts de développement précédents, le test doit échouer. L’exécution de tests existants permet de valider que votre nouvelle fonctionnalité ou test ne réduit pas la fiabilité des fonctionnalités de zone d’atterrissage existantes.

  3. Développez et refactorisez la zone d’atterrissage. Ajoutez ou modifiez du code source pour répondre à la fonctionnalité d’ajout de valeur demandée et améliorer la qualité générale de la base de code.

    Pour répondre aux critères TDD, l’équipe de plateforme cloud ajoute du code uniquement pour répondre à la fonctionnalité demandée. Toutefois, la qualité et la maintenance du code sont des efforts partagés. Au fur et à mesure qu’ils remplissent de nouvelles demandes de fonctionnalités, l’équipe de plateforme cloud doit essayer d’améliorer le code en supprimant la duplication et en clarifiant le code. L’exécution de tests entre la création de code et la refactorisation du code source est vivement recommandée.

  4. Déployez la zone d’atterrissage. Une fois que le code source répond à la demande de fonctionnalité, déployez la zone d’atterrissage modifiée sur le fournisseur de cloud dans un environnement de test ou de bac à sable contrôlé.

  5. Testez la zone d’atterrissage. Testez à nouveau la zone d’atterrissage pour vérifier que le nouveau code répond aux critères d’acceptation de la fonctionnalité demandée. Une fois tous les tests réussis, la fonctionnalité est considérée comme terminée et les critères d’acceptation sont considérés comme remplis.

Le cycle de TDD répète les étapes de base précédentes jusqu’à ce qu’elles répondent à la définition de Terminé complète. Lorsque toutes les fonctionnalités et critères d’acceptation à valeur ajoutée réussissent leurs tests associés, la zone d’atterrissage est prête à prendre en charge la prochaine vague du plan d’adoption du cloud.

Le cycle qui rend le développement piloté par les tests (TDD) efficace est souvent appelé test rouge/vert. Dans cette approche, l’équipe de plateforme cloud commence par un test ayant échoué ou un test rouge, en fonction de la définition de l’opération effectuée et des critères d’acceptation définis. Pour chaque fonctionnalité ou critère d’acceptation, l’équipe de la plateforme cloud effectue les tâches de développement jusqu’à ce que le test réussisse ou qu’elle ait un test vert.

L’objectif de TDD est d’aborder une meilleure conception, et non de créer une suite de tests. Les tests sont un artefact précieux pour terminer le processus.

Définition de Terminé

La réussite peut être une mesure subjective qui fournit une équipe de plateforme cloud peu d’informations exploitables pendant le développement ou la refactorisation de la zone d’atterrissage. Le manque de clarté peut entraîner des attentes et des vulnérabilités manquées dans un environnement cloud. Avant la refactorisation ou le développement d’une zone d’atterrissage, l’équipe de la plateforme cloud doit faire de la clarté sur la définition de Terminé (DoD) pour chaque zone d’atterrissage.

DoD est un accord simple entre l’équipe de plateforme cloud et d’autres équipes affectées qui définit les fonctionnalités ajoutées attendues à inclure dans l’effort de développement de la zone d’atterrissage. La définition de terminé est une liste de vérification, qui s’aligne sur le plan d’adoption du cloud à court terme.

À mesure que les équipes adoptent davantage de charges de travail et de fonctionnalités cloud, le DoD et les critères d’acceptation deviennent plus complexes. Dans les processus matures, les caractéristiques attendues ont chacun leurs propres critères d’acceptation pour fournir plus de clarté. Lorsque les fonctionnalités ajoutées répondent tous aux critères d’acceptation, la zone d’atterrissage est suffisamment configurée pour permettre la réussite de la vague d’adoption ou de la mise en production actuelle.

Exemple simple du Département de la Défense

Pour un effort de migration initial, la définition de Terminé peut être trop simple. L’exemple suivant est une définition de Terminé simple :

La zone d’atterrissage initiale hébergera 10 charges de travail à des fins d’apprentissage initiale. Ces charges de travail ne sont pas critiques pour l’entreprise et n’ont pas accès aux données sensibles. À l’avenir, ces charges de travail seront probablement mises en production, mais la criticité et la sensibilité ne sont pas censées changer.

Pour prendre en charge ces charges de travail, l’équipe d’adoption du cloud doit répondre aux critères suivants :

  • Segmentation du réseau pour s’aligner sur la conception de réseau proposée. Cet environnement doit être un réseau de périmètre disposant d’un accès à l’Internet public.
  • Accès aux ressources de calcul, de stockage et de mise en réseau pour héberger les charges de travail alignées sur la découverte du patrimoine numérique.
  • Schéma de nommage et d’étiquetage pour faciliter l’utilisation.
  • Pendant l’adoption, l’accès temporaire pour l’équipe d’adoption du cloud afin de modifier les configurations de service.
  • Avant la mise en production, l’intégration avec le fournisseur d’identité de l’entreprise est nécessaire pour gérer l’identité et l’accès continus dans le cadre de la gestion des opérations. À ce stade, l’accès de l’équipe d’adoption du cloud doit être révoqué.

Le dernier point n’est pas un critère d’acceptation ou de fonctionnalité, mais un indicateur indiquant qu’un plus grand nombre d’expansions seront nécessaires et qu’ils doivent être explorés avec d’autres équipes dès le début.

Exemples DoD plus complexes

La méthodologie de gouvernance au sein du Framework d’adoption du cloud fournit un parcours narratif à travers la maturité naturelle d’une équipe de gouvernance. Dans ce parcours, vous trouverez plusieurs exemples de « définition de Terminé » et de « critères d’acceptation », sous la forme de déclarations de stratégie.

Les exemples précédents sont des exemples de base pour vous aider à développer un DoD pour vos zones d’atterrissage.

Outils et fonctionnalités Azure pour la prise en charge des cycles TDD de la zone d’atterrissage

Le diagramme suivant montre les outils de développement pilotés par les tests disponibles dans Azure :

Diagramme montrant les outils de développement pilotés par les tests disponibles dans Azure.

Vous pouvez facilement intégrer ces outils et fonctionnalités Azure dans TDD pour la création de zone d’atterrissage. Les outils servent des objectifs spécifiques, ce qui facilite le développement, le test et le déploiement de zones d’atterrissage en alignement avec les cycles TDD.

  • Azure Resource Manager fournit une plateforme cohérente pour les processus de génération et de déploiement. La plateforme Resource Manager peut déployer des zones d’atterrissage basées sur des définitions de code source.

  • Les modèles Azure Resource Manager (ARM) fournissent le code source principal pour les environnements qui sont déployés dans Azure. Certains outils tiers tels que Terraform fournissent leurs propres modèles ARM à soumettre à Azure Resource Manager.

  • Les modèles de démarrage rapide Azure fournissent des modèles de code source pour vous aider à accélérer le déploiement de la zone d’atterrissage et de la charge de travail.

  • azure Policy fournit le mécanisme principal permettant de tester les critères d’acceptation dans votre DoD. Azure Policy peut également fournir une détection, une protection et une résolution automatisées lorsque les déploiements s’écartent des stratégies de gouvernance.

    Dans un cycle TDD, vous pouvez créer une définition de stratégie pour tester un critère d’acceptation unique. Azure Policy comprend des définitions de stratégie intégrées qui peuvent répondre à des critères d’acceptation individuels dans la définition de Terminé. Cette approche fournit un mécanisme pour les tests rouges avant la modification de la zone d’atterrissage.

    Azure Policy comprend également des initiatives de stratégie intégrées que vous pouvez utiliser pour tester et appliquer la définition de Terminé complète pour une zone d’atterrissage. Vous pouvez ajouter tous les critères d’acceptation à une initiative de stratégie affectée à l’ensemble de l’abonnement. Une fois que la zone d’atterrissage répond au DoD, Azure Policy peut appliquer les critères de test pour éviter les modifications de code qui entraîneraient l’échec du test dans les versions ultérieures.

    Concevez et passez en revue Azure Policy en tant que flux de travail de code dans le cadre de votre approche TDD.

  • Azure Resource Graph propose un langage de requête pour créer des tests orientés par les données en fonction des informations sur les ressources déployées dans une zone d'accueil. Plus loin dans le plan d’adoption, cet outil peut également définir des tests complexes en fonction des interactions entre les ressources de charge de travail et l’environnement cloud sous-jacent.

    Resource Graph inclut des exemples de requêtes avancés , que vous pouvez utiliser pour comprendre comment les charges de travail sont déployées dans une zone d’atterrissage pour les scénarios de test avancés.

Selon votre approche préférée, vous pouvez également utiliser les outils suivants :

Étapes suivantes