122 lines
5.0 KiB
Markdown
122 lines
5.0 KiB
Markdown
\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 !
|
||
:::::
|
||
|
||
{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 !
|
||
|
||
{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
|