Votre modèle de données pour le cycle de développement logiciel

GitLab
Votre modèle de données pour le cycle de développement logiciel

Votre modèle de données pour le cycle de développement logiciel

Ce modèle complet vous guide dans la préparation des données nécessaires à l’analyse du cycle de développement logiciel. Il présente les attributs à recueillir, les principales activités à suivre et des conseils pratiques pour extraire ces informations directement de GitLab. Vous pourrez ainsi préparer vos données pour le Process Mining en toute confiance.
  • Attributs recommandés à recueillir
  • Activités clés à suivre
  • Conseils d’extraction
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs du cycle de développement logiciel

Voici les champs de données recommandés dans votre journal d’événements pour analyser et optimiser le cycle de développement logiciel.
3 Obligatoire 5 Recommandé 12 Facultatif
Nom Description
Activité
Activity
Nom de l’étape ou de l’événement précis du processus, par exemple « Problème créé » ou « Demande de fusion intégrée ».
Description

L’attribut Activité recense les événements distincts qui surviennent pour un élément de développement. Dans GitLab, ils ne sont pas stockés dans un champ unique, mais sont déduits de différentes actions et de différents champs d’horodatage des problèmes, des demandes de fusion et des pipelines CI/CD. La création d’un problème, l’envoi d’un commit, l’échec d’un pipeline ou l’approbation d’une demande de fusion sont autant d’activités distinctes.

Cet attribut est indispensable pour créer la carte du processus, visualiser le flux de travail et analyser l’ordre et la fréquence des événements. Il sert à repérer les écarts, les goulots d’étranglement entre les étapes et les parcours les plus fréquents.

Pourquoi est-ce important ?

Il définit les étapes de la carte du processus et permet de visualiser et d’analyser le flux de travail de développement de bout en bout.

Où trouver ces données

L’attribut est déduit des types d’événements et des changements d’état dans le flux d’événements GitLab, ou de l’interprétation des champs d’horodatage tels que created_at, merged_at et closed_at des problèmes et des demandes de fusion.

Exemples
Problème crééDéveloppement commencéDemande de fusion intégréeÉchec du pipelineDéployé en production
Élément de développement
DevelopmentItem
Identifiant unique d’une unité de travail, comme une fonctionnalité, un correctif ou une tâche. Il sert d’identifiant principal du cas.
Description

L’élément de développement désigne une unité de travail distincte, qui peut être suivie tout au long du cycle de vie du développement logiciel. Il relie en un même cas toutes les activités associées, de la création au déploiement final. Dans GitLab, il s’agit généralement de l’ID interne (IID) du problème, unique au sein d’un projet.

L’analyse par élément de développement permet de mesurer le temps de cycle de bout en bout, de repérer les goulots d’étranglement et de vérifier la conformité du processus. Elle aide à comprendre avec quelle efficacité le travail passe du concept à la production.

Pourquoi est-ce important ?

Cet identifiant de cas essentiel relie tous les événements du processus et permet de retracer le cycle de vie complet de chaque élément de travail.

Où trouver ces données

Il s’agit généralement de l’ID interne (IID) d’un problème GitLab. Vous le trouverez dans la réponse de l’API Issues, dans le champ iid.

Exemples
1024512PRJ-2345
Heure de début
StartTime
Horodatage indiquant le début d’une activité ou d’un événement.
Description

StartTime indique la date et l’heure précises auxquelles une activité donnée s’est produite. Dans GitLab, les événements sont enregistrés dans différents champs d’horodatage. Par exemple, pour l’activité « Problème créé », StartTime correspond à l’horodatage created_at du problème ; pour l’activité « Demande de fusion intégrée », il correspond à l’horodatage merged_at de la demande de fusion.

Cet horodatage constitue l’élément temporel central du Process Mining. Il sert à classer les événements par ordre chronologique, à calculer les durées entre les activités, à mesurer les temps de cycle et à analyser l’évolution des performances du processus.

Pourquoi est-ce important ?

