tuto 2022 5, 6

tutorial/devops/ci-gistre.md

@@ -0,0 +1,121 @@
+\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`](https://git.nemunai.re/nemunaire/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](https://docs.drone.io/pipeline/docker/examples/languages/golang/).
+
+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 !
+:::::
+
+![Drone en action](../devops/drone-run-linky.png){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 !
+
+![Binaire publié automatiquement sur Gitea](../devops/tag-released.png){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