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

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

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

Ce modèle complet vous guide à travers les points de données essentiels nécessaires à l’analyse de votre processus de cycle de vie du développement logiciel. Il présente les attributs importants à collecter, les activités clés à suivre et des conseils pratiques pour extraire directement ces informations de GitLab. Grâce à cette ressource, vous pouvez préparer vos données en toute confiance pour réaliser une analyse Process Mining pertinente.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d’extraction
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs du cycle de vie du développement logiciel

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser et optimiser de manière complète le cycle de vie du 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 qui s’est produit, comme « Issue Created » ou « Merge Request Merged ».
Description

L’attribut Activité recense les événements distincts qui se produisent pour un élément de développement. Ces événements ne sont pas stockés dans un champ unique de GitLab, mais sont déduits de différentes actions et de différents champs d’horodatage dans les issues, les merge requests et les pipelines CI/CD. Par exemple, la création d’une issue, l’envoi d’un commit, l’échec d’un pipeline ou l’approbation d’une merge request sont autant d’activités distinctes.

Cet attribut est fondamental pour créer la carte du processus, visualiser le flux de travail et analyser la séquence ainsi que la fréquence des événements. Il sert à identifier les écarts, les goulots d’étranglement entre les étapes et les parcours courants du processus.

Pourquoi c’est important

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

Où les obtenir

L’attribut est dérivé des types d’événements et des changements d’état du flux d’événements GitLab, ou de l’interprétation de champs d’horodatage tels que « created_at », « merged_at » et « closed_at » dans les Issues et les Merge Requests.

Exemples
Issue crééeDéveloppement commencéMerge Request fusionnéePipeline en échecDéployé en production
Élément de développement
DevelopmentItem
Identifiant unique d’une unité de travail, telle qu’une fonctionnalité, un correctif ou une tâche, servant d’identifiant principal du cas.
Description

L’élément de développement représente une unité de travail unique et traçable qui progresse au sein du cycle de vie du développement logiciel. Il relie toutes les activités associées, de la création au déploiement final, au sein d’un même cas cohérent. Dans GitLab, il correspond généralement à l’identifiant interne (IID) de l’Issue, qui est 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, d’identifier les goulots d’étranglement et de vérifier la conformité des processus. Elle constitue la base nécessaire pour comprendre avec quelle efficacité le travail passe du concept à la production.

Pourquoi c’est important

Il s’agit de l’identifiant de cas essentiel qui relie tous les événements du processus et permet de retracer le cycle de vie complet d’un élément de travail donné.

Où les obtenir

Il s’agit généralement de l’identifiant interne (IID) d’une Issue GitLab. Il figure dans la réponse de l’API Issues, dans le champ « iid ».

Exemples
1024512PRJ-2345
Heure de début
StartTime
Horodatage indiquant le moment où une activité ou un événement a commencé.
Description

StartTime indique la date et l’heure précises auxquelles une activité donnée s’est produite. Pour les événements GitLab, cette information est capturée dans différents champs d’horodatage. Par exemple, le StartTime de l’activité « Issue Created » correspond à l’horodatage « created_at » de l’Issue, tandis que celui de l’activité « Merge Request Merged » correspond à l’horodatage « merged_at » de la Merge Request.

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 les performances du processus au fil du temps.

Pourquoi c’est important

Cet attribut fournit la séquence chronologique des événements, indispensable au calcul de toutes les métriques temporelles et à la compréhension du flux du processus.

Où les obtenir

Extrait de différents champs d’horodatage GitLab, tels que « created_at », « updated_at » et « closed_at » pour les Issues, ainsi que « merged_at » pour les Merge Requests.

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 pour les bogues ou les incidents.
Description

La gravité indique l’impact d’un bogue ou d’un problème, de critique à mineur. GitLab ne possède pas de champ de gravité natif. Cette information est donc presque toujours mise en œuvre au moyen d’étiquettes, par exemple « severity::1 » ou « severity::2 ».

Cet attribut est essentiel pour le Dashboard « Severity Escalation Trends » et le KPI associé. L’analyse de l’évolution de la gravité au cours du cycle de vie peut révéler des problèmes initialement sous-estimés ou des processus qui aggravent les difficultés.

Pourquoi c’est important

Il aide à hiérarchiser le travail et à déterminer si les éléments présentant une gravité élevée sont traités plus rapidement. Le suivi des changements contribue au KPI « Severity Escalation Frequency ».