Cet attribut établit l’ordre chronologique des événements, indispensable au calcul de toutes les métriques temporelles et à la compréhension du déroulement du processus.

Où trouver ces données

L’attribut est extrait de différents champs d’horodatage de GitLab, tels que created_at, updated_at et closed_at des problèmes, ainsi que merged_at des demandes de fusion.

Exemples
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Gravité
Severity
Niveau de gravité de l’élément de développement, généralement dans le cas d’un bogue ou d’un incident.
Description

La gravité indique l’impact d’un bogue ou d’un problème, de critique à mineur. GitLab ne comporte pas de champ de gravité natif ; cette information est donc presque toujours gérée au moyen d’étiquettes, par exemple severity::1 ou severity::2.

Cet attribut est essentiel au Dashboard « Évolution des escalades de gravité » et au KPI associé. L’analyse des changements de gravité au cours du cycle de vie peut révéler des problèmes initialement sous-estimés ou des processus qui aggravent la situation.

Pourquoi est-ce important ?

Cet attribut aide à établir les priorités et à vérifier si les éléments les plus graves sont traités plus rapidement. Le suivi des changements permet de calculer le KPI « Fréquence des escalades de gravité ».

Où trouver ces données

L’attribut est déduit des étiquettes appliquées à un problème GitLab. Une association est nécessaire pour interpréter des étiquettes comme S1 ou S2 en tant que niveaux de gravité.

Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
Heure de fin
EndTime
Horodatage indiquant la fin d’une activité ou d’un événement.
Description

EndTime indique la date et l’heure précises auxquelles une activité s’est terminée. Pour de nombreux événements ponctuels dans GitLab, comme « Problème créé », EndTime est identique à StartTime. Pour les activités qui ont une durée, comme la revue du code, il correspond à l’horodatage de fin, par exemple celui de l’approbation finale.

Cet attribut est essentiel pour calculer avec précision la durée des activités (durée de traitement). Il permet d’analyser les goulots d’étranglement en distinguant le temps consacré au travail effectif sur une tâche du temps d’attente entre les tâches.

Pourquoi est-ce important ?

Il permet de calculer précisément la durée des activités (temps de traitement), ce qui aide à repérer les étapes inefficaces du processus.

Où trouver ces données

Pour les événements ponctuels, cette valeur est identique à StartTime. Pour les activités qui ont une durée, elle doit être déduite d’un événement de fin correspondant dans les données.

Exemples
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Nom du projet
ProjectName
Nom du projet GitLab auquel appartient l’élément de développement.
Description

Cet attribut identifie le dépôt de code ou le projet dans lequel le travail est effectué. Dans GitLab, chaque problème et chaque demande de fusion appartient à un projet.

L’analyse par nom de projet permet de comparer les performances de différents produits, composants ou services. Elle peut révéler si certains projets suivent un SDLC plus efficace que d’autres et permet de filtrer les Dashboards sur un domaine précis.

Pourquoi est-ce important ?

Il permet de segmenter l’analyse du processus par produit, application ou composant, afin de cibler les efforts d’amélioration.

Où trouver ces données

La valeur est extraite des champs name ou path_with_namespace de l’API Project, à partir du project_id des problèmes et des demandes de fusion.

Exemples
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Personne affectée
Assignee
Utilisateur affecté au problème ou à la demande de fusion au moment de l’événement.
Description

La personne affectée est le développeur ou l’utilisateur responsable de l’élément de travail à un moment donné du processus. Dans GitLab, cette information figure dans le champ assignee ou assignees d’un problème ou d’une demande de fusion.

L’analyse par personne affectée est essentielle au Dashboard « Charge de travail et répartition des développeurs ». Elle aide à comprendre l’utilisation des ressources, à repérer les personnes ou les équipes surchargées et à analyser les transferts entre collaborateurs.

Pourquoi est-ce important ?

Cet attribut indique qui a effectué le travail. Il permet d’analyser la charge de travail et l’efficacité de la répartition des ressources, ainsi que de repérer les retards dus aux transferts.

