search

cplanson / think-tank

4 stars 0 forks source link

Solutions d'intégration continue #3

Closed acadet closed 9 years ago

acadet commented 10 years ago

Bonjour à tous,

Je viens juste de découvrir la solution gratuite Travis CI pour faire de l'intégration continue (uniquement avec GitHub) et qui se révèle très pratique :)

J'aimerais connaître vos expériences avec d'autres solutions !

cplanson commented 9 years ago

Chez Smile on utilise Jenkins pour l'intégration continue. C'est open source (Smile oblige) et ça a l'air puissant et flexible. Après je ne connais pas trop c'est le CP technique qui le configure. Je sais qu'on peut le coupler avec un code sniffer pour alerter à chaque build des erreurs de code et compagnie, avec différents niveaux d'alerte suivant les erreurs détectées, tout cela étant paramétrable bien sûr. Après petite question, de l'intégration continue quand tu ne travaille pas en équipe il y a un intérêt ?

acadet commented 9 years ago

D'accord. J'ai oublié de dire que pour le .NET, on utilisait l'outil TFS de chez Microsoft.

Hé bien je dirai que oui, pour assurer la pérennité de ton code. Par exemple, tu bosses sur une amélio de ton application. Le soir tu sauvegardes sur une branche à part (un shelve), ça te joue tous les tests et tu peux voir si ton application est actuellement fonctionnelle ou non. Egalement, ça te permet d'être sûr que ce qui est sur ta branche master compile et valide tous les tests.

cplanson commented 9 years ago

Ouais je vois, pour gérer plusieurs branches j'imagine que ça peut être utile. Je reste un peu sceptique, je ne pense pas que le travail demandé pour la mise en place d'un outil d'intégration continue en vaille la peine. Enfin je suppose que ça dépend aussi de la complexité de l'outil en question

acadet commented 9 years ago

Bien sûr. Enfin là, pour Travis, c'est assez simple. Voici la configuration que j'ai dû faire : 

language: node_js
node_js:
    - "0.11"
before_install:
    - "npm install -g grunt-cli"
install:
    - "npm install grunt-ts"
script:
    - "grunt ts:build --verbose --force"
    - "grunt ts:testing --verbose --force"

Bien sûr, ici il n'y a aucun tests unitaires lancés, mais uniquement une compilation. Il ne me semble pas que ce soit monstrueux. Après si l'outil de TUs est bien fait, ça devrait se faire également de façon fluide.

acadet commented 9 years ago

Je viens de trouver cet outil également : https://coveralls.io/ Pour le taux de couverture

FoxCie commented 9 years ago

Désolé d'être un peu nul, mais je n'ai aucune idée de ce qu'est "l'intégration continue". Quelqu'un pourrait expliquer ça rapidement (genre éditer le premier post par exemple, comme ça on sait de quoi ça parle en arrivant sur la page même quand on est un petit RSR). Je dis pas ça pour troller, je me dis que ça pourrait être intéressant. Vous allez me dire que je peux chercher sur internet. C'est vrai, mais le principe de ce dépôt c'était à la base de regrouper un peu tout ce qui pourrait nous être utile, donc je pense qu'une description rapide, avec à la rigueur un lien vers un article plus complet serait appropriée.

Sinon, j'ai jamais bien compris le principe de la couverture...

acadet commented 9 years ago

Ok mon poulet, je t'explique :smiley: !

En gros, imagine que tu es le développeur d'une solution logicielle. Normalement, si tu es un développeur, tu utilises un dépôt (sinon t'es une merde).

La première idée clé d'une intégration continue est que tu possèdes une branche (souvent la branche master) sur laquelle il y a une version fonctionnelle de ton application. Tous les tests sont passants, elle n'est en aucun cas buguée. Ainsi, tu peux accéder en un instant à une version stable de ton outil.

Bien, maintenant, tu souhaites améliorer ton application en ajoutant une nouvelle fonctionnalité par exemple. Tu crées donc une nouvelle branche, tu commences ton dev. A la fin de la journée, tu envoies le tout sur le dépôt pour effectuer une sauvegarde. Une nouvelle fois, c'est ici qu'une solution d'intégration continue va intervenir. Elle va ici te permettre de par exemple compiler automatiquement ton projet à chaque commit. Tu peux ainsi savoir si le code de ta branche est viable ou non. Ensuite, tu peux la paramétrer pour jouer automatiquement les tests unitaires que tu as déjà définis. Tu peux alors rapidement observer ceux qui sont non passants.

