119 lines
4.6 KiB
Markdown
119 lines
4.6 KiB
Markdown
|
\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 !
|
||
|
|
|
||
|
|
{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 !
|
||
|
|
|
||
|
|
{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`.
|