Où les obtenir

Déduit des « labels » appliqués à une Issue GitLab. Une correspondance est nécessaire pour interpréter des étiquettes telles que « S1 » ou « S2 » comme des niveaux de gravité.

Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
Heure de fin
EndTime
Horodatage indiquant le moment où une activité ou un événement s’est terminé.
Description

EndTime indique la date et l’heure précises auxquelles une activité s’est terminée. Pour de nombreux événements atomiques dans GitLab, comme « Issue Created », l’EndTime est identique au StartTime. Pour les activités qui ont une durée, comme « Code Review », il correspond à l’horodatage de fin, par exemple au moment où l’approbation finale est donnée.

Cet attribut est essentiel pour calculer précisément la durée des activités individuelles, c’est-à-dire le Processing Time. Il facilite l’analyse détaillée des goulots d’étranglement en distinguant le temps consacré activement à une tâche du temps d’attente entre les tâches.

Pourquoi c’est important

Il permet de calculer précisément la durée des activités, ou temps de traitement, ce qui est essentiel pour identifier les étapes inefficaces du processus.

Où les obtenir

Pour les événements atomiques, cette valeur est identique au StartTime. Pour les activités ayant une durée, elle doit être déduite en recherchant dans les données l’événement de fin correspondant.

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 précis dans lequel le travail est effectué. Dans GitLab, chaque Issue et chaque Merge Request se trouve dans un projet.

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

Pourquoi c’est important

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

Où les obtenir

Récupéré à partir des champs « name » ou « path_with_namespace » de l’API Project, au moyen du « project_id » associé dans les Issues et les Merge Requests.

Exemples
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Responsable
Assignee
Utilisateur auquel l’Issue ou la Merge Request est attribuée au moment de l’événement.
Description

Le responsable est le développeur ou l’utilisateur chargé de l’élément de travail à un moment donné du processus. Dans GitLab, cette information est enregistrée dans le champ assignee ou assignees d’une Issue ou d’une Merge Request.

L’analyse par responsable est essentielle pour le Dashboard « Developer Workload & Allocation ». Elle permet de comprendre l’utilisation des ressources, d’identifier les personnes ou les équipes surchargées et d’analyser les transferts entre différents intervenants.

Pourquoi c’est important

Il indique qui a effectué le travail, ce qui permet d’analyser la charge, l’efficacité de l’allocation des ressources et les retards liés aux transferts.

Où les obtenir

Récupéré à partir 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 « Feature », « Bug », « Task » ou « Maintenance ».
Description

Cet attribut catégorise la nature du travail effectué. Dans GitLab, il est généralement mis en œuvre au moyen d’étiquettes appliquées à une Issue. Les équipes utilisent ces étiquettes pour distinguer les nouvelles fonctionnalités, la correction de défauts, la dette technique et les autres types de travail.

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 déterminer si les bogues sont corrigés plus rapidement que les fonctionnalités ne sont développées, ou si les tâches de dette technique suivent un processus de revue différent.

Pourquoi c’est important

La segmentation du processus par type de travail permet de déterminer si certaines catégories sont davantage exposées aux retards, aux reprises ou aux écarts.

Où les obtenir

Généralement déduit des « labels » appliqués à une Issue GitLab. Une logique de correspondance est nécessaire pour convertir certaines étiquettes en types standardisés.

Exemples
FonctionnalitéBugTâcheDette technique
Branche cible
TargetBranch
Nom de la branche de destination d’une Merge Request.
Description

La branche cible est la branche dans laquelle les modifications doivent être fusionnées, par exemple « main », « develop » ou une branche de mise en production telle que « release/1.5 ». Il s’agit d’une information essentielle pour toute Merge Request.

L’analyse par branche cible peut révéler des comportements différents selon la destination du code. Par exemple, les fusions vers « main » peuvent être soumises à un processus d’approbation plus strict et présenter des temps de cycle plus longs que les fusions vers une branche de fonctionnalité. Elle peut également aider à distinguer les déploiements en production des autres types d’intégration du code.

Pourquoi c’est important

Il aide à distinguer les différents flux de développement et de livraison, car les processus peuvent varier considérablement selon la branche de destination.

Où les obtenir

Récupéré à partir du champ « target_branch » de la réponse de l’API GitLab Merge Requests.

Exemples
principaldéveloppementrelease/v2.1.0hotfix/user-auth-bug
Délai de cycle
CycleTime
Temps total écoulé entre la première et la dernière activité d’un élément de développement.
Description

Le délai de cycle est une mesure calculée qui évalue la durée totale d’un cas. Il correspond généralement à la différence entre le tout premier événement, par exemple « Issue Created », et le tout dernier événement, par exemple « Deployed to Production », pour un même élément de développement.

Il s’agit d’un KPI essentiel pour mesurer l’efficacité globale du processus. Cette mesure est au cœur de Dashboards tels que « SDLC End-to-End Cycle Time ». Elle sert à suivre les progrès et à repérer les cas de longue durée susceptibles de révéler des problèmes systémiques.

Pourquoi c’est important

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

Où les obtenir

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

Exemples
10 jours 4 heures23 heures 15 minutes35 jours
Dernière mise à jour des données
LastDataUpdate
Horodatage indiquant le moment où les données de cet événement ont été actualisées pour la dernière fois depuis le système source.
Description

Cet attribut enregistre 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 n’indique pas le moment où l’événement s’est produit, mais celui de la dernière synchronisation de son enregistrement.

Cette information est essentielle pour comprendre l’actualité des données et vérifier la ponctualité de l’analyse du processus. Elle permet aux utilisateurs de s’assurer que les Dashboards et les KPI reposent sur des données récentes et de connaître le décalage éventuel entre le système source et l’analyse.

Pourquoi c’est important

Il apporte de la transparence sur l’actualité des données et permet aux utilisateurs de savoir dans quelle mesure l’analyse du processus est à jour.

Où les obtenir

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

Exemples
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Indicateur de 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 élément revient en développement alors que les tests ont déjà commencé. La logique de cet indicateur consiste généralement à détecter certaines séquences d’activités, comme un événement « Development Started » survenant après un événement « Pipeline Failed » ou « QA Testing Started » pour le même cas.

Cet attribut alimente directement le Dashboard « Rework & Rerun Analysis » ainsi que le KPI « Rework Rate After Testing ». Il facilite le filtrage et la quantification des reprises, afin d’aider les équipes à comprendre leur fréquence, leurs causes et leur impact sur les délais des projets.

Pourquoi c’est important

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

Où les obtenir

Calculé par l’outil de Process Mining, qui analyse la séquence des activités de chaque cas et repère les schémas révélateurs d’une reprise.

Exemples
truefalse
Nom de l’équipe
TeamName
Équipe de développement associée au projet ou au responsable.
Description

Le nom de l’équipe désigne le groupe ou la squad 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 association entre les responsables et leurs équipes au moyen d’une table de référence externe.

Cet attribut sert à analyser les performances du processus au niveau de l’équipe. Il permet de comparer l’efficacité, la charge de travail et le respect du processus entre différentes équipes, notamment dans des Dashboards tels que « Stage-Specific Bottleneck Analysis », selon une vue par équipe.

Pourquoi c’est important

Il permet d’analyser les performances et de comparer les processus entre différentes équipes, afin d’identifier les goulots d’étranglement propres à certaines équipes ou les bonnes pratiques.

Où les obtenir

Souvent déduit de l’association du nom du projet ou du responsable avec une structure d’équipe définie en dehors de GitLab, ou inféré à partir des hiérarchies de groupes GitLab.

Exemples
Frontend-AlphaBackend-ServicesPlatform-Infra
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 « Open », « In Progress » ou « Closed ».
Description

Cet attribut reflète l’état de l’élément de travail principal, généralement une Issue dans GitLab. Les Issues GitLab possèdent un champ state pouvant prendre la valeur « opened » ou « closed ». Des statuts plus détaillés sont souvent gérés au moyen d’étiquettes à portée définie, par exemple « Status::Triage » ou « Status::In-Dev ».

Le suivi des changements de statut est essentiel pour comprendre le cycle de vie du cas. Il permet de déterminer le temps passé dans chaque état et de filtrer les travaux en cours ou terminés dans des Dashboards tels que « SDLC End-to-End Cycle Time ».

Pourquoi c’est important

Il fournit un instantané de l’état du cas, permettant d’analyser le temps passé dans les différentes étapes et de distinguer les travaux en cours des travaux terminés.

Où les obtenir

Le statut principal provient du champ « state » d’une Issue GitLab (« opened », « closed »). Les statuts plus détaillés sont souvent déduits des étiquettes.