Où trouver ces données

La valeur est extraite des champs assignee.username ou assignees des réponses des API GitLab Issues et Merge Requests.

Exemples
jdoeasmithr.williams
Type d’élément de développement
DevelopmentItemType
Classification de l’élément de développement, par exemple « Fonctionnalité », « Bogue », « Tâche » ou « Maintenance ».
Description

Cet attribut classe la nature du travail effectué. Dans GitLab, cette classification repose généralement sur les étiquettes d’un problème. Les équipes s’en servent pour distinguer les nouvelles fonctionnalités, la correction de défauts, la dette technique et d’autres types de travaux.

L’analyse par type d’élément de développement permet de comparer les flux de processus et les temps de cycle selon la nature du travail. Vous pouvez, par exemple, vérifier si les bogues sont corrigés plus rapidement que les fonctionnalités ne sont développées, ou si les tâches liées à la dette technique suivent un processus de revue différent.

Pourquoi est-ce important ?

La segmentation du processus par type de travail permet de repérer les catégories plus susceptibles d’entraîner des retards, des reprises ou des écarts.

Où trouver ces données

L’attribut est généralement déduit des étiquettes appliquées à un problème GitLab. Une logique d’association est nécessaire pour convertir les étiquettes spécifiques en types standardisés.

Exemples
FonctionnalitéBogueTâcheDette technique
Branche cible
TargetBranch
Nom de la branche de destination d’une demande de fusion.
Description

La branche cible est celle dans laquelle les modifications doivent être fusionnées, par exemple « main », « develop » ou une branche de version telle que « release/1.5 ». C’est une information essentielle pour toute demande de fusion.

L’analyse par branche cible peut révéler des différences dans le déroulement du processus selon la destination du code. Par exemple, les fusions vers « main » peuvent nécessiter une procédure d’approbation plus stricte et présenter des temps de cycle plus longs que celles vers une branche de fonctionnalité. Cette analyse peut également aider à distinguer les déploiements en production des autres types d’intégration du code.

Pourquoi est-ce important ?

Permet de distinguer les différents flux de développement et de publication, car le processus peut varier considérablement selon la branche de destination.

Où trouver ces données

Récupéré dans le champ « target_branch » de la réponse de l’API GitLab Merge Requests.

Exemples
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Dernière mise à jour des données
LastDataUpdate
Horodatage indiquant la dernière actualisation des données de cet événement depuis le système source.
Description

Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données de l’événement dans le jeu de données de Process Mining. Il ne correspond pas au moment où l’événement s’est produit, mais à la dernière synchronisation de son enregistrement.

Cette information est essentielle pour connaître l’actualité des données et vérifier que l’analyse du processus repose sur des données récentes. Elle aide les utilisateurs à savoir si les Dashboards et les KPI sont à jour et à tenir compte du délai éventuel entre le système source et l’analyse.

Pourquoi est-ce important ?

Cet attribut indique clairement l’actualité des données et permet aux utilisateurs de savoir dans quelle mesure l’analyse du processus est à jour.

Où trouver ces données

Cet horodatage est généré et enregistré par l’outil d’extraction des données ou le processus ETL lors de leur actualisation.

Exemples
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Nom de l’équipe
TeamName
Équipe de développement associée au projet ou à la personne affectée.
Description

Nom de l’équipe désigne le groupe ou l’équipe responsable de l’élément de développement. Cette information ne figure généralement pas dans un champ standard de GitLab. Elle est souvent déduite des conventions de nommage des projets, de la structure des groupes ou d’une table de référence externe qui associe les personnes affectées à leurs équipes.

Cet attribut permet d’analyser les performances du processus à l’échelle d’une équipe. Il aide à comparer l’efficacité, la charge de travail et le respect du processus entre les équipes, et à alimenter des Dashboards comme « Analyse des goulots d’étranglement par étape » selon une perspective par équipe.

Pourquoi est-ce important ?

