Wiki Déj : « Gitlab… Tout savoir ou presque »

Nous retrouvons aujourd’hui l’intervention de notre expert externe Stéphane, lors du dernier Wiki Déj, pour nous présenter un outil incontournable : Gitlab.

L’objectif de ce Wiki Dèj est d’introduire l’outil Gitlab à travers un cas d’usage théorique d’évolution du produit. Pour cela, nous aborderons les fonctionnalités de ticket, de Git et de CI. La démonstration finale mettra en application une simple modification du support de présentation.

L’histoire d’un besoin

Pour commencer, nous prenons l’hypothèse suivante qui montre le parcours d’un besoin et les étapes à suivre :

Identifier, détailler, spécifier => gestion de ticket
Développer, configurer => gestion de version
Déployer pour être validé puis utilisé par le client => automatisation

Afin de réaliser ces étapes tout en coordonnant les équipes (concepteurs, développeurs, architectes, opérationnels…), un outillage est nécessaire. C’est là qu’intervient un outil permettant de réaliser à lui tout seul une grande partie de ces fonctions : Gitlab.

Spoiler : nous ne touchons aucune commission de la part de Gitlab 🤪

Gitlab : un véritable couteau suisse

Pour pouvoir mettre en œuvre notre histoire, nous avons besoin d’utiliser :

Un gestionnaire de code sources (git), qui est la base de Gitlab et permet de gérer le versioning ;
Un suivi de ticket (issue) ;
L’automatisation (CI/CD) ;
Une gestion documentaire (Wiki, Web Pages) ;
Un scanner de sécurité, code… ;
Une gestion de projets (voir issue).

Gitlab est un produit, et c’est aussi un projet, c’est-à-dire que les développeurs utilisent eux aussi ce propre outil pour le développer lui-même.

On voit ici que l’on a +46000 tickets, +13000 branches, des tags… Une activité très riche !

Lorsque l’on présente un projet sur Gitlab, il s’agit dans un premier temps d’un répertoire (repository) où l’on vient déposer des informations sous forme de texte, de code source. Dès que l’on veut effectuer une modification, on utilise git puis l’automatisation pour ensuite lancer les actions dédiées.

L’historique de l’outil

2014 Création de l’entreprise (start-up ukrainienne)

2018 Hébergement sur Google

2019 Création de plusieurs filiales à-travers le monde

2021 Entrée en bourse US / Nasdaq

Malgré son entrée en bourse, il existe encore aujourd’hui une édition gratuite open-source et collaborative, ainsi que des éditions payantes.

Si vous voulez participer à l’histoire de Gitlab, vous pouvez donc contribuer par du code, de la documentation ou encore de la relecture !

Et les concurrents ?

Github, le plus connu ;
La suite d’Atlassian (Bitbucket, Jira, Confluence) qui propose plusieurs produits distincts ;
Pour le versioning, SVN, CVS, Mercury…

Amazon (AWS), Google ou encore Microsoft proposent également des produits ayant des fonctionnalités présentes dans Gitlab. On retrouve des outils tels que Jenkins, Circle CI, Tekton.

La gestion de version avec Git

Git est un logiciel de gestion de version décentralisée et reste le cœur de Gitlab.

Il facilite la collaboration d’une équipe, distingue les modifications et permet d’avoir un historique. Il permet aussi les retours arrière et gère les conflits.

Git est outil de gestion de version en usage libre pour rappel, créé en 2005 par Linus Torvalds, auteur du noyau Linux.

La partie horizontale représente les branches, qui se dédoublent ou bien se rassemblent. A travers la gestion définie dans le projet (entre les développeurs, acteurs du projet), on désigne un processus de fonctionnement commun.

Par exemple, quand j’ai besoin de gérer un incident (« hotfix ») en production, je vais créer une nouvelle branche à partir de la branche de référence/principale, corriger, tester, et fusionner ensuite sur cette branche principale. Un « tag » permettra d’identifier la mise à jour dans cette branche. Cette nouvelle version pourra suivre le processus de mise en production.

Si j’ai besoin de créer de nouvelles fonctionnalités, je vais m’appuyer non pas sur la branche principale (« main ») mais sur la branche secondaire (« develop ») ici en violet.

