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
- Attributs recommandés à recueillir
- Activités clés à suivre
- Conseils d’extraction
Attributs du cycle de développement logiciel
| 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
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
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 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
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 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
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
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 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
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 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
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
|
|||
Activités du cycle de développement logiciel
| 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
Données à recueillir
Utilisez l’horodatage
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
Données à recueillir
Utilisez l’horodatage
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
Données à recueillir
Utilisez l’horodatage
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
Données à recueillir
Utilisez l’horodatage
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
Données à recueillir
Utilisez l’horodatage
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
Données à recueillir
Filtrez les enregistrements de pipeline dont le statut est
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
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
Données à recueillir
Utilisez l’horodatage
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
|
|||
Guides d’extraction
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é.
Aucune carte bancaire requise. Commencez à optimiser dès maintenant.