Il permet d’analyser les performances et de comparer les processus entre les équipes, afin de repérer les goulots d’étranglement propres à chacune ou de mettre en évidence les bonnes pratiques.

Où trouver ces données

L’attribut est souvent déduit du nom du projet ou de la personne affectée, à partir d’une structure d’équipe définie en dehors de GitLab, ou de la hiérarchie des groupes GitLab.

Exemples
Frontend-AlphaBackend-ServicesPlatform-Infra
Reprise
IsRework
Indicateur booléen précisant si une activité fait partie d’une boucle de reprise.
Description

Cet attribut calculé signale les activités qui correspondent à un retour en arrière dans le processus, par exemple lorsqu’un travail de développement reprend après le début des tests. La logique de cet indicateur consiste généralement à repérer certaines séquences d’activités, comme un événement « Début du développement » survenant après un événement « Échec du pipeline » ou « Début des tests d’assurance qualité » pour le même cas.

Cet attribut alimente directement le Dashboard « Analyse des reprises et des nouvelles exécutions » ainsi que le KPI « Taux de reprise après les tests ». Il facilite le filtrage et la quantification des reprises, afin que les équipes puissent en comprendre la fréquence, les causes et les effets sur les délais des projets.

Pourquoi est-ce important ?

Signale et quantifie directement les reprises, ce qui facilite l’analyse des causes et des effets des inefficacités du processus et des problèmes de qualité.

Où trouver ces données

Calculé par l’outil de Process Mining, qui analyse la séquence des activités de chaque cas pour repérer les schémas révélateurs de reprises.

Exemples
truefalse
Statut de l’élément de développement
DevelopmentItemStatus
Statut de l’élément de développement au moment de l’événement, par exemple « Ouvert », « En cours » ou « Fermé ».
Description

Cet attribut indique l’état de l’élément de travail principal, généralement un problème GitLab. Les problèmes GitLab ont un champ state dont la valeur peut être opened ou closed. Les statuts plus détaillés sont souvent gérés à l’aide d’étiquettes avec portée, par exemple Status::Triage, Status::In-Dev ou Status::In-Review.

Le suivi des changements de statut est essentiel pour comprendre le cycle de vie du cas. Il permet de savoir combien de temps les éléments passent dans chaque état et de filtrer les travaux en cours ou terminés dans des Dashboards comme « Temps de cycle du SDLC de bout en bout ».

Pourquoi est-ce important ?

Cet attribut donne un aperçu de l’état du cas. Il permet d’analyser le temps passé à chaque étape et de distinguer les travaux en cours des travaux terminés.

Où trouver ces données

Le statut principal provient du champ state d’un problème GitLab (opened ou closed). Les statuts plus détaillés sont souvent déduits des étiquettes.

Exemples
ouvertferméEn coursEn revue
Statut de la demande de fusion
MergeRequestStatus
Statut de la demande de fusion associée à l’événement, par exemple « Ouverte », « Fusionnée » ou « Fermée ».
Description

Cet attribut indique l’état d’une demande de fusion (MR) au moment de l’événement. Dans GitLab, les MR peuvent avoir différents états : « opened », « closed », « merged » ou « locked ». Cet état est distinct du statut général de l’élément de développement.

Le suivi du statut des MR permet d’analyser la phase d’intégration du code dans le cycle de vie du développement logiciel (SDLC). Il alimente directement des Dashboards comme « Temps de cycle et débit des revues de code » et aide à repérer les délais entre la création d’une MR, sa revue, son approbation et sa fusion.

Pourquoi est-ce important ?

Donne une vue sur la revue et la fusion du code, une étape qui constitue souvent un goulot d’étranglement important dans le SDLC.

Où trouver ces données

Récupéré dans le champ « state » de la réponse de l’API GitLab Merge Requests.

Exemples
ouvertmergedfermélocked
Statut du pipeline
PipelineStatus
Statut de l’exécution du pipeline CI/CD, par exemple « Réussi », « Échoué » ou « En cours ».
Description