Je fais donc un duplicata de branche « feature », j’effectue mon développement à part puis je le réintègre à « develop » en définissant une « release ». Une fois validée, je la fusionne sur la principale avec un tag/nom de version (V1.0). Je sais toujours qu’elle est ma version de référence à un instant précis.

Tout ce mécanisme permet un seul objectif : fournir une version identifiée dans les mains du client en connaissant tout son historique.

On obtient une visibilité claire et précise de tout ce qui a été fait, ou pas.

On alimente régulièrement la branche principale, qui est le référentiel, et on délivre rapidement chez le client.

Quels sont les bénéfices ?

Git permet :

D’avoir une source unique. Un repository doit regrouper toutes les informations (code source, configurations logicielle et plateforme, scripts, versioning…)
De gérer une branche principale. « main » est la référence sur laquelle vient fusionner les nouvelles fonctionnalités (gestion de flow).
De faire des petites itérations. En validant (commit) chaque petit changement, il est plus facile et plus rapide de le suivre du dev, test jusqu’en production et aussi de connaitre ce qui est mis entre les mains du client. Si un problème intervient, le retour arrière est plus simple et plus rapide.

Issue – Gestion des tickets

Dans Gitlab, la gestion des tickets permet :

D’identifier les évolutions et les bugs ;
De créer une branche (git) et/ou une fusion (merge request) ;
D’utiliser des templates pour un format particulier ;
D’associer des infos complémentaires (étapes, personnes…).

Voici une vue du board des issues réalisées sur le projet Gitlab. On y voit les tickets avec leur titre, les couleurs représentant des informations complémentaires et qui pourront être utilisés sous différentes vues.

Dans cet exemple, la vue est en liste avec différents blocs : backlog, en développement, en review, clos.

Il est possible d’avoir un usage en :

Workflow comme ci-dessus – liste par étapes (ex Kanban) ;
Fonctionnalité – liste par catégorie ;
Assignation – liste par personne ;
Planification – Kanban / échéance (milestone). On peut aussi définir des sprints.

CI/CD – Pipeline

On associe toujours l’automatisation à un pipeline, c’est-à-dire une suite d’actions qui vont être effectuées dans un ordre donné pour arriver à une finalité.

Sur ce schéma, on retrouve à gauche le code source de référence. Le plus souvent, lors de la validation (commit) le pipeline sera déclenché. Par coutume, on découpe la partie intégration (CI) de la partie déploiement (CD).

Dans la partie CI, on va builder le logiciel (ex: compiler le code) puis on réalise des tests unitaires, d’intégration, … ou encore des validations liées à la sécurité. Le but de ces tâches est de vérifier que le code correspond bien à ce qui a été dit, au niveau de la qualité, fonctionnalité, bref on prouve que le boulot a été fait.

À la suite de ces étapes de CI, on peut déployer (CD) le code sur des environnements d’intégration, de préproduction voire de production (cela dépend de la stratégie du projet). On refait des tests complémentaires prenant en compte des environnements au plus proche du contexte du client (plateformes et jeux de données de staging) permettent de s’assurer que le client reçoit bien le bon service. dans le cloud approprié.

Bénéfices

A chaque validation (commit), le pipeline est lancé automatiquement. Tout ce que l’on sait réaliser manuellement va pouvoir être automatisé : actions de versioning, tests, vérifications et scans de sécurité, déploiement… C’est un gain de temps et une rapidité d’exécution.

On peut déployer sur une ou plusieurs plateformes tout en assurant aussi un retour arrière si nécessaire. Tout est regroupé dans le pipeline.

La construction du pipeline est souvent assurée par l’intégrateur DevOps. Mais les différentes étapes du pipeline doivent répondre aux besoins de chacun des acteurs du projet. Ainsi, chacun des membres du projet est acteur, contributeur et responsable de son rôle vis-à-vis du produit final, et donc du client.

A retenir

Gitlab est un outil complet permettant de réaliser l’ensemble de la chaîne à partir d’un besoin énoncé. Que ce soit pour faire évoluer un produit ou développer un projet from scratch, n’hésitez pas à étudier cette solution !

Pour aller plus loin, Stéphane vous propose quelques références supplémentaires :

Nous espérons que cette présentation aura attisé votre curiosité et vous donnons rendez-vous bientôt pour le prochain Wiki Déj !

Blog

> Actualités > Wiki Déj : « Gitlab… Tout savoir ou presque »