Ce genre de solutions peut ainsi se révéler utile, que tu travailles seul ou non sur un projet. Tu peux tout de suite observer si ta solution est opérationnelle. En effet, elle peut par l'exemple l'être en local sur ton ordi, mais pas sur un serveur de test (ce qui pose problème évidemment, un manque de configuration ou de dépendances par exemple). Si tu bosses à plusieurs, on peut rapidement diagnostiquer quel est le commit foireux qui a rendu notre application bancale. Si le build (le résultat de ta solution d'intégration continue) est cassé / non passant, c'est que tu dois améliorer ton programme, il n'est pas encore prêt pour une release.

L'intégration continue s'effectue toujours dans une sandbox, à l'image de la solution Vagrant de Clément. On est ainsi sûr d'avoir un environnement propre à chaque fois.

Enfin, le taux de couverture. Il te permet de savoir si des portions de code ne sont pas couvertes par tes tests. Cela peut signifier plusieurs choses :

FoxCie commented 9 years ago

C'est effectivement plutôt intéressant comme concept l'intégration continue, faudra que je me penche dessus un de ces quatre. Ca peut tourner en local ce genre de trucs ? Parfois, je me crée des dépôts Git en local sur mon PC, juste pour versionner un projet perso. C'est pas limité à des plateformes du genre GitHub ?

Pour la couverture, oui je suis d'accord que dans de rares cas ça peut indiquer un oubli d'un truc, mais au final ça ne donne aucune certitude quant à la viabilité du code, alors que c'est parfois utilisé comme ça. Par exemple, certaines entreprises te disent "on a un taux de couverture de notre code à 100%". Ouais, c'est bien, mais ça ne veut pas dire qu'il n'y a pas de bug. Donc OK pour trouver quelques malfaçons dans le code, mais l'intérêt s'arrête là pour moi, et je trouve ça assez limité.

acadet commented 9 years ago

Pour le premier point que j'ai donné (scénarios oubliés), le taux de couverture peut t'aider à identifier des failles. Sinon, oui, je suis en partie d'accord avec toi, ça n'apporte aucune certitude. De plus, un taux de 100% est souvent impossible, notamment si tu as une partie graphique.

Oui bien sûr. A toi de paramétrer ton projet comme tu l'entends. Par exemple, pour du C (dont je te sais grand fan :wink:), tu as gcov et lvcov pour la couverture. Pour le test unitaire je ne sais pas trop. Enfin, tu peux par exemple configurer ton makefile pour lancer tes solutions de tests, de couverture etc. d'une seule ligne de commande !

Après je pense qu'il est possible de lancer automatiquement pour des évènements particuliers, tel le commit sur un dépôt. Il te faudra peut être utiliser des solutions plus puissantes, comme Grunt par exemple.

Ici, je me sers de solutions automatiques car j'ai la flemme de m'embêter à paramétrer les choses.

EDIT : Pour revenir au taux de couverture, il est surtout utile lors de la rédaction des TUs, afin de savoir les portions de code restantes à couvrir. Une fois la release faite, il n'est plus vraiment utile

FoxCie commented 9 years ago

Oui, on peut faire ça à la main en fait. Normalement, dans les dépôts y a des fichiers de {hooks} qui servent à lancer des commandes sur certains évènements (avant un commit, après, etc...), donc suffit de lancer un makefile ou autre qui va compiler et tester ton projet sur un truc clean (sandbox). Mais je pense qu'une solution automatique est plus adéquate, dans le sens où ça t'abstrait des fichiers à modifier, etc... Après, si c'est trop galère à paramétrer, le faire à la main est probablement plus simple.

cplanson commented 9 years ago

Je me permettrai d'ajouter que les possiblités ne s'arrêtent pas à du test. Comme je l'ai dit plus haut, à titre d'exemple sur nos projets à Smile on utilise un code sniffer (phpcs) qui à chaque build va détecter les "erreurs" de code, de l'erreur d'indentation jusqu'à certaines mauvaises pratiques et non respect d'un design pattern (par exemple, pour donner une idée, appeler une méthode de requête en base depuis un contrôleur dans une archi MVC), et parfois même de la redondance de code peut être détectée. Bon, les codes sniffers, c'est encore un sujet à part entière mais il est vrai que couplé à de l'intégration continue là on commence vraiment à toucher à des process qui permettent d'avoir du code propre sur des projets solo comme en équipe.

acadet commented 9 years ago

:+1: Tout à fait, j'avais complètement oublié cet aspect.

On peut effectivement ajouté des linters et des formateurs de code à la solution. Les linters, Clément vient d'en parler. Les formateurs permettront eux d'harmoniser le code, selon des règles prédéfinies, afin d'obtenir un programme codé de façon similaire entre les morceaux de code.

Par exemple, en C#, StyleCops va harmoniser le code :

if(isSuccess) {
    // ... do some stuff
} else {
    // ... do another stuff
}

en 

if (isSuccess) {
    // ... do some stuff
} 
else {
    // ... do another stuff
}
acadet commented 9 years ago

Je ferme le sujet :) Pour toute proposition de solutions, on se retrouve ici