Développement piloté par les tests pour les zones d’atterrissage Azure
Le développement piloté par les tests est un processus DevOps et de développement de logiciels (TDD) qui améliore la qualité des nouvelles fonctionnalités et améliorations apportées aux solutions basées sur du code. Le développement piloté par les tests (TDD) crée des cas de test unitaires 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 d’abord et à la création de cas de test ultérieurement.
La zone d’atterrissage est un environnement permettant d’héberger les charges de travail, qui sont pré-approvisionnées par le biais de code. Les zones d’atterrissage incluent des fonctionnalités de base qui utilisent un ensemble défini de services cloud et de bonnes pratiques. Cet article décrit une approche qui utilise le TDD pour déployer des zones d’atterrissage réussies tout en respectant les exigences de qualité, de sécurité, d’exploitation et de gouvernance.
L’infrastructure cloud est le résultat de l’exécution du code. Un code correctement structuré, testé et vérifié produit une zone d’atterrissage viable. L’infrastructure basée sur le cloud et le code source sous-jacent peuvent utiliser ce processus pour garantir que les zones d’atterrissage répondent aux exigences principales et qu’elles sont de haute qualité.
Cette approche peut être utilisée pour répondre à des demandes de fonctionnalités simples pendant les premières phases de développement. Plus tard dans le cycle de vie de l’adoption du cloud, ce processus peut être utilisé pour répondre aux exigences de sécurité, d’exploitation, de gouvernance ou de conformité. Ce 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 :
Créer un test. Définissez un test pour valider que les critères d’acceptation pour une fonctionnalité ont été satisfaits. Automatisez les tests à mesure que vous développez pour réduire la quantité de tests manuels, en particulier pour les déploiements à l’échelle de l’entreprise.
Tester la zone d’atterrissage. Exécutez le nouveau test et les tests existants. Si la fonctionnalité requise n’est pas incluse dans les offres du fournisseur cloud et n’a pas été fournie par des efforts de développement antérieurs, le test doit échouer. L’exécution de tests existants permet de valider que votre nouvelle fonctionnalité ou votre nouveau test ne réduit pas la fiabilité des fonctionnalités existantes de la zone d’atterrissage.
Développer et refactoriser la zone d’atterrissage. Ajoutez ou modifiez le code source pour satisfaire la fonctionnalité à valeur ajoutée demandée et améliorer la qualité générale de la base de code.
Pour répondre aux critères du TDD, l’équipe de la 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. Lors de la réalisation de nouvelles demandes de fonctionnalités, l’équipe de la 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 fortement recommandée.
Déployer la zone d’atterrissage. Une fois que le code source remplit la demande de fonctionnalité, déployez la zone d’atterrissage modifiée sur le fournisseur de cloud dans un environnement de test contrôlé ou de bac à sable (sandbox).
Tester la zone d’atterrissage. Le nouveau test de la zone d’atterrissage doit confirmer 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 étant satisfaits.
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 à valeur ajoutée et les critères d'acceptation réussissent les tests associés, la zone d’atterrissage est prête à prendre en charge la vague suivante 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 test rouge, en fonction de la définition de Terminé et des critères d’acceptation définis. Pour chaque fonctionnalité ou critère d’acceptation, l’équipe de plateforme cloud exécuterait des tâches de développement jusqu’à ce que le test soit réussi, ou test vert.
L’objectif du TDD est d’apporter une meilleure conception, pas de créer une suite de tests. Les tests sont un artefact précieux pour terminer le processus.
Définition de Terminé
Le succès peut être une mesure subjective qui fournit à l’équipe d’une 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 manquées et des vulnérabilités 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.
La définition de Terminé est un accord simple entre l’équipe de plateforme cloud et les 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, la définition de Terminé et les critères d’acceptation deviennent plus complexes. Dans les processus matures, les fonctionnalités attendues ont chacune leurs propres critères d’acceptation pour plus de clarté. Lorsque les fonctionnalités à valeur ajoutée remplissent chacune les critères d’acceptation, la zone d’atterrissage est suffisamment configurée pour permettre la réussite de la vague ou de la mise en œuvre de l’adoption en cours.
Exemple de définition de Terminé simple
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 initial. Ces charges de travail ne sont pas essentielles 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 chargée de l’adoption du cloud doit respecter les critères suivants :
- Segmentation de réseau à aligner avec la conception de réseau proposée. Cet environnement doit être un réseau de périmètre avec 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 de domaine numérique.
- Schéma d’attribution de noms et de marquage pour une utilisation plus simple.
- Pendant l’adoption, accès temporaire pour l’équipe d’adoption du cloud afin de modifier les configurations des services.
- Avant la version de production, une intégration avec le fournisseur d’identité d’entreprise pour régir l’identité et l’accès en continu pour gestion des opérations. C’est à ce moment que 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 une fonctionnalité, mais un indicateur signalant que d’autres expansions seront requises et doivent être explorées avec les autres équipes le plus tôt possible.
Exemples de définition de Terminé plus complexes
La méthodologie de gouvernance au sein du Cloud Adoption Framework 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.
Déclarations de stratégie initiales. Exemple de définition de Terminé initiale basée sur les stratégies d’entreprise régissant les exigences d’adoption précoces.
Améliorations incrémentielles pour développer la gestion des identités. Exemple de stratégies d’entreprise directrices (« définition de Terminé ») pour répondre aux exigences de développement de la gestion des identités pour une zone d’atterrissage.
Améliorations incrémentielles pour développer les exigences de sécurité. Exemple de stratégies d’entreprise directrices (« définition de Terminé ») pour répondre aux exigences de sécurité alignées sur le plan d’adoption du cloud de référence.
Améliorations incrémentielles pour développer la gestion des opérations. Exemple de stratégies d’entreprise directrices (« définition de Terminé ») pour répondre aux exigences de base de la gestion des opérations.
Améliorations incrémentielles pour développer la gestion des coûts. Exemple de stratégies d’entreprise directrices (« définition de Terminé ») pour répondre aux exigences de la gestion des coûts.
Les exemples précédents sont des exemples de base pour vous aider à développer une définition de Terminé pour vos zones d’atterrissage. Des exemples de stratégies sont disponibles pour chacune des Cinq disciplines de gouvernance cloud.
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 :
Vous pouvez facilement intégrer ces outils et fonctionnalités Azure dans le développement piloté par les tests pour la création de zones d’atterrissage. Les outils servent un objectif spécifique, facilitant le développement, le test et le déploiement de la zone d’atterrissage en conformité avec les cycles TDD.
Azure Resource Manager une plateforme cohérente pour les processus de création 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 ARM (Azure Resource Manager) fournissent le code source primaire pour les environnements déployés dans Azure. Certains outils tiers comme 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 également le mécanisme principal pour tester les critères d’acceptation dans votre définition de Terminé. Azure Policy peut fournir des fonctionnalités automatiques de détection, de protection et de résolution dans les cas où les déploiements s’écartent des stratégies de gouvernance.
Dans un cycle TDD, une définition de stratégie peut être créée pour tester un seul critère d’acceptation. 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. Tous les critères d’acceptation peuvent être ajoutés à une initiative de stratégie affectée à l’abonnement entier. Une fois que la zone d’atterrissage est conforme à la définition de Terminé, Azure Policy peut être utilisé pour appliquer les critères de test afin d’éviter les modifications de code qui provoqueraient l’échec du test dans les versions ultérieures.
Concevez et passez en revue les workflows Azure Policy en tant que code dans le cadre de votre approche de développement piloté par les tests.
Azure Resource Graph permet de créer des tests pilotés par les données basés sur des informations relatives aux ressources déployées dans une zone d’atterrissage. Plus loin dans le plan d’adoption, cet outil peut également définir des tests complexes basés sur les interactions entre les ressources de la charge de travail et l’environnement cloud sous-jacent.
Resource Graph comprend des exemples de requêtes avancés, qui peuvent être utilisés pour comprendre comment les charges de travail sont déployées dans une zone de destination dans le cadre de scénarios de test avancés.
Selon votre approche préférée, vous pouvez également utiliser les outils suivants :
- Déployer des zones d’atterrissage avec Terraform.
- Déployer des zones d’atterrissage avec Bicep.
- Gérer les zones d’atterrissage avec AzOps, un module PowerShell qui envoie (push) des modèles de ressources et des fichiers Bicep à tous les niveaux d’étendue Azure, et qui extrait (pull) et exporte des hiérarchies de ressources Azure.