New tuto 3 done

tutorial/devops/ci.md

@@ -0,0 +1,118 @@
+\newpage
+
+Intégration continue
+====================
+
+Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentré
+dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
+
+## `youp0m`
+
+### Créez un dépôt pour `youp0m`
+
+Reprenez les travaux réalisés au TP précédent. Nous allons notamment avoir
+besoin du `Dockerfile` dans la section suivante.
+
+Après avoir créé (ou migré pour les plus malins !) le dépôt
+[`youp0m`](https://gitea.nemunai.re/nemunaire/youp0m), dans Drone,
+synchronisez les dépôts, puis activez la surveillance de `youp0m`.
+
+Vous allez devoir rédiger un fichier `.drone.yml`, que l'on placera à la
+racine du dépôt (celui qui existe déjà dans le dépôt pourra servir
+d'inspiration, mais il ne fonctionnera pas directement sur votre
+installation). C'est ce fichier qui sera traité par DroneCI pour savoir comment
+compiler et tester le projet.
+
+
+### Définir les étapes d'intégration
+
+Toutes les informations nécessaire à 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 vous avez
+écrit lors du TP précédent.
+
+Comittez puis pousser votre travail, dès qu'il sera reçu par Gitea, vous
+devriez voir l'interface de Drone lancer les étapes décrites dans le fichier.
+
+**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.png){height=8cm}
+
+Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
+
+
+### Inspection qualité
+
+Nous n'avons pas encore de test à proprement parlé. Nous allons utiliser
+[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
+
+Tout d'abord, il faut lancer le conteneur Sonarqube (pensez à l'ajouter à votre
+playbook !) :
+
+<div lang="en-US">
+```bash
+docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube
+```
+</div>
+
+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](http://plugins.drone.io/aosapps/drone-sonar-plugin/).
+
+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é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}
+
+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 `youp0m` pour plusieurs architecture 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 `arm`, `arm64`, `mips`, ... nous pouvons générer
+les binaires correspondant à chaque architecture et système.
+
+Ajoutez au moins 2 autres architectures à votre fichier `.drone.yml`.