Exemples
OuvertClôturéEn coursEn revue
Statut de la Merge Request
MergeRequestStatus
Statut de la Merge Request associée à l’événement, par exemple « Opened », « Merged » ou « Closed ».
Description

Cet attribut capture l’état d’une Merge Request (MR) au moment d’un événement. Les MR GitLab possèdent plusieurs états distincts : « opened », « closed », « merged » ou « locked ». Ce statut est indépendant du statut global de l’élément de développement.

Le suivi du statut de la MR est essentiel pour analyser la phase d’intégration du code dans le SDLC. Il alimente directement des Dashboards tels que « Code Review Cycle Time & Throughput » et aide à localiser les retards entre la création, la revue, l’approbation et la fusion de la MR.

Pourquoi c’est important

Il offre une visibilité sur le processus de revue et de fusion du code, qui constitue souvent un goulot d’étranglement important du SDLC.

Où les obtenir

Récupéré à partir du champ « state » de la réponse de l’API GitLab Merge Requests.

Exemples
OuvertFusionnéClôturéVerrouillé
Statut du pipeline
PipelineStatus
Statut de l’exécution du pipeline CI/CD, par exemple « Success », « Failed » ou « Running ».
Description

Cet attribut indique le résultat de l’exécution d’un pipeline CI/CD associé à un commit ou à une Merge Request. Les statuts courants dans GitLab comprennent « running », « pending », « success », « failed », « canceled » et « skipped ».

Ces données sont essentielles pour le Dashboard « Rework & Rerun Analysis ». Les échecs fréquents de pipeline peuvent être une source importante de reprises et de retards. L’analyse de leur fréquence, de leur emplacement et de leur impact est donc essentielle pour améliorer l’efficacité du développement et la qualité du code.

Pourquoi c’est important

Il suit les réussites et les échecs des compilations et des tests automatisés, en mettant en évidence les boucles de reprise ainsi que les problèmes de qualité du code ou d’automatisation des tests.

Où les obtenir

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

Exemples
réussiéchouéen cours d’exécutionannulé
Système source
SourceSystem
Identifie le système à l’origine des données.
Description

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

Cet attribut est essentiel dans les environnements où les données de processus peuvent provenir de plusieurs systèmes, par exemple Jira pour la planification et GitLab pour l’exécution. Il permet le filtrage et la segmentation, tout en contribuant à préserver la traçabilité des données.

Pourquoi c’est important

Il garantit la clarté de l’origine des données, un élément essentiel pour la gouvernance des données et l’intégration de données provenant de plusieurs systèmes d’entreprise.

Où les obtenir

Il s’agit d’une valeur statique, « GitLab », ajoutée lors de la transformation des données.

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

Cette mesure calcule la durée de l’intervalle entre la fin d’une activité et le début de la suivante, lorsque la personne responsable change. Elle mesure par exemple 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.

Il s’agit de la mesure principale du KPI « Average Handoff Wait Time ». Elle permet de mettre au jour les inefficacités liées à l’affectation des ressources et à la communication entre équipes ou collaborateurs, en faisant ressortir les délais qui ne correspondent à aucune activité en cours.

Pourquoi c’est important

Il quantifie le temps d’inactivité lors des transferts entre différentes personnes ou équipes, révélant ainsi les retards cachés et les goulots d’étranglement liés à la communication.

Où les obtenir

Calculé par l’outil de Process Mining. Cette mesure nécessite d’analyser les événements consécutifs d’un cas, de vérifier si l’« Assignee » est différent, puis de calculer l’écart de temps.

Exemples
1 jour 2 heures15 minutes8 heures
Titre du jalon
MilestoneTitle
Titre du jalon ou du sprint auquel l’élément de développement est associé.
Description

Dans GitLab, un jalon sert à suivre le travail réalisé pour atteindre un objectif précis ou dans une période définie, par exemple un sprint ou une version de mise en production. Cet attribut contient 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 précis. Vous pouvez l’utiliser pour vérifier si les délais de cycle s’améliorent d’un sprint à l’autre ou pour filtrer la vue du processus afin d’afficher uniquement le travail associé à une prochaine mise en production.

Pourquoi c’est important

Associe le travail de développement aux cycles de planification, tels que les sprints ou les mises en production, afin d’analyser les performances par rapport aux périodes prévues.

Où les obtenir

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

Exemples
Release T4 2023Sprint 23.11Phase 1 : MVP
Version de mise en production
ReleaseVersion
Balise de version logicielle prévue ou réelle associée au déploiement.
Description

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

