Votre modèle de données pour le cycle de vie du développement logiciel
Votre modèle de données pour le cycle de vie du développement logiciel
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction
Attributs du Cycle de vie du développement logiciel
| Nom | Descriptionn | ||
|---|---|---|---|
|
Activité
Activity
|
Le nom de l'étape de processus ou de l'événement spécifique qui s'est produit, tel que 'Anomalie Créée' ou 'Merge Request Fusionnée'. | ||
|
Descriptionn
L'attribut Activité capture les événements distincts qui se produisent sur un Élément de Développement. Ceux-ci ne sont pas stockés comme un champ unique dans GitLab, mais sont dérivés de diverses actions et champs de horodatage à travers les Issues, Merge Requests et Pipelines CI/CD. Par exemple, la création d'une anomalie, un commit poussé, un échec de pipeline ou l'approbation d'une merge request sont toutes des activités distinctes. Cet attribut est indispensable pour construire la cartographie des processus, visualiser le workflow et analyser la séquence et la fréquence des événements. Il est utilisé pour identifier les écarts, les points de blocage entre les étapes et les chemins de processus courants.
Pourquoi est-ce important ? :
Il définit les étapes de la cartographie des processus, pour visualiser et l'analyse du workflow de développement complet.
Source des données :
Dérivé des types d'événements et des changements d'état dans le flux d'événements de GitLab, ou en interprétant des champs d'horodatage comme 'created_at', 'merged_at' et 'closed_at' sur les problèmes (Issues) et les demandes de fusion.
Exemples
Problème crééDéveloppement commencéMerge Request fusionnéePipeline échouéeDéployé en production
|
|||
|
Élément de développement
DevelopmentItem
|
L'identifiant unique d'une unité de travail, telle qu'une fonctionnalité, une correction de bug ou une tâche, servant d'identifiant de dossier principal. | ||
|
Descriptionn
L'Élément de Développement représente une seule pièce de travail traçable circulant à travers le cycle de vie du développement logiciel. Il connecte toutes les activités connexes, de la création au déploiement final, en un cas cohérent. Dans GitLab, cela est généralement représenté par l'ID interne (IID) de l'Issue, qui est unique au sein d'un projet. L'analyse par Élément de Développement permet la mesure du temps de cycle complet, l'identification des points de blocage et la vérification de la conformité des processus. Elle constitue la base pour comprendre l'efficacité avec laquelle le travail est livré du concept à la production.
Pourquoi est-ce important ? :
C'est l'identifiant de cas clé qui relie tous les événements du processus, permettant de tracer le cycle de vie complet de tout élément de travail donné.
Source des données :
C'est généralement l'ID interne (IID) d'une Issue GitLab. Il peut être trouvé dans la réponse de l'API Issues sous le champ 'iid'.
Exemples
1024512PRJ-2345
|
|||
|
Heure de début
StartTime
|
L'horodatage indiquant le début d'une activité ou d'un événement. | ||
|
Descriptionn
StartTime marque la date et l'heure précises auxquelles une activité spécifique s'est produite. Pour les événements dans GitLab, cela est capturé dans divers champs de horodatage. Par exemple, le StartTime de l'activité 'Anomalie Créée' serait l'horodatage Ce horodatage est l'élément temporel central du process mining. Il est utilisé pour ordonner les événements chronologiquement, calculer les durées entre les activités, mesurer les temps de cycle et analyser les performances des processus au fil du temps.
Pourquoi est-ce important ? :
Cet attribut fournit la séquence chronologique des événements, ce qui est indispensable pour calculer toutes les métriques temporelles et comprendre le flux de processus.
Source des données :
Extrait de divers champs d'horodatage dans GitLab, tels que 'created_at', 'updated_at', 'closed_at' sur les problèmes (issues), et 'merged_at' sur les demandes de fusion.
Exemples
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Gravité
Severity
|
Le niveau de sévérité de l'élément de développement, généralement pour les bugs ou les incidents. | ||
|
Descriptionn
La sévérité indique l'impact d'un bug ou d'une anomalie, allant de critique à mineur. GitLab ne dispose pas de champ de sévérité natif, cela est donc presque toujours implémenté à l'aide d'étiquettes (par exemple, 'severity::1', 'severity::2'). Cet attribut est indispensable pour le tableau de bord 'Tendances d'escalade de la sévérité' et le KPI associé. L'analyse des changements de sévérité tout au long du cycle de vie peut mettre en évidence des anomalies initialement sous-estimées ou des processus qui exacerbent les problèmes.
Pourquoi est-ce important ? :
Aide à prioriser le travail et à analyser si les éléments de haute sévérité sont traités plus rapidement. Le suivi des changements soutient l'indicateur clé de performance (KPI) 'Fréquence d'escalade de la sévérité'.
Source des données :
Dérivé des 'labels' appliqués à un problème (Issue) GitLab. Un mappage est nécessaire pour interpréter les étiquettes comme 'S1', 'S2' comme des niveaux de gravité.
Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
|
|||
|
Heure de fin
EndTime
|
Le 'horodatage' indiquant quand une activité ou un 'event' a été terminé. | ||
|
Descriptionn
EndTime marque la date et l'heure précises de fin d'une activité. Pour de nombreux événements atomiques dans GitLab, comme 'Problème créé', le champ EndTime est identique au StartTime. Pour les activités ayant une durée, comme 'Revue de code', il représente l'horodatage d'achèvement, par exemple, lorsque l'approbation finale est donnée. Cet attribut est indispensable pour calculer avec précision la durée des activités individuelles (temps de traitement). Il aide à l'analyse détaillée des points de blocage en distinguant le temps passé à travailler activement sur une tâche et le temps d'attente entre les tâches.
Pourquoi est-ce important ? :
Permet le calcul de durées d'activité précises (temps de traitement), ce qui est indispensable pour identifier les étapes inefficaces du processus.
Source des données :
Pour les événements atomiques, c'est identique à StartTime. Pour les activités de durée, il doit être dérivé en trouvant 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
|
Le nom du projet GitLab auquel l'élément de développement appartient. | ||
|
Descriptionn
Cet attribut identifie le référentiel de code ou le projet spécifique où le travail est effectué. Dans GitLab, chaque anomalie et merge request est contenue dans un projet. L'analyse par Nom de Projet permet des comparaisons de performance entre différents produits, composants ou services. Elle peut aider à identifier si certains projets ont des processus SDLC plus sains que d'autres et est utile pour filtrer les dashboards vers un domaine d'intérêt spécifique.
Pourquoi est-ce important ? :
Permet de segmenter l'analyse des processus par produit, application ou composant, facilitant ainsi les efforts d'amélioration ciblés.
Source des données :
Récupéré des champs 'name' ou 'path_with_namespace' dans l'API Project, liés via le 'project_id' dans Issues et Merge Requests.
Exemples
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Responsable assigné
Assignee
|
L'utilisateur assigné à l'anomalie ou à la merge request au moment de l'événement. | ||
|
Descriptionn
L'Assigné est le développeur ou l'utilisateur individuel responsable de l'élément de travail à un moment donné du processus. Dans GitLab, cela est capturé dans le champ L'analyse par Assigné est indispensablele pour le tableau de bord 'Charge de travail et allocation des développeurs'. Elle aide à comprendre l'utilisation des ressources, à identifier les individus ou équipes surchargés et à analyser les transferts entre différentes personnes.
Pourquoi est-ce important ? :
Suit les responsables des tâches, facilitant l'analyse de la charge de travail, l'efficacité de l'allocation des ressources et l'identification des retards dus aux passations.
Source des données :
Récupéré des champs 'assignee.username' ou 'assignees' dans les réponses de l'API GitLab Issues et Merge Requests.
Exemples
jdoeasmithr.williams
|
|||
|
Type d'élément de développement
DevelopmentItemType
|
La classification de l'élément de développement, telle que 'Fonctionnalité', 'Bug', 'Tâche' ou 'Maintenance'. | ||
|
Descriptionn
Cet attribut catégorise la nature du travail effectué. Dans GitLab, cela est généralement implémenté à l'aide d'étiquettes sur une anomalie. Les équipes utilisent des étiquettes pour distinguer entre les nouvelles fonctionnalités, la résolution de défauts, la dette technique et d'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 pour différents types de travail. Par exemple, on peut analyser si les bugs sont résolus plus rapidement que les fonctionnalités sont développées, ou si les tâches de dette technique suivent un processus de revue différent.
Pourquoi est-ce important ? :
Segmenter le processus par type de travail aide à identifier si certains types de travail sont plus sujets aux retards, au reprises ou aux écarts.
Source des données :
Généralement dérivé des 'labels' appliqués à une Issue GitLab. Une logique de mappage est nécessaire pour traduire des labels spécifiques en types standardisés.
Exemples
FeatureBugTâcheDette technique
|
|||
|
Branche cible
TargetBranch
|
Le nom de la branche de destination pour une merge request. | ||
|
Descriptionn
La Branche Cible est la branche dans laquelle les changements sont destinés à être fusionnés, par exemple, 'main', 'develop', ou une branche de livraison comme 'release/1.5'. C'est une information essentielle pour toute Merge Request. L'analyse par Branche Cible peut révéler différents comportements de processus pour le code fusionné dans différentes destinations. Par exemple, les fusions vers 'main' peuvent avoir un processus d'approbation plus rigoureux et des temps de cycle plus longs que les fusions vers une branche de fonctionnalité. Cela peut également aider à distinguer les déploiements en production d'autres types d'intégration de code.
Pourquoi est-ce important ? :
Aide à différencier les divers workflows de développement et de livraison, car les processus peuvent varier considérablement en fonction de la branche de destination.
Source des données :
Récupéré du champ 'target_branch' dans 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
|
L'horodatage indiquant la dernière actualisation des données de cet événement à partir du système source. | ||
|
Descriptionn
Cet attribut consigne la date et l'heure de la dernière extraction ou mise à jour des données d'événement dans le dataset de process mining. Il ne représente pas le moment où l'événement s'est produit, mais plutôt le moment où l'enregistrement de l'événement a été synchronisé pour la dernière fois. Cette information permet de mieux comprendre la la réactualisation des données et valider la pertinence de l'analyse des processus. Elle aide les utilisateurs à faire confiance au fait que les dashboards et les KPI sont basés sur des données récentes et les informe du décalage potentiel entre le système source et l'analyse.
Pourquoi est-ce important ? :
Offre une transparence sur la la réactualisation des données, garantissant que les utilisateurs sont conscients de l'actualité de l'analyse des processus.
Source des données :
Ce horodatage est généré et enregistré par l'outil d'extraction de données ou le processus ETL au moment d'une actualisation des données.
Exemples
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Est un reprises
IsRework
|
Un indicateur booléen indiquant si une activité fait partie d'une boucle de reprises. | ||
|
Descriptionn
Cet attribut calculé signale les activités qui représentent un pas en arrière dans le processus, comme le retour au développement après que les tests aient déjà commencé. La logique de ce flag implique généralement la détection de séquences spécifiques d'activités, par exemple, un événement 'Développement Démarré' se produisant après un événement 'Pipeline Échoué' ou 'Tests QA Démarrés' pour le même cas. Cet attribut alimente directement le tableau de bord 'Analyse du reprises et des réexécutions' et le KPI 'Taux de reprises après test'. Il permet un filtrage et une quantification aisés du reprises, aidant les équipes à comprendre sa fréquence, ses causes et son impact sur les délais des projets.
Pourquoi est-ce important ? :
Signale et quantifie directement les retouches, facilitant l'analyse des causes et de l'impact des inefficacités de processus et des problèmes de qualité.
Source des données :
Calculé par l'outil de Process Mining en analysant la séquence d'activités pour chaque cas et en identifiant les modèles qui indiquent des retouches.
Exemples
truefaux
|
|||
|
Nom de l'équipe
TeamName
|
L'équipe de développement associée au projet ou à l'assigné. | ||
|
Descriptionn
Le Nom de l'Équipe représente le groupe ou la squad responsable de l'élément de développement. Cette information n'est généralement pas un champ standard dans GitLab et est souvent dérivée des conventions de nommage de projet, des structures de groupe, ou en mappant les assignés à leurs équipes respectives à l'aide d'une table de référence externe. Cet attribut est utilisé pour analyser la performance des processus au niveau de l'équipe. Il aide à comparer l'efficacité, la charge de travail et le respect des processus entre différentes équipes, supportant des dashboards comme l'« Analyse des Goulots d'Étranglement Spécifiques à une Étape » d'un point de vue basé sur l'équipe.
Pourquoi est-ce important ? :
Permet l'analyse des performances et la comparaison des processus entre différentes équipes, aidant à identifier les points de blocage ou les meilleures pratiques spécifiques à chaque équipe.
Source des données :
Souvent dérivé en mappant le Nom du Projet ou l'Assigné à une structure d'équipe définie en dehors de GitLab, ou inféré à partir des hiérarchies de groupes GitLab.
Exemples
Frontend-AlphaServices BackendPlatform-Infra
|
|||
|
Statut de l'élément de développement
DevelopmentItemStatus
|
Le statut de l'élément de développement au moment de l'événement, tel que 'Ouvert', 'En cours' ou 'Fermé'. | ||
|
Descriptionn
Cet attribut reflète l'état de l'élément de travail principal, généralement une Issue dans GitLab. Les Issues GitLab ont un Le suivi des changements de statut est impératif pour comprendre le cycle de vie du cas. Il aide à identifier combien de temps les éléments passent dans chaque état et peut être utilisé pour filtrer le travail actif ou terminé dans des dashboards comme 'Temps de Cycle de Bout en Bout du SDLC'.
Pourquoi est-ce important ? :
Fournit un instantané de l'état du cas, permettant l'analyse du temps passé dans diverses étapes et le filtrage entre le travail en cours et le travail terminé.
Source des données :
Le statut principal provient du champ 'state' d'une Issue GitLab ('opened', 'closed'). Les statuts plus granulairesres sont souvent dérivés d'étiquettes.
Exemples
openedferméEn coursEn cours d'examen
|
|||
|
Statut de la Merge Request
MergeRequestStatus
|
Le statut de la merge request associée à l'événement, tel que 'Ouverte', 'Fusionnée' ou 'Fermée'. | ||
|
Descriptionn
Cet attribut capture l'état d'une Merge Request (MR) au moment d'un événement. Les MR GitLab ont des états distincts : 'opened', 'closed', 'merged' ou 'locked'. Ceci est distinct du Statut global de l'Élément de Développement. Le suivi du statut de la MR est impératif pour analyser la phase d'intégration de code du SDLC. Il supporte directement les dashboards comme 'Temps de cycle et débit de la revue de code' et aide à identifier les retards entre la création, la revue, l'approbation et la fusion des MR.
Pourquoi est-ce important ? :
Offre une visibilité sur le processus de revue de code et de fusion, qui est souvent un goulot d'étranglement critique dans le SDLC.
Source des données :
Récupéré du champ 'state' dans la réponse de l'API GitLab Merge Requests.
Exemples
openedfusionnéfermélocked
|
|||
|
Statut du Pipeline
PipelineStatus
|
Le statut de l'exécution du pipeline CI/CD, tel que 'Succès', 'Échoué' ou 'En cours'. | ||
|
Descriptionn
Cet attribut indique le résultat d'une exécution de pipeline CI/CD associée à un commit ou une merge request. Les statuts courants dans GitLab incluent 'running', 'pending', 'success', 'failed', 'canceled' et 'skipped'. Ces données sont indispensables pour le tableau de bord 'Analyse du reprises et des réexécutions'. Les échecs fréquents de pipeline peuvent être une source significative de reprises et de retard, et l'analyse de leur fréquence, de leur emplacement et de leur impact est indispensablele pour améliorer l'efficacité du développement et la qualité du code.
Pourquoi est-ce important ? :
Suit les succès et les échecs des builds et tests automatisés, mettant en lumière les cycles de retouche et les problèmes de qualité du code ou d'automatisation des tests.
Source des données :
Récupéré du champ 'status' dans la réponse de l'API GitLab CI/CD Pipelines.
Exemples
succèséchouérunningannulé
|
|||
|
Système source
SourceSystem
|
Identifie le système d'où proviennent les données. | ||
|
Descriptionn
Cet attribut spécifie l'origine des données de processus. Pour ce modèle de données, la valeur sera constamment 'GitLab'. Inclure cet attribut est impératif dans les environnements où les données de processus peuvent être combinées à partir de plusieurs systèmes, tels que Jira pour la planification et GitLab pour l'exécution. Il permet le filtrage, la segmentation et aide à maintenir la traçabilité des données.
Pourquoi est-ce important ? :
Assure la clarté sur l'origine des données, ce qui est indispensable pour la gouvernance des données et lors de l'intégration des données provenant de multiples systèmes d'entreprise.
Source des données :
C'est une valeur statique, 'GitLab', ajoutée lors du processus de transformation des données.
Exemples
GitLab
|
|||
|
Temps d'Attente de Transfert
HandoffWaitTime
|
Temps d'inactivité calculé entre deux activités consécutives effectuées par des assignés différents. | ||
|
Descriptionn
Cette métrique calcule la durée de l'intervalle entre la fin d'une activité et le début de la suivante, spécifiquement lorsque l'assigné change. Par exemple, elle mesure le temps entre le moment où un développeur termine son travail et le moment où un relecteur commence la revue de code. C'est la métrique clé pour le KPI 'Temps d'attente moyen de transfert'. Elle aide à identifier les points de blocage dans l'allocation des ressources et la communication entre les équipes ou les individus, mettant en évidence les retards qui ne font pas partie d'un travail actif.
Pourquoi est-ce important ? :
Quantifie le temps d'inactivité lors des transferts entre différentes personnes ou équipes, révélant les retards cachés et les points de blocage de communication.
Source des données :
Calculé par l'outil de Process Mining. Cela nécessite d'analyser les événements consécutifs au sein d'un cas, de vérifier si l''Assignee' est différent, puis de calculer la différence de temps.
Exemples
1 jour 2 heures15 minutes8 heures
|
|||
|
Temps de cycle
CycleTime
|
Le temps total écoulé de la première à la dernière activité pour un élément de développement. | ||
|
Descriptionn
Le Cycle Time est une métrique calculée qui mesure la durée totale d'un cas. Il est généralement calculé comme la différence de temps entre le tout premier événement (par exemple, 'Problème créé') et le tout dernier événement (par exemple, 'Déployé en production') pour un seul Development Item. C'est un KPI principal pour mesurer l'efficacité globale des processus. C'est la métrique clé dans les dashboards comme 'SDLC End-to-End Cycle Time' et est utilisée pour suivre les améliorations et identifier les cas de longue durée qui peuvent indiquer des problèmes systémiques.
Pourquoi est-ce important ? :
C'est un KPI central du process mining qui mesure l'efficacité complet du cycle de vie du développement.
Source des données :
Calculé par l'outil de Process Mining en soustrayant le StartTime minimum du StartTime maximum pour chaque CaseId unique.
Exemples
10 jours 4 heures23 heures 15 minutes35 jours
|
|||
|
Titre du jalon
MilestoneTitle
|
Le titre du jalon ou du sprint auquel l'élément de développement est assigné. | ||
|
Descriptionn
Un Milestone dans GitLab est utilisé pour suivre le travail par rapport à un objectif ou une période spécifique, comme un sprint ou une version de release. Cet attribut capture le nom ou le titre de ce jalon. Cet attribut permet d'analyser la performance des processus dans le contexte de sprints ou de périodes de planification spécifiques. Il peut être utilisé pour voir si les temps de cycle s'améliorent d'un sprint à l'autre ou pour filtrer la vue du processus afin de n'afficher que le travail lié à une release à venir.
Pourquoi est-ce important ? :
Lie le travail de développement aux cycles de planification comme les sprints ou les livraisons, permettant l'analyse des performances par rapport aux timeboxes prévus.
Source des données :
Récupéré du champ 'milestone.title' dans les réponses de l'API GitLab Issues ou Merge Requests.
Exemples
Livraison T4-2023Sprint 23.11Phase 1 : MVP
|
|||
|
Version de livraison
ReleaseVersion
|
Le tag de version logicielle planifiée ou réelle associé au déploiement. | ||
|
Descriptionn
Cet attribut identifie la livraison logicielle spécifique dont fait partie un élément de développement. Dans GitLab, cela peut être associé via un Jalon, un tag protégé ou une entrée dans la fonctionnalité Releases. Ceci est indispensable pour le tableau de bord 'Suivi de l'adhérence au calendrier de livraison'. En comparant la date de déploiement réelle à une date planifiée associée à la version de livraison, les organisations peuvent mesurer leur capacité à respecter les calendriers et à diagnostiquer les causes des retards de livraison.
Pourquoi est-ce important ? :
Connecte les éléments de développement à une livraison logicielle spécifique, ce qui est impératif pour suivre la progression de la livraison et le respect du calendrier.
Source des données :
Cela peut être tiré des Releases GitLab, du nom d'un tag git, ou du titre d'un jalon utilisé pour la planification de la livraison.
Exemples
v1.2.0v3.0.0-beta2023.4.1
|
|||
Activités du Cycle de vie du développement logiciel
| Activité | Descriptionn | ||
|---|---|---|---|
|
Déployé en production
|
Cette activité marque le déploiement réussi du code dans l'environnement de production en direct, le rendant disponible aux utilisateurs finaux. Ceci est capturé lorsqu'un job spécifique de 'déploiement en production' dans un pipeline CI/CD GitLab se termine avec succès. | ||
|
Pourquoi est-ce important ? :
C'est l'événement de fin primaire du processus, signifiant que de la valeur a été livrée. Il est indispensable pour mesurer le temps de cycle total complet du SDLC et la fréquence de livraison.
Source des données :
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 suit cela explicitement.
Capture
Utilisez l'horodatage 'finished_at' du job CI de déploiement en production réussi.
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 dans le workflow GitLab, capturé lorsqu'un développeur ouvre une nouvelle merge request (MR). | ||
|
Pourquoi est-ce important ? :
C'est un jalon critique qui marque le transfert du développement à la revue et aux tests. C'est le point d'entrée pour analyser l'ensemble du cycle de revue de code et de pipeline CI/CD.
Source des données :
C'est un événement explicite capturé à partir du horodatage 'created_at' dans la table 'merge_requests' ou via l'API Merge Requests.
Capture
Utilisez l'horodatage 'created_at' de la merge request.
Type d'événement
explicit
|
|||
|
Merge Request fusionnée
|
Cette activité signifie l'achèvement réussi du processus de revue de code et d'intégration. C'est un événement explicite qui se produit lorsqu'un utilisateur fusionne la branche de la merge request dans la branche cible. | ||
|
Pourquoi est-ce important ? :
C'est un jalon majeur indiquant que le développement et la revue sont terminés. Il sert de point final pour mesurer le temps de cycle de développement et de point de départ pour mesurer le délai de déploiement.
Source des données :
C'est un événement explicite capturé à partir du horodatage 'merged_at' dans la table 'merge_requests'. Une note système est également générée lors de la fusion.
Capture
Utilisez l'horodatage 'merged_at' de la merge request.
Type d'événement
explicit
|
|||
|
Problème créé
|
Cette activité marque le début du cycle de vie du développement, représentant la création d'un nouvel élément de travail, tel qu'une fonctionnalité, un bug ou une tâche. Elle est capturée explicitement lorsqu'un utilisateur crée une nouvelle anomalie dans GitLab, ce qui enregistre l'horodatage de création. | ||
|
Pourquoi est-ce important ? :
C'est l'événement de démarrage primaire pour le processus complet. L'analyse du temps entre la création de l'anomalie et le déploiement fournit une image complète du temps de cycle du SDLC.
Source des données :
C'est un événement explicite capturé à partir du horodatage 'created_at' dans la table 'issues' ou via l'API Issues. Les notes système enregistrent également l'événement de création.
Capture
Utilisez l'horodatage 'created_at' de l'issue.
Type d'événement
explicit
|
|||
|
Approbation ajoutée
|
Représente une approbation formelle des changements de code dans une merge request par un relecteur. Il s'agit d'un événement explicite capturé par GitLab lorsqu'un utilisateur clique sur le bouton 'Approuver'. | ||
|
Pourquoi est-ce important ? :
Les approbations sont des quality gates clés. Leur suivi aide à analyser le temps nécessaire pour obtenir les validations requises et assure la Conformité avec les politiques de révision.
Source des données :
Capturé à partir des événements d'approbation de demande de fusion. Ceux-ci sont disponibles via l'API des approbations ou peuvent être vus dans l'historique de la MR.
Capture
Utilisez l'horodatage du journal d'événements d'approbation de la merge request.
Type d'événement
explicit
|
|||
|
Déploiement démarré
|
Représente le début du processus de livraison de code vers un environnement spécifique, tel que la pré-production ou la production. Dans GitLab, cela correspond au début d'un job de 'déploiement' au sein d'un pipeline CI/CD. | ||
|
Pourquoi est-ce important ? :
Le suivi du début du déploiement aide à isoler la durée de la phase de déploiement. Il est impératif pour mesurer et optimiser le délai de déploiement.
Source des données :
Capturé à partir de l'horodatage 'started_at' d'une tâche CI/CD configurée comme tâche de déploiement. Cela fait partie de la fonctionnalité Environments and Deployments de GitLab.
Capture
Utilisez l'horodatage 'started_at' du log du job CI pour une tâche de déploiement.
Type d'événement
explicit
|
|||
|
Développement commencé
|
Cette activité signifie le début du travail de codage actif sur l'anomalie. Cela est généralement inféré à partir du premier commit de code poussé vers une branche associée à l'anomalie, car GitLab ne dispose pas de bouton explicite 'démarrer le développement'. | ||
|
Pourquoi est-ce important ? :
Identifie le début exact du travail de développement à valeur ajoutée, permettant une mesure précise de la phase de codage pur et la séparant du temps de planification ou d'attente.
Source des données :
Inférez en trouvant l'horodatage du premier commit sur une branche de fonctionnalité liée à l'anomalie. Cela nécessite de lier les anomalies aux branches, souvent via des conventions de nommage ou des métadonnées.
Capture
Trouvez l'horodatage du premier commit sur une branche associée à l'ID de l'anomalie.
Type d'événement
inferred
|
|||
|
Pipeline démarré
|
Représente l'initiation d'un pipeline CI/CD automatisé, qui exécute généralement des builds, des tests et des scans de sécurité. GitLab crée explicitement un enregistrement de pipeline avec un horodatage de démarrage chaque fois qu'un pipeline est déclenché, par exemple par un commit ou la création d'une MR. | ||
|
Pourquoi est-ce important ? :
Le suivi des exécutions de pipeline est indispensable pour surveiller la santé et l'efficacité des processus de test et d'intégration automatisés. Il aide à identifier le temps passé en validation automatisée.
Source des données :
Capturé à partir de l'horodatage 'created_at' ou 'started_at' d'un enregistrement de pipeline dans la table 'ci_pipelines' ou via l'API des Pipelines.
Capture
Utilisez l'horodatage de l'enregistrement d'exécution du pipeline associé à la branche de la MR.
Type d'événement
explicit
|
|||
|
Pipeline échouée
|
Cette activité se produit lorsqu'une exécution de pipeline CI/CD échoue à n'importe quelle étape, comme une erreur de build ou un test échoué. GitLab enregistre explicitement le statut final de chaque pipeline, ce qui facilite l'identification des échecs. | ||
|
Pourquoi est-ce important ? :
Les échecs de pipeline sont un moteur principal du reprises. L'analyse de leur fréquence, durée et cause aide à identifier les problèmes de qualité, les tests instables et les points de blocage dans la boucle de rétroaction vers les développeurs.
Source des données :
Identifié par un statut 'failed' sur un enregistrement de pipeline dans la table 'ci_pipelines'. L'horodatage 'finished_at' indique quand l'échec s'est produit.
Capture
Filtrez les enregistrements de pipeline ayant un statut 'failed' et utilisez l'horodatage 'finished_at'.
Type d'événement
explicit
|
|||
|
Problème attribué
|
Représente l'attribution d'une anomalie à un développeur ou une équipe spécifique, indiquant que la responsabilité du travail a été établie. Il s'agit d'un événement explicite enregistré par GitLab chaque fois que le champ d'assignation d'une anomalie est renseigné ou modifié. | ||
|
Pourquoi est-ce important ? :
Le suivi des assignations est impératif pour analyser l'allocation des ressources, la charge de travail de l'équipe et les temps de transfert. Il aide à identifier les retards entre le moment où le travail est créé et le moment où il est pris en charge.
Source des données :
Capturé à partir des notes système de GitLab pour le problème (issue), qui enregistrent quand un 'assignee' est ajouté ou modifié. L'horodatage de l'événement est enregistré dans la note.
Capture
Extrayez les événements de 'changement d'assigné' des notes système du problème (issue).
Type d'événement
explicit
|
|||
|
Problème clos
|
Représente la clôture administrative finale de l'élément de travail, généralement après que ses changements ont été déployés et vérifiés. Il s'agit d'un événement explicite capturé lorsqu'un utilisateur ferme l'anomalie dans GitLab. | ||
|
Pourquoi est-ce important ? :
La clôture d'un problème (issue) signifie souvent la fin de tout le travail associé. La comparaison avec le temps de déploiement peut révéler des retards dans la validation post-déploiement ou les processus administratifs.
Source des données :
C'est un événement explicite capturé à partir du horodatage 'closed_at' dans la table 'issues' ou de la note système correspondante.
Capture
Utilisez l'horodatage 'closed_at' de l'issue.
Type d'événement
explicit
|
|||
|
Revue de code démarrée
|
Marque le début du processus de revue par les pairs pour une merge request. Cet événement est inféré à partir de la première action liée à la revue, comme le premier commentaire ou fil de discussion posté par une personne autre que l'auteur. | ||
|
Pourquoi est-ce important ? :
Mesurer le temps entre la création d'une MR et le début de la revue met en évidence les retards d'attente. Réduire ce temps d'attente est indispensable pour raccourcir le cycle global de revue de code.
Source des données :
Inférez à partir du horodatage du premier commentaire ou fil de discussion de revue sur la merge request qui ne provient pas de l'auteur de la MR. Ces données sont disponibles via les notes système ou l'API Notes.
Capture
Trouvez l'horodatage du premier commentaire utilisateur sur une MR provenant d'un non-auteur.
Type d'événement
inferred
|
|||