Workflow Gitflow - Cloud - 8.0

Guide d'utilisation du Studio Talend

Version
Cloud
8.0
Language
Français
Product
Talend Big Data
Talend Big Data Platform
Talend Cloud
Talend Data Fabric
Talend Data Integration
Talend Data Management Platform
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Real-Time Big Data Platform
Module
Studio Talend
Content
Création et développement
Last publication date
2024-04-16
Le workflow Gitflow définit un modèle de branches strict et conçu autour de la sortie d'un projet. Il fournit un framework robuste permettant de gérer des projets volumineux.

Le workflow Gitflow n'ajoute pas de concept à celui du workflow de branches de fonctionnalités. En revanche, il attribue des rôles spécifiques à différentes branches et définit quand et comment elles doivent interagir.

Le workflow Gitflow utilise un référentiel central comme hub de communication pour toutes les équipes de développement. Comme dans le workflow de branches de fonctionnalités, les développeurs et développeuses travaillent en local et effectuent des Push de leurs branches vers le référentiel central. La seule différence est la structure des branches du projet.

Au lieu d'une branche main unique, ce workflow utilise deux branches pour enregistrer l'historique du projet. La branche main stocke l'historique officiel des versions et la branche develop sert de branche d'intégration pour les fonctionnalités. Tous les commits de la branche main doivent comporter un tag indiquant un numéro de version.

Voici un exemple de scénario dans lequel le workflow Gitflow est utilisé.

Exemple de workflow Gitflow.

Imaginez qu'un développeur nommé Andy doive travailler sur une nouvelle fonctionnalité feature-123 et qu'une développeuse nommée Lucy doive travailler sur une nouvelle fonctionnalité feature-456.

L'administrateur·trice crée une branche develop basée sur main et en effectue un Push vers le référentiel Git distant dans le Studio Talend.

Création d'une branche de développement (develop) basée sur la branche principale (main) et push vers le dépôt Git distant.

Andy crée une branche andy-feature-123 basée sur la branche develop dans le Studio Talend et passe sur cette nouvelle branche.

Création d'une branche basée sur la branche de développement (develop) et passage à cette nouvelle branche.

Comme Andy, Lucy crée une branche lucy-feature-456 basée sur la branche develop dans le Studio Talend et passe sur cette nouvelle branche.

Andy et Lucy travaillent sur leur nouvelle fonctionnalité et créent des Jobs sur leur branche locale de fonctionnalité, puis effectuent un Push de leurs modifications vers le référentiel distant.

Push des modifications vers le dépôt distant.

Pendant qu'Andy continue à travailler sur sa fonctionnalité, Lucy termine la sienne et se prépare à la publier.

Lucy effectue un checkout de la branche develop distante comme branche locale et passe sur cette branche develop.

Check-out de la branche de développement (develop) distante et passage à la branche locale de développement (develop).

Lucy fusionne ensuite ses Jobs de la branche de fonctionnalité lucy-feature-456 dans la branche locale develop à l'aide du menu Pull and Merge Branch.

Fusion de Jobs de la branche de fonctionnalité (feature) dans la branche locale à l'aide de l'outil Git Pull and Merge.

Lucy effectue un Push de ses modifications sur la branche locale develop vers la branche distante develop.

Push des modifications depuis la branche locale vers la branche distante.

L'administrateur·trice crée ensuite une branche release à partir de la branche develop mise à jour et effectue un Push vers le référentiel distant. Lucy termine sa sortie de version.

Elle peut supprimer la branche locale, qui n'est plus utile.

Suppression de la branche locale.

Lorsque la fonctionnalité est prête à être livrée, Lucy effectue un checkout de la branche main comme branche locale, fusionne les modifications de la branche release distante vers la branche main locale à l'aide du menu Pull and Merge Branch, puis effectue un Push de ses modifications vers la branche main distante.

Lucy passe ensuite sur la branche main distante et lui ajoute un tag contenant la version publiée.

La branche release doit être fusionnée dans la branche develop, qui peut contenir de nouvelles mises à jour depuis le début de la sortie de version.

Ajout d'un tag sur la branche.

Après la sortie de la version courante, les développeur·euses peuvent continuer à travailler sur les fonctionnalités de la version suivante, jusqu'au moment où il faudra éventuellement ajuster la version sortie.

Pour ajuster cette version, un·e développeur·euse effectue un checkout de la branche main comme branche de maintenance locale, corrige ce qui doit l'être et effectue un Push de ses modifications vers le référentiel distant. Une branche maintenance distante est créée.

Ce·tte développeur·se effectue un checkout de la branche main distante comme branche locale, effectue une action Pull and Merge Branch depuis la branche maintenance distante et effectue un Push depuis la branche main locale vers la branche main distante. Les ajustements apportés sur la branche maintenance sont à présent fusionnés dans la branche main distante.

Le·a développeur·euse ajoute un tag à la branche main distante, avec le numéro de correctif (hotfix) v1.0.1.

Comme les branches de livraison de version, les branches de maintenance doivent être fusionnées dans la branche develop. Les équipes de développement doivent effectuer cette fusion et supprimer toutes les branches locales qui ne sont plus utiles.