Cet attribut indique le résultat de l’exécution d’un pipeline CI/CD associé à un commit ou à une demande de fusion. Dans GitLab, les statuts courants sont « running », « pending », « success », « failed », « canceled » et « skipped ».

Ces données sont essentielles au Dashboard « Analyse des reprises et des nouvelles exécutions ». Les échecs fréquents des pipelines peuvent entraîner des reprises et des retards importants. Analyser leur fréquence, leur origine et leurs conséquences aide à améliorer l’efficacité du développement et la qualité du code.

Pourquoi est-ce important ?

Suit la réussite ou l’échec des compilations et des tests automatisés, et met en évidence les boucles de reprise ainsi que les problèmes de qualité du code ou d’automatisation des tests.

Où trouver ces données

Récupéré dans le champ « status » de la réponse de l’API GitLab CI/CD Pipelines.

Exemples
successfailedrunningcanceled
Système source
SourceSystem
Indique le système d’où proviennent les données.
Description

Cet attribut précise l’origine des données du processus. Dans ce modèle de données, sa valeur sera toujours « GitLab ».

Cet attribut est particulièrement utile lorsque les données de processus proviennent de plusieurs systèmes, par exemple Jira pour la planification et GitLab pour l’exécution. Il permet de filtrer et de segmenter les données, tout en préservant leur traçabilité.

Pourquoi est-ce important ?

Il clarifie l’origine des données, un point important pour leur gouvernance et l’intégration de données provenant de plusieurs systèmes d’entreprise.

Où trouver ces données

Cette valeur statique, « GitLab », est ajoutée lors de la transformation des données.

Exemples
GitLab
Temps d’attente lors du transfert
HandoffWaitTime
Temps d’inactivité calculé entre deux activités consécutives réalisées par des personnes affectées différentes.
Description

Cette métrique mesure le délai entre la fin d’une activité et le début de la suivante, lorsque la personne affectée change. Par exemple, elle mesure le temps écoulé entre la fin du travail d’un développeur et le début de la revue de code par un réviseur.

C’est la métrique principale du KPI « Temps d’attente moyen lors d’un transfert ». Elle aide à repérer les inefficacités cachées dans la répartition des ressources et la communication entre les équipes ou les personnes, en mettant en évidence les délais qui ne correspondent à aucune activité en cours.

Pourquoi est-ce important ?

Quantifie le temps d’inactivité lors des transferts entre personnes ou équipes et révèle les retards cachés ainsi que les problèmes de communication.

Où trouver ces données

Calculé par l’outil de Process Mining. Le calcul nécessite d’analyser les événements consécutifs d’un cas, de vérifier si la personne affectée a changé, puis de calculer l’écart de temps.

Exemples
1 jour et 2 heures15 minutes8 heures
Temps de cycle
CycleTime
Durée totale entre la première et la dernière activité d’un élément de développement.
Description

Le temps de cycle est une métrique calculée qui mesure la durée totale d’un cas. Il correspond généralement à l’écart entre le tout premier événement (par exemple, « Création du ticket ») et le dernier (par exemple, « Déploiement en production ») pour un même élément de développement.

C’est un KPI essentiel pour mesurer l’efficacité globale du processus. Il constitue la métrique principale de Dashboards comme « Temps de cycle de bout en bout du SDLC » et permet de suivre les améliorations ainsi que de repérer les cas qui s’éternisent et peuvent révéler des problèmes systémiques.

Pourquoi est-ce important ?

Ce KPI central du Process Mining mesure l’efficacité de bout en bout du cycle de développement.

Où trouver ces données

Calculé par l’outil de Process Mining en soustrayant le StartTime minimum du StartTime maximum pour chaque CaseId unique.

Exemples
10 jours et 4 heures23 heures et 15 minutes35 jours
Titre du jalon
MilestoneTitle
Titre du jalon ou du sprint auquel l’élément de développement est affecté.
Description

