Intégration continue et Team Foundation Server (1/2)
Comme beaucoup d’entre nous le savent, la ou les phases d’intégration au cours d’un projet sont souvent synonymes de nuits blanches au bureau et de stress. Nous allons donc essayer, au cours de cette série d’articles, de définir ce qu’est l’intégration continue de manière générale et ensuite quels outils existent pour implémenter cette pratique en nous intéressant tout particulièrement à Team Foundation Server.
Dans ce premier article nous allons nous intéresser au concept même de l’intégration continue ainsi qu’aux changements que cela implique pour une équipe de développement et pour un projet.
L’intégration continue en deux mots
Comme le définit Martin Fowler, l’intégration continue vise à faire d’un processus d’intégration un « non-évènement », c’est-à-dire à réduire de façon significative l’importance donnée à ce processus en en faisant quelque chose de courant.
L’idée derrière l’intégration continue est donc de banaliser la phase d’intégration en la décomposant en un processus régulier, souvent quotidien. C’est une pratique facilitée par l’agilité et l’une des bonnes pratiques prônées par l’eXtreme Programming. Cela reste cependant une pratique qui ne nécessite pas un contexte agile pour être appliquée.
L’intégration continue se compose de plusieurs étapes qui correspondent à la définition générale d’un build:
- Récupération du code source
- Vérification et optimisation du code source
- Compilation
- Exécution des tests unitaires
- Préparation au déploiement
- Déploiement
- Exécution des tests fonctionnels
- Génération de la documentation (optionnelle)
Il est important de savoir qu’il existe plusieurs types de build, répertoriés selon leur fréquence, notamment :
|
Build |
Développeur |
Intégration |
Nuit |
| Fréquence | Douzaine par jour | Plusieurs par jour | Un par jour |
| Visibilité | Développeur | Equipe | Equipe |
| Objectif | Savoir si les changements du développeur fonctionnent | S’assurer que les changements fonctionnent | S’assurer que le produit fonctionne |
| Opération | Exécution des tests unitaires affectés | Exécution automatique des tests unitaires | Exécution automatique de tous les tests (unitaires, performance….) |
Afin de pouvoir mettre en place l’intégration continue, un certain nombre de choses sont nécessaires :
- Un serveur d’intégration capable de simuler l’environnement de production
- Une solution logicielle d’intégration
On aura également besoin d’une forte volonté de la part de toute l’équipe de développement y compris le chef de projet qui devra défendre auprès de sa hiérarchie les coûts du serveur d’intégration et du logiciel.
L’équipe de développement aura besoin d’une certaine volonté et d’une certaine discipline afin de prendre les habitudes impliquées par cette pratique qu’est l’intégration continue.
La problématique
L’intégration continue, de par son application, permettra de réduire un certain nombre de conflits dont :
- Conflits de merge lorsque deux développeur modifient le même fichier
- Conflits de compilation lorsqu’une modification a un effet de bord
- Conflits de test lorsqu’une modification dans l’implémentation de la logique métier fait échouer les tests unitaires
De plus, le fait d’avoir un déploiement extérieur à l’environnement de test permettra d’éliminer le syndrome bien connu du « ça marche sur ma machine pourtant ! ».
Le plus gros avantage de l’intégration continue reste tout de même dans la réduction des risques de régression et des coûts de maintenance sur le long terme. En effet le fait d’avoir un grand nombre de build permettra de réduire l’impact qu’aura chaque erreur et ainsi réduira d’autant son coût pour l’entreprise.
On peut donc, grâce à l’intégration continue :
- Détecter rapidement les failles dans le code
- Tester les unités modifiées
- Réduire les problèmes d’intégration
- Avoir une application stable pour faire des tests ou des démos
- Réduire de beaucoup les problèmes d’intégration
- Réduire les coûts de maintenance sur le long terme
Le fait d’avoir une version stable de l’application pour faire des démonstrations augmentera les retours utilisateurs, permettant ainsi de nous assurer que le produit en cours de développement correspond aux besoins actuels des utilisateurs.
Ceci dit, on rappellera que l’intégration continue présente certains inconvénients tels qu’une augmentation du coût de développement, en plus du coût d’installation et de maintenance du serveur d’intégration, ou encore le niveau de discipline demandé aux développeurs qui parfois peut, selon le contexte, être trop grand.
Le développeur qui se trouve dans une équipe pratiquant l’intégration continue devra :
- Commiter fréquemment son code
- N’envoyer que du bon code, c’est-à-dire du code testé
- Donner la priorité aux erreurs empêchant les builds
- Ecrire des tests automatisés
- Vérifier l’état du build avant de récupérer la dernière version du code source
C’est l’ensemble de ces pratiques qui deviendront rapidement des automatismes qui, couplés au serveur d’intégration, permettront de mettre en œuvre l’intégration continue.
Dans l’article suivant “Intégration continue et Team Foundation Server 2/2”, nous feront un rapide survol des solutions logicielles existantes pour implémenter cette pratique et nous nous attarderons sur la solution qu’offre TFS.