Il est essentiel pour le Dashboard « Release Schedule Adherence Tracking ». En comparant la date réelle de déploiement à la date prévue associée à la version, les organisations peuvent mesurer leur capacité à respecter les échéances et déterminer les causes des retards de mise en production.

Pourquoi c’est important

Associe les éléments de développement à une version logicielle précise, ce qui est essentiel pour suivre l’avancement de la mise en production et le respect du calendrier.

Où les obtenir

Cette information peut provenir de GitLab Releases, du nom d’une balise git ou du titre d’un jalon utilisé pour planifier une mise en production.

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

Activités du cycle de vie du développement logiciel

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus et identifier les goulots d’étranglement.
4 Recommandé 8 Facultatif
Activité Description
Déployé en production
Cette activité marque le déploiement réussi du code dans l’environnement de production actif, où il devient accessible aux utilisateurs finaux. Elle est enregistrée lorsqu’une tâche « deploy to production » spécifique d’un pipeline CI/CD GitLab se termine avec succès.
Pourquoi c’est 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, ainsi que la fréquence des mises en production.

Où les obtenir

L’événement est capturé à partir 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.

Collecte

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

Type d’événement explicit
Issue créée
Cette activité marque le début du cycle de vie du développement. Elle correspond à la création d’un nouvel élément de travail, tel qu’une fonctionnalité, un bogue ou une tâche. Elle est enregistrée explicitement lorsqu’un utilisateur crée une nouvelle Issue dans GitLab, qui consigne l’horodatage de création.
Pourquoi c’est 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 de l’Issue et le déploiement fournit une vision complète du temps de cycle du SDLC.

Où les obtenir

Il s’agit d’un événement explicite capturé à partir de l’horodatage « created_at » de la table « issues » ou via l’API Issues. Les notes système enregistrent également l’événement de création.

Collecte

Utilisez l’horodatage « created_at » de l’Issue.

Type d’événement explicit
Merge Request créée
Indique que le travail de développement initial est terminé et que le code est prêt pour la revue et l’intégration. Il s’agit d’un événement explicite et central du flux GitLab, enregistré lorsqu’un développeur ouvre une nouvelle merge request (MR).
Pourquoi c’est important

Il s’agit d’une étape importante, qui 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ù les obtenir

Il s’agit d’un événement explicite capturé à partir de l’horodatage « created_at » de la table « merge_requests » ou via l’API Merge Requests.

Collecte

Utilisez l’horodatage « created_at » de la Merge Request.

Type d’événement explicit
Merge Request fusionnée
Cette activité marque la fin réussie du processus de revue et d’intégration du code. Il s’agit d’un événement explicite qui se produit lorsqu’un utilisateur fusionne la branche de la Merge Request dans la branche cible.
Pourquoi c’est important

Il s’agit d’une étape majeure, qui indique que le développement et la revue sont terminés. Elle constitue le point final de la mesure du cycle de développement et le point de départ de la mesure du délai de mise en production.

Où les obtenir

Il s’agit d’un événement explicite capturé à partir de l’horodatage « merged_at » de la table « merge_requests ». Une note système est également générée lors de la fusion.

Collecte

Utilisez l’horodatage « merged_at » de la Merge Request.

Type d’événement explicit
Approbation ajoutée
Cette activité correspond à l’approbation formelle des modifications du code d’une Merge Request par un réviseur. Il s’agit d’un événement explicite capturé par GitLab lorsqu’un utilisateur clique sur le bouton « Approve ».
Pourquoi c’est important

Les approbations constituent des points de contrôle qualité essentiels. Leur suivi permet d’analyser le délai nécessaire à l’obtention des validations requises et de garantir le respect des politiques de revue.

Où les obtenir

L’événement est capturé à partir des événements d’approbation des Merge Requests. Ceux-ci sont disponibles via l’API Approvals ou consultables dans l’historique de la MR.

Collecte

Utilisez l’horodatage du journal des événements d’approbation de la Merge Request.

Type d’événement explicit
Déploiement commencé
Cette activité correspond au début du processus de mise à disposition du code dans un environnement donné, tel que la préproduction ou la production. Dans GitLab, elle correspond au démarrage d’une tâche « deploy » au sein d’un pipeline CI/CD.
Pourquoi c’est 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ù les obtenir

L’événement est capturé à partir de l’horodatage « started_at » d’une tâche CI/CD configurée comme tâche de déploiement. Cette information fait partie de la fonctionnalité Environments and Deployments de GitLab.