Dans GitLab, un jalon sert à suivre le travail lié à un objectif ou à une période définie, comme un sprint ou une version. Cet attribut indique le nom ou le titre de ce jalon.

Il permet d’analyser les performances du processus dans le contexte de sprints ou de périodes de planification spécifiques. Vous pouvez ainsi vérifier si les temps de cycle diminuent d’un sprint à l’autre ou filtrer la vue du processus pour n’afficher que le travail lié à une prochaine version.

Pourquoi est-ce important ?

Relie le travail de développement aux cycles de planification, comme les sprints ou les versions, afin d’analyser les résultats au regard des périodes prévues.

Où trouver ces données

Récupéré dans le champ « milestone.title » des réponses de l’API GitLab Issues ou Merge Requests.

Exemples
Version du T4 2023Sprint 23.11Phase 1 : MVP
Version de publication
ReleaseVersion
Version logicielle prévue ou réelle associée au déploiement.
Description

Cet attribut identifie la version logicielle à laquelle appartient un élément de développement. Dans GitLab, cette information peut être associée à un jalon, à une étiquette protégée ou à une entrée dans la fonctionnalité Releases.

Cet attribut est essentiel au Dashboard « Suivi du respect du calendrier des versions ». En comparant la date réelle du déploiement à la date prévue pour la version, les organisations peuvent mesurer leur capacité à respecter le calendrier et déterminer les causes des retards de publication.

Pourquoi est-ce important ?

Associe les éléments de développement à une version logicielle précise, ce qui permet de suivre l’avancement de la publication et le respect du calendrier.

Où trouver ces données

Cette information peut provenir de GitLab Releases, du nom d’une étiquette git ou du titre d’un jalon utilisé pour planifier une version.

Exemples
v1.2.0v3.0.0-beta2023.4.1
Obligatoire Recommandé Facultatif

Activités du cycle de développement logiciel

Voici les principales étapes et les principaux jalons à consigner dans votre journal d’événements pour découvrir le processus avec précision et repérer les goulots d’étranglement.
4 Recommandé 8 Facultatif
Activité Description
Demande de fusion créée
Cet événement indique que le travail de développement initial est terminé et que le code est prêt à être examiné et intégré. Il s’agit d’un événement explicite et central du flux de travail GitLab, enregistré lorsqu’un développeur ouvre une demande de fusion (MR).
Pourquoi est-ce important ?

Cette étape importante marque le passage du développement à la revue et aux tests. Elle constitue le point de départ de l’analyse de l’ensemble du cycle de revue du code et du pipeline CI/CD.

Où trouver ces données

Cet événement explicite est enregistré à partir de l’horodatage created_at de la table merge_requests ou au moyen de l’API Merge Requests.

Données à recueillir

Utilisez l’horodatage created_at de la demande de fusion.

Type d’événement explicit
Demande de fusion intégrée
Cette activité marque la fin réussie de la revue et de l’intégration du code. Il s’agit d’un événement explicite qui se produit lorsqu’un utilisateur intègre la branche de la demande de fusion à la branche cible.
Pourquoi est-ce important ?

Cette étape importante indique que le développement et la revue sont terminés. Elle marque la fin de la mesure du temps de cycle de développement et le début de celle du délai de mise en production.

Où trouver ces données

Cet événement explicite est enregistré à partir de l’horodatage merged_at de la table merge_requests. Une note système est également créée lors de l’intégration.

Données à recueillir

Utilisez l’horodatage merged_at de la demande de fusion.

Type d’événement explicit
Déployé en production
Cette activité marque le déploiement réussi du code dans l’environnement de production, où il devient accessible aux utilisateurs finaux. Elle est enregistrée lorsqu’une tâche spécifique de déploiement en production se termine avec succès dans un pipeline CI/CD GitLab.
Pourquoi est-ce important ?

Il s’agit de l’événement de fin principal du processus, qui indique que la valeur a été livrée. Il est essentiel pour mesurer le temps de cycle total du SDLC de bout en bout et la fréquence des mises en production.

Où trouver ces données

