La création d’environnements en libre-service ne constitue qu’un premier aperçu de vos possibilités avec Lab Management. La véritable valeur de cette technologie apparaît lorsque vous commencez à employer les fonctions d'intégration poussées de ces environnements. L’automatisation de build constitue la première de ces fonctions.
Les équipes
Guide déploiement de builds d’applications
de projet consacrent des ressources significatives au déploiement de chaque build dans de multiples environnements avant le passage de l’application en production.
Des processus ad hoc sont appliqués pour ramener un environnement en arrière jusqu’à un état sans erreurs et pour réessayer le processus à chaque échec d’un déploiement. Par ailleurs, les équipes de test doivent répéter les mêmes tests sur chaque build pour capturer les régressions. Bien que la réexécution des tests de non-régression sur chaque build représente un coût important, l’économie de cette étape ne fera que retarder la détection des problèmes et dégradera la qualité de votre application.
Lab Management exploite la puissance des instantanés (ou snapshot) pour simplifier le déploiement de builds d’application dans un environnement. Un snapshot est un « marqueur » de l’état complet d’un environnement à un instant donné. Un utilisateur peut revenir à ce snapshot à tout moment et relancer l’exécution des machines dans le même état que celui où les instantanés ont été réalisés. Cette approche est pratique pour préserver l’état sans erreurs d’un environnement. Il est possible de revenir à cet état avant de déployer une build ou après l’exécution de tests.
Outre le déploiement de builds sur un snapshot sans erreurs, Lab Management permet également d’exécuter un jeu de tests de non-régression sur celui-ci. Le flux complet build-déploiement-test est disponible comme n’importe quel autre modèle de build dans Visual Studio.
Pour créer un flux build-déploiement-test, procédez comme suit :
- Créez une définition de flux build-déploiement-test : Au moyen de Visual Studio Team Explorer, créez une nouvelle définition de build à partir du modèle par défaut lab. Tout en créant la définition, sélectionnez l’environnement virtuel, le snapshot sans erreurs vers lequel restaurer l’environnement, la définition pour la compilation des sources, les scripts pour le déploiement et la suite de tests.
- Placez en file d’attente la nouvelle définition de build : Vous pouvez définir le flux build-déploiement-test en vue d’un déclenchement manuel ou planifié.
Grâce à cette approche, les équipes de développement n’ont pas à se soucier de la cohérence du processus de déploiement dans différents environnements. Il est inutile de perdre du temps à exécuter des scripts d’annulation ou à effectuer des procédures supplémentaires lorsqu’un déploiement échoue. Il suffit de revenir au snapshot sans erreurs de l’environnement avant de déployer la build suivante. Vous pouvez aussi exécuter des tests de non-régression et d’intégration en plus des tests unitaires, car vous disposez d’un environnement réel sur lequel déployer la build. Les testeurs peuvent ainsi se faire une meilleure idée de la qualité de la build.
Téléchargez cette ressource

État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le Club EBIOS, une communauté dédiée à la gestion des risques autour de la méthode EBIOS
- La difficile mise en conformité avec les réglementations pour les entreprises françaises
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
