\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 !) :
```bash 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 . En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à notre `.drone.yml` : . 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 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 : - - 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 : . 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`.