Questions diverses sur la mise en oeuvre de l'integration continue

[vdaanen]

bonjour,

comme ecrit dans le titre, j'ai quelques questions sur la mise en oeuvre de l'integration continue.

Dans un premier temps, je vais decrire tel que nous fonctionnons a ce jour: nous travaillons sous Visual C++ (dont sous MS Windows). nous avons configuré le projet qui crée
l'application principale comme dependant des projets de tests de composants unitaires cad que tous les composants unitaires sont compilés et testés (tests unitaires automatisés)
et le binaire de l'application principale est construit si & seulement si tous les tests unitaires passent.

Le probleme de cette approche est que tous les developpeurs doivent reconstruire et tester tous les composants unitaires a chaque nouveau commit.

Dans un sens, c'est de l'integration continue mais on perd tout de meme pas mal de temps car un full build prend une 15aine de minutes
(bien qu'on utilise incredibuild etn qu'on a environ 20 processeurs qui participent a la compilation)

je souhaiterai savoir si on peut faire la meme chose a savoir:
- compiler et executer tous les programmes de tests unitaires et avoir un rapport de tests (integrer un rapport xml créé par boost.test pour 'rendu')
- construire l'appli
- effectuer des tests de l'appli (ca se sera pour plus tard)

J'avoue tout de meme avoir un peu de mal a voir ce que nous apporterait de plus la mise en oeuvre un outil d'integration continue tel que jenkins ou CruiseControl.Net

Est-ce que notre facon de proceder n'est pas correcte (construction de l'appli qui ne peut demarrer que si tous les tests unitaires passent bien que ca me paraisse logique !)

Si ceux qui utilisent des outils d'integration continue veulent bien prendre quelques minutes pour me decrire leur facon de proceder, je leur en serait tres reconnaissant

Merci

Vincent

[romaintaz]

Bonjour,

Je vais donenr mon point de vue là-dessus, bien que mon environnement diffère (je travaille sur des projets Java). Toutefois, ces principes restent valables quelques soient le langage.

Première chose : l'intégration continue se doit d'être séparée des postes des développeurs. C'est d'ailleurs le chemin que vous voulez prendre. L'idée derrière cela est de pouvoir se libérer d'un possible problème de contexte : on peut imaginer que sur un poste de développeur, une librairie X est disponible, mais qu'elle n'a pas été définie correctement dans la configuration globale du projet. Ainsi, le projet compilera sur la machine du développeur, mais pas nécessairement sur celles des autres. Avoir une machine dédiée à l'IC permet d'éviter de tomber dans le syndrome du ça marche sur ma machine !

Autre chose : vous ne faites pas vraiment de l'intégration continue, dans la mesure où rien ne force le développeur a se synchroniser avec le gestionnaire de sources (SCM). Donc peut-être que le développeur va tester le code de l'application qui n'est pas le dernier disponible. L'intégration continue va quant à elle toujours récupérer la dernière version du code sur le SCM, et donc on est sûrs qu'elle va bien intégrer toutes les modifications de l'équipe.

L'autre intérêt de l'IC est justement de décharger le développeur de tout tester avant de commiter. L'idée est que le développeur lance un minimum de tests unitaires lorsqu'il développe. Il pourra lancer ainsi les tests unitaires liés au code qu'il modifie, ou à défaut ceux du module qu'il touche (pour les développeurs Java, je recommande Infinitest, qui se charge de faire ça automatiquement !). L'IC se chargera elle d'intégrer les modifications commitées par le développeur dans l'ensemble de l'application, et en lançant l'intégralité des tests vérifiera que rien n'a été cassé, y compris dans les autres modules (tests de non régression).
Certains serveurs d'IC proposent même la fonctionnalité du commit pré-testé (voir ici pour TeamCity 4+) : le principe est que l'IC fait "barrière" avant le SCM lors d'un commit de code. Lorsqu'un développeur commite des fichiers, l'IC va tester l'application actuelle en intégrant ces commits. Si tout le build passe (compilation + tests), alors le commit est validé. Sinon, il est refusé. Cela permet de toujours disposer d'un état stable de l'application sur le SCM (ça peut éviter le syndrome du je commite à l'arrache mon code et je pars vite en WE de 3 jours, et tant pis pour mes collègue si je viens de casser l'application).

