4.2 KiB
\newpage
Intégration continue
Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentrer dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
Créez un dépôt pour youp0m
Reprenez les travaux déjà réalisés : nous allons notamment avoir besoin du
Dockerfile que nous avons réalisé pour ce projet youp0m.
Après avoir créé (ou migré pour les plus malins !) le dépôt
youp0m1 dans gitea, synchronisez les dépôts dans Drone, puis
activez la surveillance de youp0m.
Nous allons devoir rédiger un fichier drone.yml, que l'on placera à la racine
du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
compiler et tester le projet.
::::: {.warning}
Un fichier drone.yml existe déjà à la racine du dépôt. Celui-ci pourra vous
servir d'inspiration, mais il ne fonctionnera pas directement dans votre
installation.
Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
.drone.yml du dépôt. Vous DEVEZ partir d'un fichier vide et suivre la
documentation pour obtenir un .drone.yml fonctionnel.
:::::
Définir les étapes d'intégration
Toutes les informations nécessaires à l'écriture du fichier .drone.yml se
trouvent dans l'excellente documentation du projet :
https://docs.drone.io/pipeline/docker/examples/languages/golang/.
Les étapes sont sensiblement les mêmes que dans le Dockerfile que nous avons
écrit précédemment.
Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
{height=6cm}
::::: {.warning} IMPORTANT : si vous avez l'impression que ça ne marche pas et que vous avez réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné dans la documentation, commencez en partant de l'exemple de la documentation ! Le fichier présent sur le dépôt ne fonctionnera pas dans votre situation ! :::::
Lorsqu'apparaît enfin la ligne git.nemunai.re/youp0m, le projet est compilé !
Inspection qualité
Nous n'avons pas encore de test à proprement parler. Nous allons utiliser Sonarqube pour faire une revue qualité du code !
Tout d'abord, il faut lancer le conteneur Sonarqube :
Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé, nous pourrons accéder à l'interface sur http://localhost:9000.
En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à
notre .drone.yml : http://plugins.drone.io/aosapps/drone-sonar-plugin/.
Après s'être connecté à Sonarqube (admin:admin), nous pouvons aller générer
un token, tel que décrit dans la documentation du plugin
Drone.
Une fois la modification commitée et poussée, Drone enverra le code à Sonarqube qui en fera une analyse minutieuse. Rendez-vous sur http://127.0.0.1:9000/projects pour admirer le résultat.
Publier le binaire correspondant aux tags/jalons
Nous savons maintenant que notre projet compile bien dans un environnement différent de celui du développeur ! Néanmoins, le binaire produit est perdu dès lors que la compilation est terminée, car nous n'en faisons rien.
Ajoutons donc une nouvelle règle à notre .droneci.yml pour placer le binaire
au sein de la liste des fichiers téléchargeables aux côtés des tags.
Vous aurez sans doute besoin de :
- https://docs.drone.io/pipeline/conditions/
- http://plugins.drone.io/drone-plugins/drone-gitea-release/
Attention à ne pas stocker votre clef d'API dans le fichier YAML !
{height=8cm}
::::: {.more} Lorsque l'on est plusieurs à travailler sur le projet ou pour accroître la sécurité, il convient de créer, un compte bot qui sera responsable de la création des releases. Ce sera donc sa clef d'API que l'on indiquera dans l'interface de Drone. :::::