Voici comment aider tous les membres de votre équipe, designers, testeurs ou autres, à démarrer avec GitLab CI.
Chez fleetster, ils ont leur propre instance de GitLab et ils s’appuient beaucoup sur GitLab CI/CD. Leurs designers et leurs responsables qualité l'utilisent (et l'adorent) en raison de ses fonctionnalités avancées.
GitLab CI/CD est un système très puissant d'intégration continue, doté de nombreuses fonctionnalités différentes, de plus en plus avancées à chaque nouvelle version. La documentation technique est très dense, mais il lui manque une introduction générique pour ceux qui veulent l'utiliser dans une installation existante. Un designer ou un testeur n'a pas besoin de savoir comment l'adapter à Kubernetes ni de connaître la différence entre une image ou un service.
Note de traduction : la suite de l’article est écrit par Riccardo Padovani de fleeter et est donc écrit à la première personne.
Il doit savoir ce qu'est un pipeline et comment l'intégrer dans un système existant. Dans cet article, je vais donc évoquer un maximum de fonctionnalités, en soulignant leurs avantages pour les utilisateurs finaux. C’est ce que j’ai fait ces derniers mois auprès de certains membres de notre équipe, qui sont aussi développeurs : tout le monde ne sait pas ce qu'est l'intégration continue ou n'a pas utilisé GitLab CI/CD dans un poste précédent.
Si vous voulez savoir pourquoi l'intégration continue est si importante, je vous suggère de lire cet article, mais je laisse le soin à Christophe ou à GitLab de vous convaincre d'utiliser Gitlab CI/CD.
Introduction
À chaque fois qu'un développeur modifie un code, il enregistre ses modifications dans un commit. Ce commit peut ensuite être envoyé sur GitLab, afin que d'autres développeurs puissent réviser le code.
Si GitLab CI/CD a été configuré, GitLab commencera également à travailler sur ce commit. Ce travail est exécuté par un runner. Un runner est en fait un serveur (cela peut être un grand nombre de choses, y compris votre PC, mais simplifions en disant un serveur) qui exécute les instructions figurant dans le fichier .gitlab-ci.yml, et rapporte le résultat directement à GitLab, qui l'affichera dans son interface graphique.
Une fois que les développeurs ont terminé la mise en œuvre d'une nouvelle fonctionnalité ou une correction de bug (activité qui nécessite généralement plusieurs commits), ils peuvent ouvrir une demande de fusion, afin que les autres membres de l'équipe puissent commenter le code et sa mise en œuvre.
Comme nous le verrons, les designers et les testeurs peuvent également (et devraient vraiment !) participer à ce processus, en donnant leur avis et en suggérant des améliorations, notamment grâce à deux fonctions de GitLab CI : les environnements et les artefacts.
Les pipelines
Chaque commit envoyé sur GitLab génère un pipeline qui lui est rattaché. Si plusieurs commits sont envoyés ensemble, seul le dernier se verra attribuer un pipeline. Un pipeline est un ensemble de tâches réparties en différentes étapes.
Toutes les tâches d'une même étape sont exécutées en parallèle (s'il y a suffisamment de runners) et l'étape suivante ne commence que lorsque toutes les tâches de l'étape précédente sont terminées sans erreurs.
Il suffit que l'une des tâches échoue pour que l'ensemble du pipeline échoue, à une exception près, que nous verrons ci-après : si une tâche est définie comme manuelle, le pipeline n'échouera pas même si cette tâche échoue.
Les étapes sont simplement une division logique entre des ensembles de tâches, sachant qu'il n'est pas logique d'exécuter la tâche suivante si la précédente a échoué. Il peut y avoir par exemple une étape de construction souvent nommée build, pendant laquelle toutes les tâches liées à la création de l'application sont exécutées, puis une étape de déploiement nommée deploy (on utilise plutôt l’anglais pour les noms d’étapes), où l'application en question est déployée. Il n'y a aucun sens à déployer une application dont la construction aurait échoué, n'est-ce pas ?
Les tâches d'une même étape ne doivent pas dépendre les unes des autres, mais peuvent être conditionnées aux résultats des tâches d'une étape précédente.
Voyons comment GitLab affiche les informations sur les étapes et leur statut.
Les tâches
Une tâche est un ensemble d'instructions qu'un runner doit exécuter. Il est possible de voir en temps réel le résultat de la tâche, ce qui permet aux développeurs de comprendre pourquoi une tâche échoue.
Une tâche peut être automatique, c'est-à-dire qu'elle débute automatiquement lorsqu'un commit est envoyé, ou manuelle. Une tâche manuelle doit être déclenchée manuellement par quelqu'un. Cela peut être utile, par exemple, pour automatiser un déploiement, ou le conditionner à une autorisation manuelle. De même, il existe un moyen de limiter le nombre de personnes à pouvoir exécuter une tâche, de sorte que, par exemple, seules des personnes de confiance puissent autoriser le déploiement.
Une tâche peut également créer des artefacts que les utilisateurs pourront télécharger, à l'instar d'une APK que l'on peut télécharger et tester sur son appareil. De cette façon, les designers et les testeurs peuvent télécharger une application et la tester sans avoir à demander de l'aide aux développeurs.
Outre la création d'artefacts, une tâche peut déployer un environnement, généralement accessible via une URL, pour que les utilisateurs y testent le commit.
Le statut d'une tâche est identique à celui des étapes puisque les étapes empruntent leur statut aux tâches.
Les artefacts
Comme nous l'avons dit, une tâche peut créer un artefact que les utilisateurs téléchargeront pour le tester. Cet artefact peut prendre différentes formes, comme une application pour Windows, une image générée par un PC ou une APK pour Android.
Donc si vous êtes designer et que la demande de fusion vous a été assignée : vous devez valider la mise en œuvre du nouveau design !
Mais comment faire ?
Vous devez ouvrir la demande de fusion (MR) et télécharger l'artefact, comme indiqué sur le schéma.
Chaque pipeline rassemble tous les artefacts de toutes les tâches, et chaque tâche peut comporter plusieurs artefacts. Lorsque vous cliquez sur le bouton Télécharger, un menu déroulant apparaît pour vous permettre de sélectionner l'artefact de votre choix. Après la révision, vous pouvez laisser un commentaire dans la MR.
Vous pouvez également toujours télécharger les artefacts des pipelines sans demande de fusion ouverte ;-)
J'insiste sur les demandes de fusion car c'est généralement à ce moment que les testeurs, designers et autres parties prenantes entrent dans le flux de travail.
Mais les demandes de fusion ne sont pas liées aux pipelines : elles s'y intègrent mais n'ont aucun rapport avec eux.
Les environnements
De la même manière, une tâche peut déployer quelque chose sur un serveur externe, pour que vous puissiez y accéder via la demande de fusion elle-même.
Comme vous pouvez le voir, l'environnement possède un nom et un lien. Il suffit de cliquer sur ce lien pour accéder à une version déployée de votre application (bien sûr, si votre équipe l'a configurée correctement).
Vous pouvez également cliquer sur le nom de l'environnement, car GitLab propose d'autres fonctions intéressantes pour les environnements, comme la supervision.
Conclusion
Ceci est une brève introduction à certaines des fonctionnalités de GitLab CI, un outil très puissant qui, utilisé correctement, permet à toute l'équipe de se concentrer sur un seul outil de la planification jusqu’au déploiement. De nombreuses nouvelles fonctionnalités sont introduites chaque mois, alors gardez un œil sur le blog de GitLab ainsi que celui de Lydra qui traduit régulièrement des articles de GitLab
Pour le paramétrer, ou pour accéder à des fonctionnalités plus avancées, veuillez consulter la documentation.
Chez fleetster, nous l'utilisons non seulement pour effectuer les tests, mais aussi pour archiver les versions des logiciels et les déployer automatiquement dans des environnements de test. Nous avons également automatisé d'autres tâches comme la création d'applications et leur publication dans le Play Store…
Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? Rejoignez la Communautés Froggit.
Crédits 
Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction issue du site de GitLab. Image de couverture par Mike Tinnion sur Unsplash À propos de l'auteur invité Riccardo est étudiant à l'université et développeur à temps partiel chez fleetster. En dehors de ces deux activités, il aime contribuer à des projets open source. Cette Introduction à l'intégration continue a été publiée à l'origine sur rpadovani.com.
