Générer et déployer en continu

Lorsque de nombreux développeurs collaborent sur des projets logiciels complexes, le processus d'intégration des différentes parties de code peut s'avérer long et incertain. Vous avez cependant la possibilité de rendre ce processus plus efficace et plus fiable si vous générez et déployez votre projet de façon continue.

L'intégration continue (CI) consiste à intégrer aussi fréquemment que possible votre code dans un référentiel partagé. Pendant l'intégration du code, un arrêt de build ou un échec de test peut vous indiquer, en temps opportun, une erreur dans votre code.

Martin Fowler propose la stratégie de pratiques suivante pour permettre une intégration continue :

• Maintenir un référentiel source unique.

• Automatiser la build.

• Rendre votre build autonome.

• Archiver au moins une fois par jour.

• Effectuer chaque archivage sur le serveur CI.

• Garder la build rapide.

• Tester dans un clone de l'environnement de production.

• Simplifier l'accès de toute l'équipe au fichier exécutable le plus récent.

• Rester toujours informé de ce qui se passe.

• Automatiser le déploiement.

Pour plus d'informations, consultez la page suivante sur le site Web de Martin Fowler : Continuous Integration.

Visual Studio Application Lifecycle Management (ALM) vous aide à gérer le processus de développement logiciel de bout en bout et prend en charge la pratique d'intégration continue. Grâce aux fonctionnalités de Visual Studio ALM, vous pouvez éviter les retards inattendus, les dépassements de coûts et les risques d'exécution dans le cadre de vos projets.

Dans cette rubrique

• Gestion des dépendances

• Intégration continue dans Visual Studio 2010

• Préparation et mise en route

• Contrôle de version

• Build

• Test et déploiement

• Intégration de projet et communication

Gestion des dépendances

L'intégration du code est un processus complexe en raison des dépendances au sein du code. Par exemple, une bibliothèque qui dessine un cercle sur un écran dépend de la méthode Sqrt() des bibliothèques de calcul du système. Si la méthode Sqrt() change, vous devez mettre à jour la bibliothèque en conséquence. Le matériel et les systèmes d'exploitation changent beaucoup moins souvent que votre projet d'équipe. Toutefois, le fait d'ignorer les changements quelles que soient les circonstances peut entraîner des résultats désastreux. Vous pouvez intégrer votre code dès que possible de façon à vérifier qu'il repose sur des hypothèses valides et qu'il fonctionne comme prévu.

Les changements de code peuvent affecter les dépendances de différentes façons. L'illustration suivante présente deux situations. L'exemple de gauche montre un changement relativement isolé. Cependant, l'exemple de droite illustre un changement ayant un impact potentiel supérieur car présentant de nombreuses dépendances.

L'illustration suivante montre comment les changements constants peuvent avoir des effets combinés si vous n'intégrez pas votre code et que vous ne le mettez pas à niveau de façon continue.

Dans l'étape 1, vous changez le bloc de code h, ce qui affecte potentiellement tous les blocs de code dépendants a, b, d, e et f. Dans l'étape 2, vous changez les blocs de code a et b. Si l'équipe n'effectue pas d'intégration entre les étapes 1 et 2, les blocs a et b peuvent ne plus être valides. Dans l'étape 3, vous changez le bloc de code f. Si l'équipe n'effectue pas d'intégration entre les étapes 2 et 3, le bloc de code b, à ce stade précis, a été affecté, changé, puis à nouveau affecté. Par conséquent, le bloc de code b peut devenir difficile à résoudre.

Intégration continue dans Visual Studio 2010

Visual Studio ALM fournit des ensembles d'outils intégrés pour la prise en charge de l'intégration continue. Comme le montre l'illustration suivante, ces outils incluent des fonctionnalités de contrôle de version, de build, de test, de déploiement dans un environnement lab, de suivi des éléments de travail et d'entreposage des données.

Tout d'abord, vous pouvez utiliser contrôle de version Team Foundation pour gérer des branches, des ensembles de modifications, ainsi que l'intégration entre ces éléments. Chaque membre de l'équipe peut utiliser des espaces de travail pour travailler de façon indépendante. Pour plus d'informations, consultez Création de branches et fusion et Créer un espace de travail pour utiliser le projet de votre équipe.

