Pourquoi mettre en place de l’intégration continue
Aujourd’hui nous allons commencer à aborder un sujet qui m’est cher : l’intégration continue. Pour cela nous allons commencer par comprendre d’où vient ce concept pour ensuite voir ce qu’il apporte à une équipe projet.
De quoi parle t’on ?
Avez-vous déjà entendu parler d’intégration continue ? Mais savez-vous d’où elle vient ? Comment faisions-nous avant ?
Qu’est-ce que l’intégration Continue ?
Pour en comprendre le sens nous allons commencer par nous pencher sur le terme intégration.
Souvenez-vous, vous avez sûrement déjà développé sur un projet sans avoir de serveur de versionning, même que vous utilisiez une clé usb pour passer vos modifications à votre voisin. Il y avait toujours à cet instant, un moment ou vous deviez raccorder la tuyauterie sur ce qu’avait fait votre voisin. Le fameux :
« Ah, je n’avais pas compris que tu allais faire comme ça, du coup attends, je modifie deux trois trucs pour que ça passe »
Rassembler les morceaux de code et les faire fonctionner ensemble : c’est ça finalement l’intégration et c’est le travail de l’intégrateur. Et il faut dire ce qui est, c’est généralement un vrai calvaire, chaque développeur ayant sa manière de travailler, remplir une tache, ou ayant installé telle ou telle librairie sur son poste.
Passons maintenant au second mot : Continue
Le sens de ce mot est plus simple. C’est juste que nous allons faire cette intégration « en continu ».
Nous allons voir les détails dans la partie ci-dessous.
Que faut-il pour la mettre en place ?
Tout ceci ne se met pas en place tout seul, deux éléments sont nécessaires :
- Un dépôt de source (serveur de versionning, repository)
- Une machine où compiler vos projets (Builder)
Vous vous attendiez à plus ? Et bien non, il suffit juste de cela pour commencer. Par contre, comme une compilation sans erreur ne garantit ABSOLUMENT PAS que votre application fonctionne, l’intégration continue se voit souvent adjoindre deux fonctionnalités :
La plus répandue est le lancement des tests unitaires post compilation. Ils sont généralement lancés par le builder sur l’output de votre compilation (dll, projets, …). En ayant ces briques en place, vous pouvez vous vanter d’utiliser un système d’intégration continue.
La seconde est moins répandue : le déploiement continu. Nous y reviendrons plus tard.
Le processus d’intégration continue.
Maintenant que vous avez votre dépôt de source (repository) et votre machine de compilation (builder), voici ce qui va se passer.
Tout développeur travaille sur sa machine. Il peut à tout moment publier ses modifications sur le dépôt de sources (repository) et les rendre ainsi disponible à tous. C’est l’action de commit.
Au lancement de la compilation, la machine va récupérer les sources du dépôt, à savoir l’ensemble des modifications faites par les développeurs. Elle va ensuite les compiler, puis lancer la batterie de tests.
Une fois ces étapes rendues, en cas de succès ou d’erreur, la machine de build va fournir un rapport qui va être mis à disposition de l’équipe de développement.
Et qu’est-ce que ça change ?
Pour le développeur
Le développeur aura un aperçu rapide des erreurs qu’il a causées et, sur la durée, des régressions causées par son développement.
Le fait de lancer les tests unitaires à chaque intégration permet de tester l’application sur le plan technique. Cela laisse aux utilisateurs humains le soin de tester l’application sur la partie fonctionnelle.
Un code compilé régulièrement permet d’identifier rapidement les modifications qui posent problème en cas d’erreur. Vous pourrez donc être soulagés, car vous n’aurez plus, à la fin de la période de développement, une semaine de debug pour que votre application passe en production.
Par contre, il faudra prendre le temps de créer des tests unitaires sur les méthodes développées.
Pour le chef de projet
Le chef de projet dispose d’outils de pilotage. En effet, il peut à tout moment connaître l’état de l’application. Bien entendu cet état dépend du nombre de tests mis en place par les développeurs, de leur qualité et du temps qu’ils ont eu à les coder.
Il y gagne également des indicateurs tels que l’évolution du taux de couverture de test ou de leur pourcentage de succès.
Un autre point important, est la disponibilité à tout moment, d’une version présentable du projet. Car le build n’est pas censé être cassé longtemps étant donné que la priorité est de le réparer. Le chef de projet gagne donc un produit dont il peut voir les fonctionnalités se développer et les tester. Cela peut permettre de les ajuster par exemple.
Pour la production
Vous ne savez jamais ce qui est installé sur les machines des développeurs. Ils ont peut-être tel ou tel SDK qu’ils avaient installé pour un précèdent projet et qui est une dépendance. Avec cet univers d’intégration, vous allez connaître ce qui est nécessaire pour faire tourner votre projet. En effet, si le développeur oublie de vous demander d’installer un SDK sur la machine, la compilation échouera. Vous découvrirez ainsi l’arbre des dépendances avant que votre application ne soit en production et que vous deviez revenir sur une version antérieure mais fonctionnelle.
Pour le client
Le client est celui qui en bénéficie le plus car les régressions deviennent beaucoup plus rares. Il est donc globalement plus heureux.
Avec l’intégration continue, la chose à retenir c’est que pour un peu d’investissement de temps, tout le monde est gagnant, que ce soit vous, dans votre organisation, votre visibilité, ou vos client en terme de satisfaction.
Conclusion
Au final, l’intégration continue est un processus à mettre en place, et ce n’est jamais trivial dans une société. Néanmoins, le bénéfice vaut à mon avis largement l’investissement que l’on y place.
Les prochains articles que je ferai concernant l’intégration continue seront plus techniques et concerneront TFS, le produit Microsoft. Parmi les prochains sujet abordés, nous retrouvons le packaging d’application, avec modifications de settings, qui nous amènerons à développer la notion de déploiement, pour en arriver à son industrialisation au travers du déploiement continu. Nous verrons alors que ce n’est pas si facile à mettre en place.
Pour aller plus loin
Un article pour mettre en place des builds sous TFS est disponible sur ce même blog. Je vous invite à aller le lire : https://blog.soat.fr/2012/08/integration-continue-et-team-foundation-server-22/. Néanmoins, je reviendrai sur la partie concernant l’automatisation des taches dans un prochain article mettant en avant la couche workflow des builds sur TFS.