Comment bien cadrer son projet avec gitlab flow ?

0
160
bien cadrer avec gitlab flow

Nous continuons notre série de cadrage de nos projets git, pour plus de cohésion technique (et humaine par la même occasion), avec le gitlab flow.
Evolution du github flow, il propose de répondre à plusieurs questions laissées sans vrai cadrage officiel. Gitlab flow va y répondre, tout en gardant la simplicité du github flow.

Prendre le github flow …

Avec le gitlab flow, nous reprenons les principes du github flow, à savoir :

  • Se baser sur la branche master/main pour créer les fonctionnalités
  • Utiliser les Pull/Merge request pour préparer, vérifier, valider, contrôler le code qui va être envoyé sur la master

.. Tout en l’améliorant

La branche master / main devient le staging

Ici, la master n’est plus la branche de production.
Il s’agit de la branche de staging, de recette, de tests (techniques fonctionnels).

Et ça change tout !

On va pouvoir y mettre en place un déploiement automatique de notre projet, depuis la branche main, vers un serveur de staging.
Les testeurs et testeuses, le client, la cliente, vont pouvoir tester l’ensemble, sans avoir la pression de la production.

Passer de la branche main/master à la pre-prod, puis vers la prod

Imaginons que la version actuelle, présente sur la main/master est pertinente, et est validée pour passer vers la production.
Il suffit ici de créer une Pull/Merge Request vers la branche de pré-prod.

Et on va pouvoir appliquer le même principe pour la mise en production.

Multiple branches with the code cascading from one to another

Avoir des branches par version

Gitlab flow nous propose également d’avoir, depuis la branche main/master (ou bien depuis les branches de prod), des branches de version (v1.2, v2.3, ..).

Et dès qu’une fonctionnalité, une correction de bug est délivrée sur la branche main/master, on va pour la récupérer grâce à un cherry-pick.
Très pratique, et ça permet d’avoir un système évolutif, gérant plusieurs versions de la même application (ou de la même librairie, du même framework).

Utilisation des issues du gitlab flow

Pour bien suivre les avancées du projet, gitlab propose de suivre le process suivant :

  • On crée une issue dans gitlab
  • Et après on effectue les changements via le code
  • Puis, en committant, on fait référence au ticket (issue), que l’on a traité.

Des commits par issue par amènent déjà des commits plus unitaires, et ça c’est déjà un grand pas dans l’apprentissage des bons commits, pour la documentation technique de votre projet !

Des Merge Request en mode brouillon (draft)

Lorsqu’on ne souhaite obligatoirement avoir de personnes qui relisent notre code, que l’on souhaite informer qu’on a avancé sur du code, et qu’on va se préparer à proposer une vraie Merge Request, on peut créer une Merge Request en mode brouillon (draft) (anciennement appelée Work In Progress Merge Request, nom que je préférais pour le sens apporté).

Un cadre plus complet

Ici, avec Gitlab flow, nous voyons que le Github Flow a bien évolué, et est plus « project ready », à savoir qu’on a une vraie gestion de bout en bout (e2e) du processus de livraison.
Il prend en compte également les multiples versions, et favorise la stratégie de rebase, un vrai plus !

Les merge request sont utilisées dans leur totalité, et la notion de Draft (WiP) merge request amènent vraiment un plus dans le processus, dans le cadre git.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici