Comment développer avec les Issues Gitlab comme un pro ?

Utilisez la puissance de GitLab pour standardiser vos tickets, structurer vos tâches et booster votre efficacité.

Vous avez déjà eu du mal à suivre qui fait quoi dans un projet ? Des tâches oubliées ? Des branches perdues ?

GitLab propose bien plus qu’un simple dépôt Git.

Dans cet article, je vous montre comment exploiter les issues et les merge requests pour organiser vos développements, suivre vos tâches, et créer un historique projet aussi clair que vos commits.

Le tout sans complexité, mais avec une logique simple, reproductible, et orientée DevOps.

🏆 Développer efficacement avec les issues GitLab en 3 étapes

Quand on parle de GitLab, on pense souvent au code, aux branches, aux pipelines. Mais pour tirer le meilleur de la plateforme, il faut aller plus loin.

Le combo gagnant ? Issues + Merge Requests. C’est le duo qui vous permet de coder proprement, collaborer efficacement, et documenter automatiquement l’historique du projet. Voici comment vous lancer, pas à pas.

1. Créer une issue claire et actionnable

Tout commence par un besoin. Une fonctionnalité à ajouter, un bug à corriger, une tâche à planifier ? Créez une issue.

Rendez-vous dans l’onglet Plan > Issues, puis cliquez sur New issue.

🧠 Important : soignez le titre

Le titre d’une issue est sa carte d’identité. Il doit être :

• ✍️ Clair (évitez les termes flous comme “amélioration truc”)

• 📏 Concise (les premiers mots sont visibles partout)

• 👥 Compréhensible par n’importe quel membre de l’équipe

👉 Pour notre exemple, on peut écrire comme titre : Mettre à jour la version de Spark en 4.0.0

Ensuite, gardez le type Issue, puis dans le champ description, détaillez ce qu’il faut faire.

Bonne nouvelle : le Markdown est pris en charge ! Vous pouvez structurer votre texte, ajouter du code, des liens, des listes, voire des captures d’écran.

👉 Pour l’exemple, on peut écrire : Issue de démonstration utilisée pour la merge request.

Enfin, assignez l’issue (assignee) à vous-même ou à un membre de l’équipe. Vous pouvez aussi renseigner une date d’échéance, un jalon ou des labels, mais nous y reviendrons plus tard.

Vous pouvez ensuite définir un Milestone (Jalon), mais nous le verrons dans une section ultérieure. De même pour les Labels qui sont très intéressants et seront développés plus tard.

➡️ Cliquez sur Create issue… et voilà, votre première pierre est posée.

2. Créer une Merge Request (MR) liée

Depuis l’issue, cliquez sur Create merge request. GitLab va automatiquement :

• créer une branche dédiée

• nommer la MR à partir du titre de l’issue (préfixée par Draft:)

• relier l’issue à la MR avec un Closes #id dans la description

Laissez les valeurs par défaut, puis cliquez sur Create merge request.

➡️ Vous avez maintenant un espace de travail pour développer, versionner, et discuter des changements.

3. Développer, committer, pousser… et merger

Côté local, récupérez la branche (git checkout) et développez normalement. Une fois vos modifications prêtes :

• 🧪 git commit (avec un message clair !) 🔗 Relire mon article sur le sujet

• 📤 git push

Sur GitLab, vos commits apparaissent dans la MR, accompagnés des diffs visuels. Vous pouvez :

• suivre vos changements

• demander des relectures

• valider votre code après vérifications (tests, CI/CD, etc.)

Quand tout est bon :

• cliquez sur Mark as Ready, puis Merge

• GitLab fusionne votre branche vers main, ferme l’issue, et supprime la branche de travail

➡️ Vous avez réalisé un développement propre et efficace !

📝 “Draft” vs “Ready” : deux états pour une Merge Request

Par défaut, une Merge Request (MR) créée depuis une issue est marquée comme Draft:. Cela signifie simplement que la MR est encore en cours de développement. Elle n’est pas prête à être relue ou fusionnée. C’est un excellent moyen d’indiquer à vos collègues : “je suis dessus, mais ne me relisez pas tout de suite”.

Tant que le préfixe Draft: est présent dans le titre, GitLab empêchera même la fusion (merge) de la MR. Une sécurité utile pour éviter les erreurs de précipitation.

✅ Passer une MR en “Ready” : le feu vert pour la revue

Une fois vos modifications terminées, vos tests passés, et votre code relu personnellement, il est temps de passer la MR en Ready.

Il suffit pour cela de cliquer sur “Mark as ready” dans l’interface GitLab. Le préfixe Draft: est alors retiré automatiquement du titre.

Ce changement indique clairement aux autres que la MR est prête pour une revue, des commentaires, et potentiellement pour être mergée. Cela aide toute l’équipe à mieux prioriser les revues de code

🔁 Et si je me suis trompé ?

Pas de panique.

Même si l’issue a été fermée et la branche supprimée, vous pouvez rouvrir l’issue, créer une nouvelle MR, et GitLab recréera automatiquement une branche de travail.

Mieux encore : dans l’issue, GitLab affichera un historique de toutes les MRs liées, ce qui vous permet de suivre les évolutions, erreurs, et corrections.

C’est l’un des points forts de GitLab : tout est lié, documenté, et historisé.

🚀 En résumé

Avec cette approche :

• ✅ Vous travaillez de façon plus structurée

• 🧠 Vous documentez chaque évolution

• 🤝 Vous facilitez la collaboration

Et ce n’est que le début. GitLab regorge de super-pouvoirs pour les développeurs organisés… et on va les explorer ensemble dans le prochain chapitre.

🚀 Booster vos issues GitLab

GitLab ne se limite pas à créer des tickets avec un titre et une description. Il offre de nombreuses fonctionnalités qui permettent d’aller bien plus loin : assignation, priorisation, hiérarchisation, suivi du temps, jalons…

Ces options permettent d’améliorer la lisibilité, la collaboration et la planification de vos projets data.

🔧 Paramètres avancés à connaître

Voici les principaux paramètres qui permettent de transformer une simple issue en véritable outil de pilotage :

• 👤 Assignees : affectez un ou plusieurs membres de l’équipe responsables de cette tâche.

• 🧱 Epic (option payante) : reliez l’issue à une épopée, afin de regrouper plusieurs issues autour d’un objectif ou d’un thème commun. Parfait pour structurer un projet complexe.

• 🏷️ Labels : ajoutez des mots-clés pour faciliter le filtrage et la recherche. Exemple : data, backend, urgent, tech debt, etc.

• 📆 Milestone (jalon) : positionnez l’issue dans une version ou une période de développement (par sprint, release, etc.).

• ⚖️ Weight (option payante) : attribuez un poids à chaque issue. Il peut représenter la complexité technique, l’effort estimé ou encore l’impact business. Le plus important : définir une convention claire pour que le poids ait le même sens pour toute l’équipe.

• 🕓 Due date : fixez une date limite individuelle pour l’issue. Cela peut être utile en complément d’un jalon, pour signaler une échéance particulière à respecter. À utiliser avec parcimonie pour éviter les effets de stress inutile.

• ⏱️ Time tracking : estimez la durée de travail prévue, puis enregistrez le temps passé. Pratique pour les suivis projet et le pilotage de charge, mais chronophage.

🆘 Deux types d’issues : issue ou incident

Les issues sont idéales pour suivre les évolutions, tâches techniques ou nouvelles fonctionnalités.

Mais en cas de problème en production, comment faire la différence ? Faut-il un outil externe pour gérer les incidents ?
Pas nécessairement. GitLab intègre nativement un type d’issue spécial : les Incidents.

Lorsque vous créez une issue, vous pouvez choisir un type dans le champ dédié :

• Par défaut : Issue

• Alternativement : Incident

À première vue, rien ne change dans l’interface. Le formulaire reste identique.

Mais une fois l’incident créé, de nouveaux champs spécifiques apparaissent dans la colonne de droite :

• 🚨 Severity : définissez la sévérité de l’incident (critique, haute, moyenne, basse, inconnue).

• 📶 Status : suivez l’état de l’incident (déclenché, acquitté, résolu).

Ce mécanisme permet de suivre vos incidents en interne, de manière centralisée, tout en gardant l’historique et les échanges liés.

🎯 Conseil : pour un usage externe (notamment B2C ou support client), un outil complémentaire peut être plus adapté. Dans ce cas, l’incident peut être créé dans GitLab uniquement pour l’équipe projet.

📋 Standardiser la description avec les templates d’issues

Un bon ticket commence toujours par une bonne description.

Mais lorsqu’elle est improvisée, incomplète ou désorganisée, cela peut vite devenir un frein : perte de temps, incompréhension, oublis…

La solution ? Les templates d’issues GitLab !

🛠️ Comment créer un template d’issue

1. Créez un dossier .gitlab à la racine de votre dépôt.

2. À l’intérieur, ajoutez un dossier issue_templates.

3. Créez un fichier Markdown (.md) avec le nom du template. Exemple :

   • default.md : utilisé par défaut par GitLab avec ce nom.

   • bug_report.md, feature_request.md, etc. : pour des usages spécifiques.

4. Rédigez le contenu en Markdown. Exemple de template que j'utilise :

## 🎯 Contexte
Décrire la raison d'être de ce ticket

## 🔗 Ressources
- Lister les références utiles pour traiter ce ticket

## 🚦 Definition Of Ready (DoR)
- [ ] Prérequis n°1
- [ ] Prérequis n°2

## ✅ Definition Of Done (DoD)
- [ ] Action n°1
- [ ] Action n°2

💡 Astuce : commencez simplement, avec un template pour les issues et un autre pour les incidents. Évitez d’en avoir trop, sinon cela complexifie le choix pour l’utilisateur.

🧩 Ajouter des labels personnalisés

Pour créer ou gérer vos labels, allez dans Manage > Labels.

Les labels sont très utiles pour :

• filtrer rapidement les tickets dans les tableaux de bord,

• attribuer des niveaux de priorité (urgent, low-priority, etc.),

• catégoriser les tickets (backend, data, CI/CD, etc.),

• visualiser la répartition des tâches par domaine.

Je ferais surement un article dédié sur le sujet, avec notamment des propositions de labels pour vos projets.

🔗 Lier des issues entre elles

Chaque ticket peut être relié à un ou plusieurs autres. Cela permet de documenter la logique métier, les dépendances techniques ou la séquence des tâches.

Vous pouvez :

• créer une hiérarchie parent-enfant : la tâche principale ne sera considérée comme terminée que si toutes ses sous-tâches sont closes,

• ajouter des liens de dépendance : “bloque”, “bloqué par”, “lié à”, etc. La qualification fine de la dépendance nécessite un compte premium.

💡 Astuce : précisez les niveaux de dépendances également dans la description de l’issue (dans le DoR par exemple). Cela permet une lecture immédiate sans avoir à cliquer sur les liens associés.

Nous verrons plus en détail comment exploiter ces relations pour piloter vos projets efficacement dans un prochain article.

Conclusion

Adopter les issues et les MR, c’est faire un pas vers un développement plus lisible, plus fiable, et plus collaboratif.

Commencez dès aujourd’hui avec une issue et une MR, ajoutez progressivement des labels, et voyez les effets rapidement sur un sprint.

👉 Dites-moi en commentaire quelle est la pratique GitLab que vous allez adopter dès maintenant !