Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools
Gouvernance: maîtriser les labels et les issues templates
Date de l'article:04-07-2026
CI/CD Gitlab
INFO PROJET
Jusqu'à présent, nous nous sommes concentrés sur la qualité du code et sur la fiabilité des pipelines.
La CI/CD est opérationnelle
Les branches sensibles sont protégées.
L'architecture est en place.
Les branches sensibles sont protégées.
L'architecture est en place.
Un projet ne se limitant toutefois pas aux pipelines,
Nous allons à présent voir les labels et les issue templates (modèles d'issues) qui sont deux étapes essentielles à mettre en place afin d'organiser, standardiser et automatiser le suivi de projet.
Les labels
Commençons par créer les labels; Ceux-ci nous seront utiles pour la catégorisation et le suivi des tâches (tickets, requêtes de fusion et épopées).
Ils nous serviront également plus tard dans la mise en place de la Merge Request Automatic.
Les labels d'un projet sont souvent sous-estimés. Pourtant, ils constituent un outil essentiel pour organiser et suivre efficacement les différentes tâches.
Ils permettent notamment de :
- Filtrer les Issues
- Filtrer les Merge Requests
- Piloter un sprint
- Suivre l'état d'une fonctionnalité
- Identifier rapidement les priorités
Créer les labels: à partir du projet, rendez-vous dans Manage → Labels
Les labels peuvent accompagner les différentes étapes du cycle de vie d'une tâche. Ils permettent ainsi d'obtenir une vue directe et globale de l'activité.
Priorités
low medium high critical
low medium high critical
Status
ready in progress blocked review testing
ready in progress blocked review testing
Environments:
develop staging production
develop staging production
release:
release hotfix automate
release hotfix automate
La liste des labels utilisés est disponible dans: .gitlab/Labels.md
Au final, on obtient une vingtaine de labels. Cela peut sembler beaucoup, mais leur organisation permet ensuite de disposer d'une vue claire et structurée.
Création des labels 
Un label doit apporter une information utile
L'objectif est de pouvoir comprendre rapidement la nature d'une tâche sans avoir à ouvrir chaque Issue ou Merge Request. Les labels deviennent ainsi un véritable outil de lecture et de pilotage du projet.
L'objectif est de pouvoir comprendre rapidement la nature d'une tâche sans avoir à ouvrir chaque Issue ou Merge Request. Les labels deviennent ainsi un véritable outil de lecture et de pilotage du projet.
La bonne pratique est de privilégier un nombre limité de catégories clairement définies plutôt que de créer un nouveau label pour chaque situation.
Ces labels peuvent ensuite être exploités dans les "Issue Boards" afin de filtrer et de visualiser les tâches selon leur état, leur priorité ou leur contexte.
On passe ainsi d'une simple liste de tickets à une véritable vue de pilotage du projet.
On passe ainsi d'une simple liste de tickets à une véritable vue de pilotage du projet.
Les labels prennent surtout leur sens lorsqu'ils sont combinés.
Une même Issue peut recevoir plusieurs labels afin de décrire rapidement son contexte, sa priorité et son état d'avancement.
Une même Issue peut recevoir plusieurs labels afin de décrire rapidement son contexte, sa priorité et son état d'avancement.
En CI/CD (Intégration Continue et Déploiement Continu), les labels permettent notamment d'ajouter une information de contexte aux Issues et aux Merge Requests.
Ils peuvent ensuite être exploités dans le workflow pour faciliter le suivi, le filtrage ou certaines automatisations.
Ils peuvent ensuite être exploités dans le workflow pour faciliter le suivi, le filtrage ou certaines automatisations.
Exemple : un bug bloquant en production
critical blocked production
En un coup d'oeil, on comprend qu'il s'agit d'un problème critique, actuellement bloqué, qui concerne l'environnement de production.
Exemple : une fonctionnalité en cours de développement
medium in progress develop
Cette combinaison indique une fonctionnalité de priorité moyenne, actuellement en cours de développement sur l'environnement de développement.
Exemple : une mise en production
high ready staging release
La tâche est prioritaire, prête à être traitée, validée sur l'environnement de staging et identifiée comme faisant partie d'une release.
Bonne pratique : les labels doivent permettre de comprendre rapidement une Issue sans devoir parcourir tout son contenu. Ils deviennent particulièrement utiles lorsqu'ils sont utilisés de manière cohérente sur l'ensemble du projet.
Une passerelle vers la CI/CD
Les labels ne servent pas uniquement à organiser visuellement le projet.
Ils peuvent également être utilisés comme des informations d'entrée pour automatiser certaines étapes du workflow.
Ils peuvent également être utilisés comme des informations d'entrée pour automatiser certaines étapes du workflow.
Dans GitLab CI/CD, les règles rules: permettent notamment de conditionner l'exécution d'un job en fonction des informations disponibles sur une Merge Request.
Il est par exemple possible de vérifier la présence d'un label grâce à la variable:
Il est par exemple possible de vérifier la présence d'un label grâce à la variable:
rules:
- if: '$CI_MERGE_REQUEST_LABELS =~ /staging/' Avec cette règle, une Merge Request portant le label staging
pourrait permettre, par exemple, d'exécuter un job vers l'environnement de staging
pourrait permettre, par exemple, d'exécuter un job vers l'environnement de staging
De la même manière, un label tel que automate peut servir de déclencheur logique pour exécuter certains traitements spécifiques comme des tests et/ou vérifications supplémentaires ou opérations automatisées.
Les labels deviennent ainsi un véritable lien entre la gestion du projet et l'automatisation CI/CD. Une information ajoutée par un développeur dans GitLab peut alors être réutilisée par le pipeline pour adapter son comportement.
Dans ce cas, les labels peuvent devenir des éléments de pilotage du workflow, utilisés à la fois par les développeurs, par GitLab et par les pipelines CI/CD.
Les Issue Templates
Contexte:
Sans modèle, chaque développeur peut décrire une anomalie ou une demande à sa manière.
Certaines informations essentielles peuvent alors être oubliées : version concernée, étapes de reproduction, captures d'écran, logs, environnement, etc.
Quelques exemples:
Les rapports de bugs: permettent de distinguer le comportement attendu du comportement réel.
Les demandes de fonctionnalités: structurent le besoin, le scénario utilisateur et le bénéfice attendu.
Le support interne: fournit un formulaire pour les demandes d'assistance adressées aux équipes.
Vous pouvez créer autant de modèles que vous désirez, par exemple pour la maintenance, la factorisation, les tâches techniques ou encore la réutilisation de certaines pratiques.
Dans leur simple utilisation, les templates d'issues permettent de standardiser la création des bugs, des demandes de fonctionnalités et des tâches techniques avant même de commencer le développement. Ils constituent le complément naturel des "Merge Request Templates", que nous verrons dans l'article suivant.
Création des modèles
Maintenant, que les labels existent, on peut normaliser la création des ticketsProcess :
- Créer un dossier nommé .gitlab/issue_templates
- Ajouter un fichier par modèle avec l'extension .md
- Rédiger le contenu du modèle en utilisant le format Markdown
.gitlab/
└── issue_templates/
├── Bug.md
├── Feature.md
└── Improvement.md
Ces templates seront automatiquement proposés par GitLab lors de la création d'une nouvelle tâche.
Issues templates details (exemples)
Vous pouvez vous aider d'un éditeur Markdown comme stackedit, qui permet notamment de visualiser facilement le rendu du document.
Rapport de bug
#.gitlab\issue_templates\Bug.md
# Bug Report
## Description
Describe the issue.
## Steps to reproduce
1.
2.
3.
## Expected behavior
Describe the expected behavior.
## Actual behavior
Describe what happened.
## Environment
- Branch:
- Pipeline:
- Java version:
## Additional information
Screenshots, logs or other useful information.
Nouvelle fonctionnalité
#.gitlab\issue_templates\Feature.md
# Feature Request
## Summary
Describe the proposed feature.
## Motivation
Why is this feature needed?
## Proposed solution
Describe your proposed implementation.
---
## Acceptance criteria
- [ ]
- [ ]
- [ ]
---
## Additional notes
D'autres modèles sont disponibles depuis le dossier .gitlab\issue_templates\
Des labels appliqués automatiquement
L'automatisation peut également fonctionner dans l'autre sens.
Les Issue Templates peuvent appliquer automatiquement des labels lors de la création d'une Issue.
Les Issue Templates peuvent appliquer automatiquement des labels lors de la création d'une Issue.
Pour cela, il est possible d'ajouter une Quick Actions
à la fin du fichier Markdown du template:
à la fin du fichier Markdown du template:
/label ~"status::ready" ~"priority::medium"Lorsque l'utilisateur sélectionne le template,
GitLab applique automatiquement les labels définis par la Quick Actions,
sous réserve que l'utilisateur dispose des permissions nécessaires.
GitLab applique automatiquement les labels définis par la Quick Actions,
sous réserve que l'utilisateur dispose des permissions nécessaires.
Cela permet de garantir qu'une Issue créée à partir d'un modèle commence déjà avec les informations de classification attendues.
On peut ainsi combiner les deux mécanismes : le template structure le contenu du ticket et les labels structurent son traitement.
Les templates d'Issues sont accessibles depuis le menu du projet : Projet → Menu : Plan > Work items > New
Utilisez le menu déroulant "Choose a template" pour sélectionner le modèle souhaité.
Le contenu du ticket est alors automatiquement pré-rempli avec les champs définis dans le modèle. Il ne reste plus qu'à décrire précisément l'Issue, ajouter les labels appropriés, assigner la personne concernée, etc.
Le ticket est alors intégré à votre liste "To Do", à vos " work Items" ainsi qu'au menu " Plan → Issue Boards"
Avantages en entreprise
Les templates constituent une pratique courante dans les équipes de développement professionnelles.
Ils permettent notamment de rendre les demandes plus homogènes et de limiter les informations manquantes lors de leur traitement.
Ils permettent notamment de rendre les demandes plus homogènes et de limiter les informations manquantes lors de leur traitement.
- Gain de temps: évite aux développeurs de devoir relancer l'émetteur pour obtenir les informations manquantes
- Standardisation: toutes les anomalies et demandes suivent une structure cohérente et identifiable
- Automatisation: facilite le tri, la catégorisation et, selon la configuration du projet, l'assignation des tâches
- Qualité des données: encourage la présence d'éléments importants comme la version, les étapes de reproduction, les logs et les captures d'écran
À ce stade du projet:
Les Merge Requests permettent une relecture avant intégration.
Les pipelines garantissent que chaque fusion respecte les contrôles définis.
Les labels facilitent le suivi des tâches.
Les templates assurent une description homogène des demandes.
Les pipelines garantissent que chaque fusion respecte les contrôles définis.
Les labels facilitent le suivi des tâches.
Les templates assurent une description homogène des demandes.
Étant seule sur le projet, l'objectif n'est pas de répondre à un besoin immédiat, mais plutôt de construire un environnement de travail réaliste, similaire à celui que l'on retrouve dans de nombreux projets professionnels.
Nous disposons maintenant de tous les éléments nécessaires pour poursuivre l'automatisation du workflow GitLab. Dans l'article suivant, nous nous intéresserons à la création de templates et intégrerons les labels à l'automatisation des Merge Requests.
Naviguez entre les articlesBrowse through the articles