Formation Gitlab

Écrit par Martin

Gitlab est un outil que nous utilisons au quotidien depuis 2014. Vous vous souvenez, à l’époque il ressemblait à ça 😊

Depuis, nous avons parcouru un bout de chemin ensemble, au point de devenir partenaires.

Mais rester au fait d’un outil qui évolue rapidement comme Gitlab nécessite d’y consacrer du temps, des efforts et de la formation des équipes.

Début juillet, entouré d’une partie des équipes Devops, nous avons donc formé un public varié composé de développeurs, chef de projet, designer.

Le cœur du réacteur : l’outillage Devops

Gitlab ne se présente pas comme un outil de suivi de projet ni de ticketing (même s’ils disposent de fonctionnalités pour cela) mais comme un outil DevsecOps.

C’est d’ailleurs ce qui nous a séduit dès le début, cette capacité à outiller notre démarche de qualité logicielle.

Adressant un public hétérogène, il nous fallait un angle d’attaque qui permette à chacun de bien comprendre les bases de l’outil, notre usage, mais également aux plus aguerris d’aller plus loin.

Présentation théorique

Environnement Gitlab et configuration

Dans cette partie prévue pour durer 1h, nous avons présenté notre environnement Gitlab (omnibus, pilotage des mises à jour avec ansible), comment fonctionne la partie CI/CD au sens large, mais également les conventions que nous avons adoptées.

La portée de la configuration de Gitlab est un élément important à prendre en compte et à comprendre lorsqu’on aborde l’outil. Et ce d’autant plus quand on a des droits limités.

Prenons l’exemple de la configuration de variable d’environnement pour un pipeline, vous pouvez avoir de la configuration à ces différents endroits (du plus spécifique au plus général) :

• défini manuellement en lançant un pipeline à la main
• dans la partie settings CI/CD du projet
• dans la partie settings CI/CD du groupe
• dans la partie settings CI/CD de l’instance
• dans la configuration des runners

Sans cette vision, on a tendance à penser que les outils fonctionnent de façon magique.

Gestion des runners

Dès lors qu’on veut jouer des jobs, il nous faut de quoi les exécuter. C’est le travail des runners. Il n’est pas toujours clair au premier abord que les runners disposent de leur cycle de vie autonome et indépendant.

En effet ils peuvent être mis à jour distinctement (même si ce n’est pas conseillé), être déployé en dehors de la solution et dans des configurations variées (machines virtuelles, kubernetes).

Les runners peuvent également tourner sur des architectures différentes (ARM…), par exemple si vous voulez construire un build mobile iOS depuis votre chaîne de CI/CD. Le cas échéant, vos runners pourront être taggés afin que vos jobs utilisent des runners en particulier.

Ce mécanisme peut également être utilisé pour gérer la priorisation de vos projets, notamment lorsqu’un projet a le droit de griller la politesse à tout le monde.

Le mode d’exécution des runners est également un élément de configuration central. Concrètement, il s’agit de définir si le job va s’exécuter directement sur le runner, via un shell, docker ou autre.

Dans notre cas, toutes nos applications sont packagées avec Docker et nous utilisons donc l’executor associé.

Ce mode de fonctionnement facilite également le debug des run en permettant de rentrer dans le contexte d’exécution du job.

Gestion des pipelines

Organisation de notre chaine de CI/CD

La seconde partie détaillait nos ambitions dans la gestion d’une chaine de CI/CD. Nous mettons notamment à disposition des équipes des templates thématiques (app front, java, ruby…) permettant de disposer immédiatement d’une chaîne fonctionnelle en incluant simplement un template.

Notre volonté est d’être le moins spécifique possible par projet tout en offrant des possibilités de configuration.

Le template expose donc un certain nombre de variables d’environnement qui permettront d’avoir une configuration fonctionnelle et couvrant un maximum de cas.

En changeant leurs valeurs, les équipes peuvent faire varier le comportement sur leurs app (préciser des chemins de fichier différents, utiliser des versions d’outils différentes, activer ou désactiver des étapes…).

Dans le cas où ce serait insuffisant, il est toujours possible de définir ou surcharger les étapes dans le .gitlab-ci.yml.

Le cas extrême consiste à tout redéfinir au cas où le template ne serait pas du tout adapté, un cas qu’on cherche au maximum à éviter.

Homogénéiser les pratiques c’est aussi se donner la possibilité d’offrir du support plus efficacement (les équipes sont formées sur les pratiques globales et ne peuvent pas suivre les spécifités de chaque équipe).

Enfin, avec des templates utilisés en central, nous sommes en mesure de relever la barre de la qualité sur l’ensemble des projets en un clin d’œil.

Par exemple, nous pouvons ajouter une étape d’analyse statique de dépendance sur l’ensemble des projets, forcer une montée de version d’un outil dans la chaine etc.

Évidemment cela va dans les deux sens, une régression impacterait l’ensemble des projets. Pour cela les templates suivent des cycles de développement classiques : dans leur branche de feature, appliqué sur un projet depuis une branche spécifique également, puis appliqés à plusieurs projets et enfin mergé et généralisés à l’ensemble.

Déclenchement des pipelines

Quand on pense pipeline, on pense immédiatement à un déclenchement lors d’un push de code mais Gitlab offre d’autres possibilités :

• manuellement (pratique lorsqu’on veut notamment injecter des var d’env particulières)
• scheduled (pour faire tourner des pipelines en mode cronjobs)
• via l’API
• via webhook

Gestion des permissions

S’il n’y avait qu’une seule chose à retenir, c’est que les pipelines s’exécutent avec vos droits utilisateurs.

Combien de fois j’ai eu droit au « Ça marche chez moi ™». Effectivement, c’est le token utilisateur qui sera exécuté, qui vient avec les permissions de l’utilisateur en question.

Ateliers

Après les aspects théoriques, nous avons ensuite enchainé sur 3 ateliers pratiques avec des niveaux graduels permettant :

• d’intégrer un template existant sur un projet
• faire varier le comportement du template
• contribuer directement à un template

La mise en situation a été particulièrement réussie puisque nous avons été confrontés en live au rate limit de docker hub, ce qui nous a obligé à gérer à chaud des palliatifs avec une publication de nos propres images docker pour les services utilisés dans la CI.

Au final, ce fût une formation réussie avec beaucoup d’interactions et de bonne humeur.

Découvrez le témoignage des participants !

Mouloud

La formation CI/CD GitLab a été extrêmement enrichissante. Le caractère pratique de cette formation m’a apporté une compréhension concrète et directe des concepts, me permettant de les appliquer immédiatement à mon projet avec confiance. Avec GitLab CI, j’ai pu automatiser les analyses de code Sonar chaque fois que je travaille sur mon application. Cela m’aide à suivre facilement les problèmes de qualité du code. En centralisant les outils, je gagne du temps dans la configuration et la gestion du processus, ce qui me permet de livrer des fonctionnalités plus fiables et de rester concentré sur le développement.

Maria

Un grand merci aux collègues de l’équipe Infra pour cette journée de formation ! C’était très sympa de découvrir les outils et bonnes pratiques de l’entreprise tout en mettant des visages sur des noms. Un bon rapport théorie/pratique et un super template de CI que l’on peut personnaliser selon les besoins du projet.