tuto5-srs: Done

tutorial/devops/ci.md

@@ -1,14 +1,17 @@
-\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 !
 
+L'idée est qu'à chaque nouveau *commit* envoyé sur le dépôt, Drone fasse une
+série de tests, le compile et publie les produits de compilation.
+
 ### 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`.
+::::: {.exercice}
+
+Reprenons les travaux déjà réalisés : nous allons notamment avoir besoin du
+`Dockerfile` que nous avons réalisé pour le projet `youp0m`.
 
 Après avoir créé (ou migré pour les plus malins !) le dépôt
 `youp0m`[^urlyoup0m] dans gitea, synchronisez les dépôts dans Drone, puis
@@ -16,6 +19,33 @@ activez la surveillance de `youp0m`.
 
 [^urlyoup0m]: <https://git.nemunai.re/nemunaire/youp0m>
 
+:::::
+
+::::: {.question}
+
+#### Que fait Drone pour « surveiller » un dépôt ? {-}
+\
+
+Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
+Gitea, il peut non seulement lire et récupérer le code des différents dépôts
+auxquels vous avez accès, mais il peut aussi changer certains paramètres.
+
+L'activation d'un dépôt dans Drone se traduit par la configuration d'un
+*webhook* sur le dépôt en question. On peut le voir dans les paramètres du
+dépôt, sous l'onglet *Déclencheurs Web*.
+
+:::::
+
+![L'onglet des *webhooks* dans Gitea](gitea-webhooks.png){height=6cm}
+
+À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
+Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
+ou non, selon les instructions qu'on lui a donné dans la configuration du
+dépôt.
+
+
+### Définir les étapes d'intégration
+
 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.
@@ -30,9 +60,6 @@ installation.
 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/>.
@@ -40,9 +67,18 @@ trouvent dans l'excellente documentation du projet :\
 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
+::::: {.exercice}
+
+Commencez à partir de l'exemple donné dans la documentation de Drone. Par
+rapport au `Dockerfile`, n'ajoutez pas `tags dev`, cela permettra d'embarquer
+tout le contenu statique (pages HTML, feuilles de style CSS, Javascript, ...)
+directement dans le binaire, ce qui simplifiera la distribution.
+
+*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.
 
+:::::
+
 ![Drone en action](drone-run.png){height=6cm}
 
 ::::: {.warning}
@@ -58,7 +94,7 @@ 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
+`youp0m` n'a pas de suite de tests fonctionnels, mais nous allons utiliser
 [Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
 
 Tout d'abord, il faut lancer le conteneur Sonarqube :
@@ -72,14 +108,18 @@ docker run --rm -d --name sonarqube --network drone -p 9000:9000 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>.
 
+::::: {.exercice}
+
 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](http://plugins.drone.io/aosapps/drone-sonar-plugin/).
 
-Une fois la modification commitée et poussée, Drone enverra le code à Sonarqube
+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.
 
@@ -90,6 +130,8 @@ 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.
 
+::::: {.exercice}
+
 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.
 
@@ -98,13 +140,22 @@ 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 !
+::::: {.warning}
 
-![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm}
+#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
+\
 
-::::: {.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.
+
+Pour notre exercice, nous n'avons pas besoin de créer un utilisateur dédié,
+mais il est impératif d'utiliser les *secrets* de Drone pour ne pas que la clef
+d'API apparaisse dans l'historique du dépôt.
+
 :::::
+
+:::::
+
+![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm}