[Buildbot] Intégration continue
mardi 24 avril 2018Introduction
Petite présentation de l’outil buildbot écrit en python qui permet d’offrir un framework d’intégration continue.
En d’autre termes, il va permettre d’automatiser un grand nombres d’actions lors de votre développement. Par exemple, on va pouvoir lui demander de faire des tests, releases, builds de votre application quotidiennement et aussi de les distribuer au bon endroits sans devoir se soucier de le faire chaque fois manuellement!
Cet outil propose une architecture de type master/slaves qui permettra donc au serveur maître d’envoyer les requêtes à faire sur chaque machine exclave. Par exemple, pour une application développer sur plusieurs plateformes, on peut lui demander de créer un build sur une machine slave Windows et sur une autre machine salve MacOSX par exemple et au final transmettre les deux builds sur un serveur de fichier.
Notion
Il faut savoir que ce sont les machines slave qui se connectent sur le serveur master pour savoir si il faut exécuter un build ou non.
En réalité, chaque machine slave comporte le lien vers le master avec un mot de passe et un identifiant (slavename) et le serveur master contient la liste des machines slaves (slavename) et mot de passe (pwd) valides à se connecter.
Installation serveur master
Il faut installer buildbot et créé l’utilisateur buildbot et son home doit pointer sur /var/lib/buildbot/
pip install buildbot
Donc une fois buildbot installé sur le serveur (master), la configuration du serveur est définit dans le fichier:
/etc/default/buildmaster
Par défaut la configuration se trouve dans
/var/lib/buildbot
Vous trouverez dans ce dossier le fichier principale de configuration master.cfg et un fichier de log twistd.log.
Ce fichier est subdiviser en plusieurs sections:
- WORKERS: représentent la configuration des machines slave. Elle doit contenir le slavename et pwd définit sur la machine slave dans le fichier buildbot.tac
- CHANGESOURCES: représente la configuration de gerrit ou gestionnaire de source qui permettra de lancer une action si un changement survient dans votre gestionnaire de sources. Vous définirez comment se connecter sur votre gestionnaire de source et aussi placer la clé publique/privé de connection dans le répertoire /var/lib/buildbot/.ssh qui est le home de l’utilisateur buildbot. Et donc une fois ce change source configurer vous pourrez lors de vos builders utiliser des fonctions qui vérifie tout changement de branche ou projet.
- SCHEDULERS: contiendra la liste des schedules qui seront donc déclencher soit par un temps définit ou alors si un changement a été réalisé dans votre gestionnaire de source.
- BUILDERS: représente la liste des actions (build) qui seront exécuter soit manuellement (force build) ou au travers d’un schedule. Chaque builder est équipé d’une buildfactory, qui définit les différentes étapes d’instruction (step) à faire pour un build. Ces étapes représentent toutes les instructions envoyés au buildslave.
- PROJECT IDENTITY: définit les informations du projet représenter sur le site internet.
- REPORTERS: définit un certains nombres de services que vous souhaitez lancer lorsqu’un build est terminé comme par exemple notifier des utilisateurs au succès du build, ou encore répondre à gerrit au code review que le build est réussi (gerritstatuspush).
- DB URL: représente le lien vers la db qui se chargera de centraliser les états de chaque build exécutés.
- USERS PERMISSIONS: représente la configuration des utilisateurs sur le site internet permettant d’adminstrer et voir les builds exécutés / états / etc…
Buildbot fourni un site comme outil de visualisation des builds sur le port 8010
Instructions
Comme cité précédemment c’est un produit écrit en python et dont les modules que vous aurez besoin se trouve dans
/usr/local/lib/python2.7/dist-packages/
Pour vérifier si la configuration est correcte:
buildbot checkconfig
Pour analyser les logs:
tail -f /var/lib/buildbot/twistd.log
Pour que les changements soit pris dans le master.cfg il faut redémarrer le buildserver!
/etc/init.d/buildmaster restart
Slave
Sur chaque machine vous devez avoir python installé correctement et ensuite installer le buildbot worker:
pip install buildbot-worker
Une fois le buildbot-worker installé, vous pourrez créer le fichier de configuration du slave comme suit:
buildbot-worker create-worker /path/worker localhost example-worker pass
La configuration du buildslave se trouvera dans:
buildbot.tac
Notamment la définition du slavename / pwd et le lien vers le serveur master.
Il existe aussi un fichier log twistd.log
Maintenant, il vous reste a créer un fichier script qui lance votre buildslave avec l’instruction suivante:
buildbot-worker start /path/worker