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 | Description | ||
|---|---|---|---|
|
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'. | ||
|
Description
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 timestamp à 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 fondamental pour construire la carte des processus, visualiser le workflow et analyser la séquence et la fréquence des événements. Il est utilisé pour identifier les déviations, les goulots d'étranglement entre les étapes et les chemins de processus courants.
Pourquoi c'est important
Il définit les étapes de la carte des processus, permettant la visualisation et l'analyse du workflow de développement de bout en bout.
Où obtenir
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 démarréMerge Request fusionnéePipeline échouéDé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 cas principal. | ||
|
Description
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 de bout en bout, l'identification des goulots d'étranglement 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 c'est important
C'est l'identifiant de cas essentiel qui relie tous les événements du processus, permettant de tracer le cycle de vie complet de tout élément de travail donné.
Où obtenir
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. | ||
|
Description
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 timestamp. Par exemple, le StartTime de l'activité 'Anomalie Créée' serait le timestamp Ce timestamp 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 c'est important
Cet attribut fournit la séquence chronologique des événements, ce qui est essentiel pour calculer toutes les métriques basées sur le temps et comprendre le flux de processus.
Où obtenir
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. | ||
|
Description
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 essentiel pour le dashboard '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 c'est 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é'.
Où obtenir
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 'timestamp' indiquant quand une activité ou un 'event' a été complété. | ||
|
Description
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éé', l'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 essentiel pour calculer avec précision la durée des activités individuelles (temps de traitement). Il aide à l'analyse détaillée des bottlenecks en distinguant le temps passé à travailler activement sur une tâche et le temps d'attente entre les tâches.
Pourquoi c'est important
Permet le calcul de durées d'activité précises (temps de traitement), ce qui est essentiel pour identifier les étapes inefficaces du processus.
Où obtenir
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. | ||
|
Description
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 c'est important
Permet de segmenter l'analyse des processus par produit, application ou composant, facilitant ainsi les efforts d'amélioration ciblés.
Où obtenir
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. | ||
|
Description
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 cruciale pour le dashboard '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 c'est 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.
Où obtenir
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'. | ||
|
Description
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 c'est important
Segmenter le processus par type de travail aide à identifier si certains types de travail sont plus sujets aux retards, au retravail ou aux déviations.
Où obtenir
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
FonctionnalitéBugTâcheDette Technique
|
|||
|
Branche cible
TargetBranch
|
Le nom de la branche de destination pour une merge request. | ||
|
Description
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 c'est 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.
Où obtenir
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. | ||
|
Description
Cet attribut enregistre 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 est vitale pour comprendre la fraîcheur 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 c'est important
Offre une transparence sur la fraîcheur des données, garantissant que les utilisateurs sont conscients de l'actualité de l'analyse des processus.
Où obtenir
Ce timestamp 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 retravail
IsRework
|
Un indicateur booléen indiquant si une activité fait partie d'une boucle de retravail. | ||
|
Description
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 dashboard 'Analyse du retravail et des réexécutions' et le KPI 'Taux de retravail après test'. Il permet un filtrage et une quantification aisés du retravail, aidant les équipes à comprendre sa fréquence, ses causes et son impact sur les délais des projets.
Pourquoi c'est 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é.
Où obtenir
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é. | ||
|
Description
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 c'est important
Permet l'analyse des performances et la comparaison des processus entre différentes équipes, aidant à identifier les bottlenecks ou les meilleures pratiques spécifiques à chaque équipe.
Où obtenir
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é'. | ||
|
Description
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 crucial 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 c'est 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é.
Où obtenir
Le statut principal provient du champ 'state' d'une Issue GitLab ('opened', 'closed'). Les statuts plus granulaires 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'. | ||
|
Description
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 crucial 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 c'est 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.
Où obtenir
Récupéré du champ 'state' dans la réponse de l'API GitLab Merge Requests.
Exemples
openedmergedfermélocked
|
|||
|
Statut du Pipeline
PipelineStatus
|
Le statut de l'exécution du pipeline CI/CD, tel que 'Succès', 'Échoué' ou 'En cours'. | ||
|
Description
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 essentielles pour le dashboard 'Analyse du retravail et des réexécutions'. Les échecs fréquents de pipeline peuvent être une source significative de retravail et de retard, et l'analyse de leur fréquence, de leur emplacement et de leur impact est essentielle pour améliorer l'efficacité du développement et la qualité du code.
Pourquoi c'est 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.
Où obtenir
Récupéré du champ 'status' dans la réponse de l'API GitLab CI/CD Pipelines.
Exemples
successéchouérunningannulé
|
|||
|
Système source
SourceSystem
|
Identifie le système d'où proviennent les données. | ||
|
Description
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 crucial 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 lignée des données.
Pourquoi c'est important
Assure la clarté sur l'origine des données, ce qui est essentiel pour la gouvernance des données et lors de l'intégration des données provenant de multiples systèmes d'entreprise.
Où obtenir
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. | ||
|
Description
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 à découvrir les inefficacités cachées 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 c'est important
Quantifie le temps d'inactivité lors des transferts entre différentes personnes ou équipes, révélant les retards cachés et les goulots d'étranglement de communication.
Où obtenir
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. | ||
|
Description
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 c'est important
C'est un KPI central du process mining qui mesure l'efficacité de bout en bout du cycle de vie du développement.
Où obtenir
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
|
|||
|
Temps de traitement
ProcessingTime
|
La durée d'une seule activité, calculée comme la différence entre son heure de fin et son heure de début. | ||
|
Description
Le temps de traitement mesure le temps de travail actif pour une activité spécifique, distinct du temps d'attente entre les activités. Il est calculé comme EndTime moins StartTime pour un seul enregistrement d'événement. Pour les événements instantanés, le temps de traitement est nul. Cette métrique est cruciale pour l'analyse des goulots d'étranglement spécifiques à une étape. En agrégeant les temps de traitement des activités au sein d'une étape, telle que la revue de code, les analystes peuvent déterminer exactement combien de temps est consacré à l'exécution active du travail, aidant à identifier les étapes de processus inefficaces.
Pourquoi c'est important
Mesure la durée des activités individuelles, aidant à distinguer le temps de travail actif du temps d'attente inactif pour une analyse précise des goulots d'étranglement.
Où obtenir
Calculé par l'outil de Process Mining comme la différence entre l'EndTime et le StartTime d'une activité.
Exemples
2 heures 30 minutes0 minutes3 jours 8 heures
|
|||
|
Titre du jalon
MilestoneTitle
|
Le titre du jalon ou du sprint auquel l'élément de développement est assigné. | ||
|
Description
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 c'est 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.
Où obtenir
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. | ||
|
Description
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 essentiel pour le dashboard '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 c'est important
Connecte les éléments de développement à une livraison logicielle spécifique, ce qui est crucial pour suivre la progression de la livraison et le respect du calendrier.
Où obtenir
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é | Description | ||
|---|---|---|---|
|
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 c'est important
C'est l'événement de fin primaire du processus, signifiant que de la valeur a été livrée. Il est essentiel pour mesurer le temps de cycle total de bout en bout du SDLC et la fréquence de livraison.
Où obtenir
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 c'est 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.
Où obtenir
C'est un événement explicite capturé à partir du timestamp '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 c'est 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.
Où obtenir
C'est un événement explicite capturé à partir du timestamp '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 le timestamp de création. | ||
|
Pourquoi c'est important
C'est l'événement de démarrage primaire pour le processus de bout en bout. 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.
Où obtenir
C'est un événement explicite capturé à partir du timestamp '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 c'est 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.
Où obtenir
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 c'est important
Le suivi du début du déploiement aide à isoler la durée de la phase de déploiement. Il est crucial pour mesurer et optimiser le délai de déploiement.
Où obtenir
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 démarré
|
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 c'est 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.
Où obtenir
Inférez en trouvant le timestamp 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 le timestamp 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 timestamp de démarrage 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 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.
Où obtenir
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é
|
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 c'est important
Les échecs de pipeline sont un moteur principal du retravail. L'analyse de leur fréquence, durée et cause aide à identifier les problèmes de qualité, les tests instables et les goulots d'étranglement dans la boucle de rétroaction vers les développeurs.
Où obtenir
Identifié par un statut 'failed' sur un enregistrement de pipeline dans la table 'ci_pipelines'. Le timestamp 'finished_at' indique quand l'échec s'est produit.
Capture
Filtrez les enregistrements de pipeline ayant un statut 'failed' et utilisez le timestamp '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 c'est important
Le suivi des assignations est crucial 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.
Où obtenir
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 c'est 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.
Où obtenir
C'est un événement explicite capturé à partir du timestamp '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 c'est 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 essentiel pour raccourcir le cycle global de revue de code.
Où obtenir
Inférez à partir du timestamp 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 le timestamp du premier commentaire utilisateur sur une MR provenant d'un non-auteur.
Type d'événement
inferred
|
|||