L’événement est extrait de l’horodatage finished_at d’une tâche CI/CD réussie, spécifiquement désignée pour le déploiement en production. La fonctionnalité Environments de GitLab en assure le suivi explicite.

Données à recueillir

Utilisez l’horodatage finished_at de la tâche CI de déploiement en production réussie.

Type d’événement explicit
Problème créé
Cette activité marque le début du cycle de développement : elle correspond à la création d’un nouvel élément de travail, par exemple une fonctionnalité, un bogue ou une tâche. Elle est enregistrée explicitement lorsqu’un utilisateur crée un problème dans GitLab, qui consigne alors l’horodatage de création.
Pourquoi est-ce important ?

Il s’agit de l’événement de début principal du processus de bout en bout. L’analyse du délai entre la création du problème et le déploiement donne une vue complète du temps de cycle du SDLC.

Où trouver ces données

Cet événement explicite est enregistré à partir de l’horodatage created_at de la table issues ou au moyen de l’API Issues. Les notes système consignent également la création.

Données à recueillir

Utilisez l’horodatage created_at du problème.

Type d’événement explicit
Approbation ajoutée
Cet événement correspond à l’approbation formelle des modifications de code d’une demande de fusion par une personne chargée de la revue. GitLab l’enregistre explicitement lorsqu’un utilisateur clique sur le bouton « Approuver ».
Pourquoi est-ce important ?

Les approbations constituent des points de contrôle de la qualité. Leur suivi permet d’analyser le délai nécessaire pour obtenir les validations requises et de vérifier le respect des politiques de revue.

Où trouver ces données

L’événement est extrait des approbations de demandes de fusion, disponibles au moyen de l’API Approvals ou dans l’historique de la demande de fusion.

Données à recueillir

Utilisez l’horodatage de l’événement d’approbation de la demande de fusion dans le journal d’événements.

Type d’événement explicit
Déploiement commencé
Cet événement correspond au début du processus de mise en production du code dans un environnement donné, par exemple de préproduction ou de production. Dans GitLab, il correspond au démarrage d’une tâche `deploy` dans un pipeline CI/CD.
Pourquoi est-ce important ?

Le suivi du début du déploiement permet d’isoler la durée de cette phase. Il est essentiel pour mesurer et optimiser le délai de mise en production.

Où trouver ces données

L’événement est extrait de l’horodatage started_at d’une tâche CI/CD configurée comme tâche de déploiement. Cette fonctionnalité fait partie des environnements et déploiements GitLab.

Données à recueillir

Utilisez l’horodatage started_at du journal de la tâche CI de déploiement.

Type d’événement explicit
Développement commencé
Cette activité marque le début du travail de programmation sur le problème. Elle est généralement déduite du premier commit envoyé sur une branche associée au problème, car GitLab ne propose pas de bouton explicite « démarrer le développement ».
Pourquoi est-ce important ?

Elle permet de déterminer le début exact du travail de développement qui crée de la valeur, de mesurer précisément la phase de programmation et de la distinguer du temps consacré à la planification ou à l’attente dans une file.

Où trouver ces données

L’événement est déduit de l’horodatage du premier commit sur une branche de fonctionnalité liée au problème. Il faut pour cela associer les problèmes aux branches, souvent à l’aide de conventions de nommage ou de métadonnées.

Données à recueillir

Recherchez l’horodatage du premier commit sur une branche associée à l’ID du problème.

Type d’événement inferred
Échec du pipeline
Cette activité se produit lorsqu’une exécution de pipeline CI/CD échoue à une étape, par exemple en cas d’erreur de compilation ou d’échec d’un test. GitLab enregistre explicitement le statut final de chaque pipeline, ce qui permet de repérer facilement les échecs.
Pourquoi est-ce important ?

Les échecs de pipeline sont une cause majeure de reprises. L’analyse de leur fréquence, de leur durée et de leurs causes permet de repérer les problèmes de qualité, les tests instables et les goulots d’étranglement dans la boucle de retour aux développeurs.

