5.0 KiB
\newpage
Intégration continue
::::: {.question}
La mise en place de l'environnement de CI/CD n'est pas le cœur de la version GISTRE du TP (elle l'est pour les SRS). Aussi cette partie est aussi guidée que possible et toutes les commandes vous sont données pour réduire les frictions de mise en œuvre.
Mais comme indiqué dans l'introduction au DevOps, vous serez susceptibles d'arriver dans une entreprise qui pratique correctement le DevOps. Dans cette situation, l'ensemble des développeurs et des administrateurs système (les Ops), doivent faire en sorte que leurs travaux soient intégrés dans les outils d'intégration continue. Les Ops vont évidemment plutôt gérer la mise en place des outils, proprement, c'est ce que demande de faire le TP SRS. Pour vous il s'agit plus de savoir interagir avec, en sachant manipuler la configuration des dépôts.
:::::
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 linky2influx
Après avoir créé (ou migré pour les plus malins !) le dépôt
linky2influx dans Drone,
synchronisez les dépôts, puis activez la surveillance de linky2influx.
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 sur 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.
Les étapes sont sensiblement les mêmes que dans le Dockerfile présent sur le
dépôt.
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.
::::: {.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 ! :::::
{height=7.5cm}
Lorsqu'apparaît enfin la ligne git.nemunai.re/linky2influx, le projet est compilé !
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échargeable 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. :::::
Publier pour plusieurs architectures ?
Le compilateur Go est fourni avec l'ensemble des backends des différentes architectures matérielles qu'il supporte, nous pouvons donc aisément faire de la compilation croisée pour d'autres architectures.
Essayons maintenant de compiler linky2influx pour plusieurs architectures afin de
vérifier que cela fonctionne bien !
Un exemple est donné tout en haut de cette page : https://docs.drone.io/pipeline/environment/syntax/.
En faisant varier $GOARCH en mips, powerpc, ... nous pouvons générer les
binaires correspondant à chaque architecture et système.
Ajoutez à votre fichier .drone.yml les deux architectures pour lesquelles les
Raspberry Pi d'Électropcool sont compatibles. Nommez les fichiers selon
l'architecture que pourrait renvoyer uname -m, cela pourrait nous simplifier la tâche ensuite...
\
Une fois taggé et poussé sur notre dépôt, nous aurons une version exécutable utilisable à la fois sur notre machine de développement, mais aussi sur les Raspberry Pi déjà déployées dans les bâtiments. Nous avons atteint l'un des deux objectifs qui nous était demandé. Tâchons maintenant de trouver un