Collecte

Utilisez l’horodatage « started_at » du journal de la tâche CI correspondant à une tâche de déploiement.

Type d’événement explicit
Développement commencé
Cette activité marque le début du travail de programmation effectif sur l’Issue. Elle est généralement déduite du premier commit envoyé vers une branche associée à l’Issue, car GitLab ne propose pas de bouton explicite « start development ».
Pourquoi c’est important

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

Où les obtenir

L’événement est déduit de l’horodatage du premier commit effectué sur une branche de fonctionnalité liée à l’Issue. Cela nécessite d’associer les Issues aux branches, souvent au moyen de conventions de nommage ou de métadonnées.

Collecte

Trouvez l’horodatage du premier commit sur une branche associée à l’identifiant de l’Issue.

Type d’événement inferred
Issue attribuée
Cette activité correspond à l’attribution d’une Issue à un développeur ou à une équipe précise. Elle indique qu’un responsable du travail a été désigné. GitLab enregistre explicitement cet événement chaque fois que le champ « assignee » d’une Issue est renseigné ou modifié.
Pourquoi c’est important

Le suivi des attributions est essentiel pour analyser l’allocation des ressources, la charge de travail des équipes et les délais de transfert. Il permet d’identifier les retards entre la création du travail et sa prise en charge.

Où les obtenir

L’événement est capturé dans les notes système GitLab de l’Issue, qui enregistrent l’ajout ou la modification d’un « assignee ». L’horodatage de l’événement figure dans la note.

Collecte

Extrayez les événements « assignee changed » des notes système de l’Issue.

Type d’événement explicit
Issue clôturée
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 de ses modifications. Il s’agit d’un événement explicite capturé lorsqu’un utilisateur clôture l’Issue dans GitLab.
Pourquoi c’est important

La clôture d’une Issue marque souvent la fin de l’ensemble du travail associé. La comparaison avec le moment du déploiement peut révéler des retards liés à la validation après déploiement ou aux processus administratifs.

Où les obtenir

Il s’agit d’un événement explicite capturé à partir de l’horodatage « closed_at » de la table « issues » ou de la note système correspondante.

Collecte

Utilisez l’horodatage « closed_at » de l’Issue.

Type d’événement explicit
Pipeline démarré
Cette activité 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 par un commit ou la création d’une MR.
Pourquoi c’est 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ù les obtenir

L’événement est capturé à partir de l’horodatage « created_at » ou « started_at » d’un enregistrement de pipeline dans la table « ci_pipelines » ou via l’API Pipelines.

Collecte

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

Type d’événement explicit
Pipeline en échec
Cette activité se produit lorsqu’une exécution de pipeline CI/CD échoue à une étape quelconque, par exemple en raison d’une erreur de compilation ou d’un test non concluant. GitLab enregistre explicitement le statut final de chaque pipeline, ce qui facilite l’identification des échecs.
Pourquoi c’est 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 d’identifier les problèmes de qualité, les tests instables et les goulots d’étranglement dans la boucle de retour vers les développeurs.

Où les obtenir

L’événement est identifié par le statut « failed » d’un enregistrement de pipeline dans la table « ci_pipelines ». L’horodatage « finished_at » indique le moment de l’échec.

Collecte

Filtrez les enregistrements de pipeline dont le statut est « failed » et utilisez l’horodatage « finished_at ».

Type d’événement explicit
Revue du code commencée
Cette activité marque le début de la revue par les pairs d’une Merge Request. Elle est déduite de la première action liée à la revue, comme le premier commentaire ou fil de discussion publié par une personne autre que l’auteur.
Pourquoi c’est important

La mesure du délai entre la création de la MR et le début de la revue met en évidence les temps d’attente dans la file. La réduction de ce délai est essentielle pour raccourcir le cycle global de revue du code.

Où les obtenir

L’événement est déduit de l’horodatage du premier commentaire ou fil de revue sur la Merge Request qui n’a pas été publié par son auteur. Ces données sont disponibles via les notes système ou l’API Notes.

Collecte

Trouvez l’horodatage du premier commentaire d’un utilisateur autre que l’auteur sur une MR.

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 vie du développement logiciel. Commencez dès aujourd’hui à transformer votre processus !

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

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

Démarrer l’essai gratuit

Aucune carte bancaire requise, commencez immédiatement votre optimisation.