Les bonnes pratiques du Gitflow avec Gitlab

Comprendre le Gitflow

Qu’est-ce qu’un Gitflow ?

Git est puissant pour sa gestion des branches. Pour Git, une branche est juste un pointeur vers un commit de référence, représenté par un hash SHA-1.

Mais pas facile de se souvenir d’un hash, et encore moins de le partager à son collègue en lui disant : “tu peux valider la merge request de 34ac2 vers 98ca9 ?”

Très vite on peut se perdre avec les références de commit où l’historique du dépôt peut ressembler à un plat de spaghettis.

Aussi la mise en place d’un gitflow est une étape importante pour le cycle de vie de l’application, car c’est lui qui va poser les étapes liées à la stabilisation de son développement, et à son déploiement en fonction des environnements d’exploitation.

Les différentes branches de gitflow

Généralement, le Gitflow va s’organiser autour de branches dont le nom est explicite, ne change pas au cours du projet, et qui refléte l’avancement d’une fonctionnalité vers la branche la plus stable.

On retrouve souvent les branches “feature”, “develop”, “main”, “release”, qui traduisent le niveau de maturité du code. Une branche est aussi couramment utilisée, la “hotfix”, qui permet de déployer plus rapidement des patchs en cas de besoin urgents.

A noter que sur Gitlab, avec le principe des releases, une archive (artefact) est automatiquement ajoutée aux tags qui permet de déployer une version “nue” de l’application sans l’historique des commits, ce qui est particulièrement adapté à la production (cf tuto de Stéphane Robert). Un tag fait également référence à un commit, ils peuvent donc être considérés comme un branche.

Avec le système de branches décrit ci-dessus, le développement va évoluer en suivant un déroulé de merge requests depuis les branches des features jusqu’à la création d’une release.

Mettre en place git flow dans un projet

Quelques bonnes pratiques

Respecter les environnements

Définir les branches du Gitflow en se basant sur les environnements d’exploitation est une bonne pratique, car on peut ainsi identifier clairement les différentes versions du code et l’environnement sur lequel chaque version pourra être exploitée.

Il est donc nécessaire de respecter l’ordre des étapes du Gitflow afin qu’une branche ne se retrouve pas en retard sur les autres : une nouvelle feature ou une optimisation doit pouvoir être reproductible quelque soit l’environnement.

Passer du gitflow aux pipelines Gitlab

Les plateformes d’hébergement de dépôts Git dans le cloud telles que Github, Gitlab ou Bitbucket permettent d’ajouter des automatismes en lien avec votre gitflow, il est donc nécessaire qu’il soit le plus limpide possible.

Certaines applications nécessitent de générer des assets au moment d’une étape du Gitflow peuvent utiliser ces automatismes : on parle alors de workflow.

Ceux que Bearstech a mis en place dans son Workflow devops s’adaptent à toute forme de Gitflow : chaque merge dans une étape du Gitflow peut alors déclencher des opérations qui garantiront leur bonne reproductibilité sur chaque environnement (telles que les builds d’assets, les tests, ou le déploiement).

Mirroring puis rebase

Quand un projet devient mature pour la production, il peut arriver qu’à ce moment on souhaite passer dans un cadre plus sécurisé / consolidé (comme avoir son propre Gitlab infogéré), et dans ce cas, il peut y avoir une période de transition où les devs continuent à alimenter l’ancien dépôt du projet, tandis que c’est le dépôt “officiel” qui déploie. Dans ce cas, la solution est de mettre en place du mirroring, où le code est synchronisé entre les dépôts, mais attention aux conflits si la synchronisation entre les dépôts est bidirectionnelle.

Une fois que l’équipe de devs est prête à utiliser le dépôt officiel, alors il est nécessaire de définir la branche qui a l’historique le plus proche de branche “main” du dépôt officiel, à partir de laquelle sera construit le gitflow.
Ne pas oublier d’effectuer un rebasage sur la branche main à ce moment là, afin d’aligner l’historique des commits : cela permet d’avoir un historique propre sur la branche principale.

Le gitflow c’est pas automatique

Dans Gitlab, les branches peuvent être protégées, donc il faut bien s’assurer que les développeurs ont les bons droits pour effectuer les push et les merge.

De plus, afin de garder de la lisibilité sur le gitflow, il est utile de faire le ménage dans les branches qui ne sont plus utilisées ou de les supprimer une fois mergées dans une des cibles du gitflow.

Il y a des cas de dépôts qui ne sont pas adaptés au gitflow, notamment pour les mono-repo, ou lorsque les sources de plusieurs applications sont dans un même repo.
Dans ces cas, un gitflow peut être compliqué à gérer, voire contre-productif, car toutes les parties du dépôt doivent évoluer en même temps, et c’est rarement le cas.

De la rigueur, avec ou sans conteneur

Vous l’aurez compris, vous êtes libre de déterminer votre Gitflow selon les étapes de votre projet et de vos environnements d’exploitation.
Cette liberté implique une organisation et une communication rigoureuse de l’équipe, surtout quand les intervenants vont et viennent sur le projet.
Gitlab peut vous apporter une lisibilité et des outils qui renforceront votre méthodologie.
L’expérience que nous avons acquise chez Bearstech dans l’accompagnement de nos clients lors de la maturation de leurs projets (grâce à plusieurs années de travail conjoint), nous a permis de concevoir des services en adéquation avec tous les types de Gitflow qu’ils soient adjoints à des conteneurs ou non.