Où trouver ces données

L’échec est repéré grâce au statut failed d’un enregistrement de pipeline dans la table ci_pipelines. L’horodatage finished_at indique quand il s’est produit.

Données à recueillir

Filtrez les enregistrements de pipeline dont le statut est failed, puis utilisez l’horodatage finished_at.

Type d’événement explicit
Pipeline démarré
Cet événement correspond au lancement d’un pipeline CI/CD automatisé, qui exécute généralement des compilations, des tests et des analyses de sécurité. GitLab crée explicitement un enregistrement de pipeline avec un horodatage de début chaque fois qu’un pipeline est déclenché, par exemple à la suite d’un commit ou de la création d’une demande de fusion.
Pourquoi est-ce important ?

Le suivi des exécutions de pipeline est essentiel pour surveiller l’état et l’efficacité des processus automatisés de test et d’intégration. Il permet de déterminer le temps consacré à la validation automatisée.

Où trouver ces données

L’événement est extrait de l’horodatage created_at ou started_at d’un enregistrement de pipeline dans la table ci_pipelines ou au moyen de l’API Pipelines.

Données à recueillir

Utilisez l’horodatage de l’enregistrement d’exécution du pipeline associé à la branche de la demande de fusion.

Type d’événement explicit
Problème attribué
Cette activité correspond à l’attribution d’un problème à un développeur ou à une équipe en particulier. Elle indique qu’une personne ou une équipe est désormais responsable du travail. GitLab enregistre explicitement cet événement chaque fois que le champ de personne affectée d’un problème est renseigné ou modifié.
Pourquoi est-ce important ?

Le suivi des attributions est essentiel pour analyser la répartition des ressources, la charge de travail des équipes et les délais de transfert. Il permet de repérer les retards entre la création d’un travail et sa prise en charge.

Où trouver ces données

L’événement est extrait des notes système de GitLab associées au problème, qui indiquent l’ajout ou la modification d’une personne affectée. Son horodatage figure dans la note.

Données à recueillir

Extrayez des notes système du problème les événements de modification de la personne affectée.

Type d’événement explicit
Problème fermé
Cette activité correspond à la clôture administrative finale de l’élément de travail, généralement après le déploiement et la vérification des modifications. GitLab enregistre explicitement cet événement lorsqu’un utilisateur ferme le problème.
Pourquoi est-ce important ?

La fermeture d’un problème marque souvent la fin de tous les travaux associés. Comparer cette date à celle du déploiement peut révéler des retards dans la validation après déploiement ou dans les processus administratifs.

Où trouver ces données

Cet événement explicite est enregistré à partir de l’horodatage closed_at de la table issues ou de la note système correspondante.

Données à recueillir

Utilisez l’horodatage closed_at du problème.

Type d’événement explicit
Revue de code commencée
Cet événement marque le début de la revue par les pairs d’une demande de fusion. Il est déduit de la première action liée à la revue, par exemple le premier commentaire ou fil de discussion publié par une personne autre que l’auteur.
Pourquoi est-ce important ?

Mesurer le délai entre la création de la demande de fusion et le début de la revue permet de repérer les attentes dans la file. Réduire ce délai est essentiel pour raccourcir le cycle global de revue du code.

Où trouver ces données

L’événement est déduit de l’horodatage du premier commentaire ou fil de discussion sur la demande de fusion publié par une personne autre que son auteur. Ces données sont disponibles dans les notes système ou au moyen de l’API Notes.

Données à recueillir

Recherchez l’horodatage du premier commentaire sur une demande de fusion publié par une personne autre que son auteur.

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis GitLab

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données et commencer à optimiser votre cycle de développement logiciel. Commencez dès aujourd’hui à améliorer votre processus !

Améliorez votre cycle de développement logiciel : commencez l’optimisation dès maintenant

Éliminez les goulots d’étranglement du SDLC, réduisez le temps de cycle de 30 % et améliorez la qualité.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Commencez à optimiser dès maintenant.