Ensuite, vous pouvez utiliser Team Foundation Build pour compiler, tester et déployer votre logiciel dans un système distribué et automatisé. Comme le montre l'illustration précédente, Team Foundation Build possède deux genres de builds. Le premier utilise un type de build en continu pour générer la branche de développement. Le deuxième utilise un type de build d'archivage contrôlé pour générer la branche principale (Main). Visual Studio Team Foundation Server prend en charge cinq types de builds : en manuel, en continu (déclenché par chaque archivage), enchaîné (cumul des archivages jusqu'au terme des builds précédentes), l'archivage contrôlé, et planifié. Pour plus d'informations, consultez Créer une définition de build de base, Fonctionnement d'un système Team Foundation Build et Archiver des modifications en attente contrôlées par une build d'archivage contrôlé.

Troisième point, les fonctions Lab Management de Visual Studio ALM permettent de définir et de déployer des builds vers des environnements lab à la fois virtuels et physiques. Pour intercepter les erreurs d'intégration au moment de l'exécution dans un environnement spécifique, vous pouvez déployer une build dans un environnement lab, puis exécuter des suites de tests sur cette build. Pour plus d'informations, consultez Utilisation d'un lab virtuel pour le cycle de vie de votre application.

De plus, les fonctionnalités de test de Visual Studio ALM sont disponibles sur l'ordinateur des membres de l'équipe, sur l'ordinateur de build et au sein de l'environnement lab. En premier lieu, l'exécution de suites de tests sur l'ordinateur du développeur intercepte les problèmes liés au code qui a été récemment changé ou créé. Ensuite, l'exécution de tests sur l'ordinateur de build intercepte les problèmes liés à l'intégration avec le reste du code. Troisièmement, l'exécution de tests dans le laboratoire intercepte les problèmes relatifs à un environnement spécifique que votre équipe configure. Pour plus d'informations, consultez Comment : configurer et exécuter des tests planifiés après la génération de votre application.

Quatrièmement, Visual Studio Team Foundation Server est le référentiel qui stocke les éléments de travail. Vous pouvez créer, gérer et effectuer le suivi des éléments de travail, tels que les bogues ou les tâches, qui sont assignés aux membres de votre équipe. Si une build s'arrête pendant l'intégration de code, votre équipe doit résoudre le problème le plus rapidement possible. Vous pouvez configurer Team Foundation Server afin de créer des éléments de travail pour les arrêts de build. Pour plus d'informations, consultez Suivi de bogues, de tâches et d'autres éléments de travail.

Pour finir, les bases de données de l'entrepôt de Team Foundation Server et SQL Server Analysis Services regroupent et mettent en relation toutes les données fournies par les sous-systèmes dans Team Foundation Server. Ces sous-systèmes incluent le contrôle de version, la build, le test, le déploiement et le suivi des éléments de travail. Par conséquent, votre équipe peut visualiser le processus d'intégration continue de bout en bout. Pour plus d'informations, consultez Génération de rapports à l'aide de la base de données relationnelle de l'entrepôt pour Visual Studio ALM.

Préparation et mise en route

Votre équipe peut suivre la progression suivante pour commencer à utiliser l'intégration continue et Team Foundation Server :

1. Utiliser contrôle de version Team Foundation pour intégrer le code dans une base de code unique.

2. Créer un type de build manuel dans Team Foundation Build.

3. Exécuter des cas de test automatisé pour vérifier la qualité de la build. Si vous ne disposez pas d'une suite de tests appropriée, créez une suite de tests d'espace réservé et importez des cas de test automatisé. Cette suite servira d'espace réservé pour les futurs tests.

4. Veiller à fournir les binaires résultants d'une build dans un emplacement partagé. Cette stratégie vous aide à diagnostiquer les problèmes qui apparaissent au cours du test.

5. Utiliser Gestionnaire de tests Microsoft pour intercepter les erreurs d'intégration au moment de l'exécution dans un environnement spécifique.

Contrôle de version

Un système de contrôle de version fournit un référentiel partagé à votre code. Une petite équipe peut travailler avec une branche unique. Toutefois, l'utilisation de deux branches ou plus est plus pratique car vous développez généralement plusieurs versions de code et diffusez votre projet dans le cadre de différents jalons. Pour plus d'informations sur la création et la fusion de branches de code, consultez la page suivante du site Web CodePlex : Team Foundation Server Branching Guide 2.0.

Build

Dans l'intégration continue, un système de génération génère les composants exécutables qui peuvent être testés et déployés. Le système de génération fournit également des commentaires sous la forme d'erreurs et d'avertissements de compilation. Ces erreurs découlent des modifications introduites dans votre source de projet.

Team Foundation Build fournit les types de builds suivants :

• Manuel – Les builds sont mises en file d'attente par les membres de l'équipe.

• Continu – Les builds sont mises en file d'attente par un archivage vers une branche de contrôle de version.

• Enchaîné – Les builds s'accumulent jusqu'à l'achèvement de la build précédente.

• Archivage contrôlé – Les archivages sont acceptés uniquement si les modifications soumises peuvent être fusionnées et générées correctement.

• Planifié – Les builds se produisent dans le cadre d'une planification définie.

Pour plus d'informations, consultez Créer une définition de build de base.

Que faut-il attendre des membres de l'équipe pour implémenter correctement l'intégration continue ?

Les membres de votre équipe doivent organiser leurs sources de façon à ce que leur génération ne dure pas plus de 10 minutes. Pour les projets plus importants, cela peut ne pas être possible. Grâce à Team Foundation Server, votre équipe peut configurer diverses définitions de build qui génèrent différents sous-ensembles de la base de code. Si les builds prennent beaucoup de temps, vous pouvez utiliser un type de build enchaînée pour générer continuellement des binaires pour le code non modifié.

Si et lorsqu'une build s'arrête, votre équipe doit la réparer immédiatement. En supposant que la branche principale n'est pas affectée par une mauvaise intégration inverse, la plupart des arrêts de build proviennent soit d'un mauvais archivage dans une branche de travail, soit d'une intégration en aval depuis la branche principale. Il est conseillé d'assigner la tâche de résolution des arrêts de build à un membre de l'équipe pendant une période donnée, puis de faire tourner cette assignation aux différents membres de votre équipe.

Combien de builds faut-il exécuter par jour ?

Lorsque vous intégrez votre code de façon continue, vous pouvez exécuter une build en continu pour chaque archivage qui se produit dans chaque branche. Vous pouvez également exécuter une build enchaînée qui est indépendante du nouveau code archivé. Pour plus d'informations, consultez Créer une définition de build de base et Surveiller la progression d'une exécution de build.

Comment Team Foundation Server peut-il permettre l'accélération de la génération de code ?

La configuration de la définition de la build afin d'exécuter des builds incrémentielles permet d'augmenter la vitesse de la build. Vous pouvez utiliser des journaux de génération pour identifier les parties lentes de la build où des améliorations sont possibles. Pour plus d'informations, consultez Configurer Team Foundation Build pour une génération incrémentielle.

Comment Team Foundation Build peut-il permettre la mise à l'échelle de l'intégration continue ?

Les contrôleurs de build et les agents de build permettent de mettre à l'échelle le cycle d'intégration continue.

Pour plus d'informations, consultez Fonctionnement d'un système Team Foundation Build.

Test et déploiement

Comment le test et le déploiement s'intègrent-ils au sein de l'intégration continue ?

L'illustration suivante montre comment les fonctionnalités de test et de déploiement de Visual Studio ALM s'adaptent à l'intégration continue.

En premier lieu, lorsque vous intégrez votre code de façon continue, vous pouvez rechercher les problèmes de code dans la build même. La compilation de la build réussit ou échoue, en fonction du compilateur utilisé. Vous pouvez générer un rapport de build qui contient à la fois des messages d'erreur et d'avertissement du compilateur. Dans Visual Studio ALM, le rapport de build fournit également des informations relatives aux bogues résolus dans cette build, quels ensembles de modifications ont été inclus dans cette build, et si l'analyse du code a été exécutée pendant la build. Grâce à Visual Studio ALM, vous pouvez vérifier si la conception de votre code suit les règles définies par votre équipe. Pour plus d'informations, consultez Comment : valider du code .NET par rapport à des diagrammes de couche.

Ensuite, vous pouvez rechercher les problèmes de code en exécutant des tests unitaires. Ces tests diagnostiquent les problèmes différemment des compilateurs. Les règles du compilateur vérifient les problèmes de syntaxe du code et de constructions de langage. Par opposition, les tests unitaires (qui peuvent s'exécuter sur une build après sa génération) peuvent vérifier les aspects fonctionnels du code. Ces tests unitaires peuvent également fournir des métriques telles que la couverture du code sur une build, en fonction d'un jeu de tests unitaires. Pour plus d'informations, consultez Comment : configurer la couverture du code à l'aide de paramètres de test pour les tests automatisés.

Grâce à Gestionnaire de tests Microsoft, vous pouvez configurer un environnement spécifique dans lesquels vous pouvez exécuter des tests. Les tests unitaires isolés peuvent fournir un niveau de vérification fonctionnelle. Toutefois, les environnements présentent les aspects importants suivants :

• La diversité des environnements peut affecter le fonctionnement du code. Par exemple, les paramètres réseau et la topologie peuvent être difficiles à tester sans un environnement de Lab Management.

• L'automatisation du déploiement de code dans un environnement spécifique aide votre équipe à réduire le temps de déploiement et à augmenter le nombre d'itérations de déploiement.

Pour plus d'informations, consultez How to: Create an Environment from Virtual Machine Templates et Configuration d'ordinateurs de test pour exécuter des tests ou collecter des données.

Comment puis-je organiser mes suites de tests pour permettre l'intégration continue ?

Vous pouvez exécuter les suites de tests qui sont les plus importantes pour vos builds en continu car un nombre trop élevé de tests peut retarder l'achèvement de la build. Assurez-vous de bien exécuter ces tests pour l'itération actuelle.

Au cours d'un cycle de build planifié ou nocturne, vous pouvez également exécuter des tests issus de builds précédentes et effectuer des passes de test qui vérifient les fonctionnalités des sprints précédents.

Comment l'intégration continue affecte-t-elle l'équipe de test ?

L'intégration continue permet d'identifier les builds qui contiennent des erreurs et d'éviter à l'équipe de test de perdre du temps à utiliser et installer de mauvaises builds.

Intégration de projet et communication

En fonction de la taille de votre projet, l'effort d'implémentation de l'intégration continue peut être significatif. Votre équipe doit définir et planifier le travail pour l'intégration continue au cours du premier sprint du projet.

Si vous souhaitez adopter l'intégration continue par phases, vous pouvez commencer par implémenter la build automatisée. Vous pouvez ensuite la modifier afin d'inclure l'exécution de tests unitaires. Enfin, vous pouvez ajouter les fonctionnalités de déploiement de la build testée dans un environnement lab, puis exécuter des tests au sein de l'environnement pour vérifier si un environnement différent affecte le code.