L'IC est aussi là pour notifier lorsqu'un événement particulier arrive. Si un développeur commite du mauvais code, l'IC lui enverra un mail dans le 1/4 heure qui suit. Comme le développeur est encore dans le vif du sujet, il saura rapidement corriger le problème, ce qui n'est pas forcément le cas s'il est averti plusieurs heures après le commit.

Autre intérêt de l'IC : tu peux définir différents types de jobs. De mon côté, j'utilise Jenkins. Pour chaque projet (et chaque branche SVN), je définis 2 types de jobs :

• un "build rapide" dont le but est de vérifier SVN très fréquemment (tous les 1/4 d'heure, mais plus souvent ce serait encore mieux), et de lancer la compilation + les tests unitaires.
• un "nightly build", lancé 1 fois par nuit, qui va lancer la compilation, les tests unitaires, les tests d'intégration (ils sont plus longs à exécuter, donc on évitera de les lancer dans les builds rapides), ainsi que l'analyse de qualité avec Sonar.

Je dispose également d'autres types de jobs : job de release (utilisation du plugin Maven release, je ne connais pas les équivalents pour C++), job de déploiements de l'application sur des serveurs d'application (Tomcat chez nous), jobs "utilitaires", etc. En gros, tout ce qui est automatisé / automatisable, j'essaie de l'intégrer dans mon IC.

Tu te poses également la question de savoir si la façon de procéder est correcte, s'il faut construire l'application que si tous les tests unitaires passent. Pour moi, ça me parait aussi normal. Les tests unitaires sont là pour tester non seulement le bon fonctionnement de l'application, mais aussi de vérifier qu'aucune régression n'est apparue. Du coup, un test qui échoue signifie un problème dans l'application, au même titre qu'une erreur de compilation. Il devient normal alors de stopper la construction de l'application.
Chez nous, comme je viens de le dire, nous utilisons le plugin release de Maven pour faire une release de notre application. Ce plugin se charge de tout : diverses vérifications, compilation, tests, modification des numéros de versions, tag sur SVN, déploiement sur un serveur de stockage des artifacts (repository Maven). Si un test unitaire échoue, alors le processus de release est stoppé, et il faudra le corriger pour mener à bien la release !
Donc oui, ça me parait une bonne chose

Bon, je m'égare un peu, mais il faut dire que le sujet de l'IC est vaste ! J'espère avoir répondu à pas mal de tes interrogations, mais n'hésite pas à continuer le sujet si tu as d'autres questions !

[vdaanen]

Bonjour

merci de ta reponse. J'enrichis la discussion ci dessous par des precisions sur notre pratique et des questions...

Envoyé par romaintaz

Première chose : l'intégration continue se doit d'être séparée des postes des développeurs. C'est d'ailleurs le chemin que vous voulez prendre. L'idée derrière cela est de pouvoir se libérer d'un possible problème de contexte : on peut imaginer que sur un poste de développeur, une librairie X est disponible, mais qu'elle n'a pas été définie correctement dans la configuration globale du projet. Ainsi, le projet compilera sur la machine du développeur, mais pas nécessairement sur celles des autres. Avoir une machine dédiée à l'IC permet d'éviter de tomber dans le syndrome du ça marche sur ma machine !

oui, ce n'est pas encore le cas chez nous mais nous y pensons car nous avons recemment rencontré ce type de problème et du coup nous devons mettre une fonctionnalité en attente ...

Envoyé par romaintaz

Autre chose : vous ne faites pas vraiment de l'intégration continue, dans la mesure où rien ne force le développeur a se synchroniser avec le gestionnaire de sources (SCM). Donc peut-être que le développeur va tester le code de l'application qui n'est pas le dernier disponible. L'intégration continue va quant à elle toujours récupérer la dernière version du code sur le SCM, et donc on est sûrs qu'elle va bien intégrer toutes les modifications de l'équipe.

Effectivement, pour l'instant, on est sur un guide des bonnes pratiques : avant de commiter, je vais un update, je recompile tout et je verifie qu'il n'y a pas de regression.

Envoyé par romaintaz

L'autre intérêt de l'IC est justement de décharger le développeur de tout tester avant de commiter. L'idée est que le développeur lance un minimum de tests unitaires lorsqu'il développe. Il pourra lancer ainsi les tests unitaires liés au code qu'il modifie, ou à défaut ceux du module qu'il touche (pour les développeurs Java, je recommande Infinitest, qui se charge de faire ça automatiquement !). L'IC se chargera elle d'intégrer les modifications commitées par le développeur dans l'ensemble de l'application, et en lançant l'intégralité des tests vérifiera que rien n'a été cassé, y compris dans les autres modules (tests de non régression).
Certains serveurs d'IC proposent même la fonctionnalité du commit pré-testé (voir ici pour TeamCity 4+) : le principe est que l'IC fait "barrière" avant le SCM lors d'un commit de code. Lorsqu'un développeur commite des fichiers, l'IC va tester l'application actuelle en intégrant ces commits. Si tout le build passe (compilation + tests), alors le commit est validé. Sinon, il est refusé. Cela permet de toujours disposer d'un état stable de l'application sur le SCM (ça peut éviter le syndrome du je commite à l'arrache mon code et je pars vite en WE de 3 jours, et tant pis pour mes collègue si je viens de casser l'application).

Oui, ca me parait indispensable. C'est pour pallier a la situation que tu decris que nous avons instauré ce guide des bonnes pratiques. Je ne sais pas si Hudson/Jenkins ou CC permette le test avant commit car je n'aime vraiment pas l'idee de permettre potentiellement commiter une solution 'cassée' de devoir recommiter des fixes..

Envoyé par romaintaz

Autre intérêt de l'IC : tu peux définir différents types de jobs. De mon côté, j'utilise Jenkins. Pour chaque projet (et chaque branche SVN), je définis 2 types de jobs :

• un "build rapide" dont le but est de vérifier SVN très fréquemment (tous les 1/4 d'heure, mais plus souvent ce serait encore mieux), et de lancer la compilation + les tests unitaires.
• un "nightly build", lancé 1 fois par nuit, qui va lancer la compilation, les tests unitaires, les tests d'intégration (ils sont plus longs à exécuter, donc on évitera de les lancer dans les builds rapides), ainsi que l'analyse de qualité avec Sonar.

Je dispose également d'autres types de jobs : job de release (utilisation du plugin Maven release, je ne connais pas les équivalents pour C++), job de déploiements de l'application sur des serveurs d'application (Tomcat chez nous), jobs "utilitaires", etc. En gros, tout ce qui est automatisé / automatisable, j'essaie de l'intégrer dans mon IC.

ca c'est tres interressant car c'est ce que je souhaite mettre en place !

Tu te poses également la question de savoir si la façon de procéder est correcte, s'il faut construire l'application que si tous les tests unitaires passent. Pour moi, ça me parait aussi normal. Les tests unitaires sont là pour tester non seulement le bon fonctionnement de l'application, mais aussi de vérifier qu'aucune régression n'est apparue. Du coup, un test qui échoue signifie un problème dans l'application, au même titre qu'une erreur de compilation. Il devient normal alors de stopper la construction de l'application.
Chez nous, comme je viens de le dire, nous utilisons le plugin release de Maven pour faire une release de notre application. Ce plugin se charge de tout : diverses vérifications, compilation, tests, modification des numéros de versions, tag sur SVN, déploiement sur un serveur de stockage des artifacts (repository Maven). Si un test unitaire échoue, alors le processus de release est stoppé, et il faudra le corriger pour mener à bien la release !
Donc oui, ça me parait une bonne chose

Bon, je m'égare un peu, mais il faut dire que le sujet de l'IC est vaste ! J'espère avoir répondu à pas mal de tes interrogations, mais n'hésite pas à continuer le sujet si tu as d'autres questions !

Bon, il me semble qu'on est sur la bonne voie...

V