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é
ActivityName
|
Le nom d'un événement ou d'une tâche spécifique survenu au cours du cycle de vie du développement logiciel. | ||
|
Description
Le nom de l'activité décrit une étape unique du processus de développement, telle que « Tâche créée », « Code poussé vers PR », « Demande de tirage approuvée » ou « Déploiement réussi ». Ces événements constituent la séquence d'étapes qui forment le processus de bout en bout pour un élément de développement. Cet attribut est fondamental pour le Process Mining car il est utilisé pour construire la carte de processus. L'analyse de la séquence, de la fréquence et de la durée de ces activités révèle le flux de processus réel, identifie les chemins communs, met en évidence les déviations et localise les goulots d'étranglement.
Pourquoi c'est important
Cet attribut constitue la colonne vertébrale de la carte de processus, permettant la visualisation et l'analyse de la séquence des événements dans le cycle de vie du développement.
Où obtenir
Dérivé du champ 'action' des charges utiles d'événements de webhook (par exemple, 'opened', 'closed' pour un problème) ou du type d'événement lui-même (par exemple, 'PushEvent', 'PullRequestReviewEvent').
Exemples
Problème crééDemande de tirage ouverteCode `pushé` vers la PRRevue demandéeDemande de tirage fusionnée
|
|||
|
Élément de développement
DevelopmentItemId
|
L'identifiant unique pour une unité de travail de développement, telle qu'une fonctionnalité, une correction de bogue ou une tâche. Il sert d'identifiant principal du cas (case). | ||
|
Description
L'ID de l'élément de développement suit un élément de travail de sa création à son déploiement final. Il relie toutes les activités associées, telles que la création de branche, les commits, les demandes de tirage (pull requests), les revues et les déploiements, en une seule instance de processus cohérente. En analyse, cet ID est utilisé pour calculer le temps de cycle de bout en bout d'une tâche de développement. Il permet de reconstituer le parcours complet d'une fonctionnalité ou d'une correction de bogue, autorisant une analyse détaillée des goulots d'étranglement, des boucles de retouches et des variations de processus pour les éléments de travail individuels.
Pourquoi c'est important
C'est la clé essentielle du process mining, reliant tous les événements de développement associés en un seul cas pour visualiser et analyser avec précision le cycle de vie complet du développement logiciel.
Où obtenir
Il s'agit généralement du numéro de la tâche (Issue Number) ou du numéro de la demande de tirage (Pull Request Number) de GitHub. Il peut être extrait du champ 'number' dans la charge utile des événements webhook liés aux tâches ou aux demandes de tirage, ou des réponses de l'API.
Exemples
101PR-2345TASK-812
|
|||
|
Heure de début
EventTimestamp
|
La date et l'heure exactes auxquelles une activité ou un événement de développement spécifique s'est produit. | ||
|
Description
Cet horodatage marque le début d'une activité. Il est crucial pour ordonner les événements chronologiquement afin de reconstituer le flux de processus pour chaque élément de développement. La séquence et la différence de temps entre ces horodatages sont utilisées pour analyser les performances du processus. En analyse, cet attribut est essentiel pour calculer toutes les métriques basées sur le temps, y compris les temps de cycle, les temps de traitement et les temps d'attente. Il permet d'identifier les retards entre les étapes et fournit les données nécessaires à l'analyse des goulots d'étranglement et aux tableaux de bord de suivi des performances.
Pourquoi c'est important
Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les métriques de performance, telles que les temps de cycle et les durées des goulots d'étranglement.
Où obtenir
Généralement trouvés comme champs 'created_at' ou 'updated_at' dans les charges utiles JSON des API GitHub et des webhooks pour divers objets comme les tâches (issues), les demandes de tirage (pull requests) et les commits.
Exemples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Dépôt
RepositoryName
|
Le nom du dépôt de code où l'activité de développement a lieu. | ||
|
Description
Le dépôt agit comme un identifiant de projet ou de produit, contenant tout le code, les tâches (issues) et les demandes de tirage (pull requests) pour une application ou un composant spécifique. Il offre un moyen de segmenter et de comparer les processus de développement entre différents produits ou équipes. En analyse, cet attribut permet de filtrer et de comparer les performances des processus entre différents projets. Il aide à répondre à des questions comme « Quel projet a le temps de cycle le plus long ? » ou « Comment le processus de correction de bogue dans le Projet A se compare-t-il au Projet B ? ». Il est essentiel pour le tableau de bord « Débit par projet et par type ».
Pourquoi c'est important
Permet la segmentation et la comparaison des processus de développement entre différents projets, produits ou équipes, rendant possible une analyse plus ciblée.
Où obtenir
Disponible dans l'objet 'repository' dans presque toutes les charges utiles de webhook et d'API GitHub. Le champ spécifique est généralement 'repository.full_name' ou 'repository.name'.
Exemples
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Heure de fin
EndTimestamp
|
La date et l'heure exactes auxquelles une activité ou un événement de développement spécifique a été achevé. | ||
|
Description
L'horodatage de fin marque l'achèvement d'une activité. Bien que de nombreux événements dans GitHub soient instantanés (par exemple, « Tâche créée »), certaines activités ont une durée mesurable (par exemple, l'exécution d'une vérification CI). La différence entre l'heure de fin et l'heure de début donne le temps de traitement d'une activité. Cet attribut est utilisé pour calculer la métrique « ProcessingTime », essentielle pour comprendre l'effort actif consacré à différentes tâches comme les revues de code ou les vérifications automatisées. L'analyse des temps de traitement aide à identifier les activités inefficaces qui consomment trop de temps.
Pourquoi c'est important
Permet le calcul de temps de traitement précis pour les activités, aidant à distinguer le temps de travail actif du temps d'attente inactif.
Où obtenir
Peut être trouvé comme 'completed_at' dans les objets d'exécution de vérification ou dérivé de l'horodatage d'un événement ultérieur et concluant logiquement.
Exemples
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Priorité
Priority
|
Le niveau de priorité attribué à un élément de développement, tel que 'Élevé', 'Moyen' ou 'Faible'. | ||
|
Description
La priorité indique l'urgence ou l'importance commerciale d'un élément de travail. Dans GitHub, la priorité n'est pas un champ natif et est généralement gérée à l'aide d'étiquettes (par exemple, 'P1-High', 'P2-Medium'). Un schéma d'étiquetage cohérent est nécessaire pour extraire cette information de manière fiable. Cet attribut est essentiel pour l'« Analyse des flux basée sur la priorité ». Il permet aux analystes de vérifier si les éléments de haute priorité sont réellement traités plus rapidement que ceux de basse priorité et de mesurer la variance du temps de cycle en fonction de la priorité. Il aide à évaluer l'efficacité du processus de priorisation.
Pourquoi c'est important
Permet d'analyser si les éléments à haute priorité sont traités plus rapidement que ceux à faible priorité, validant ainsi l'efficacité de la stratégie de priorisation.
Où obtenir
Dérivé des étiquettes GitHub appliquées aux problèmes ou aux
Exemples
ÉlevéMoyenFaibleCritique
|
|||
|
Type d'élément de développement
DevelopmentItemType
|
La classification de l'élément de travail de développement, tel qu'une fonctionnalité, un bogue, une tâche ou une épopée. | ||
|
Description
Cet attribut catégorise la nature du travail effectué. Cette information est généralement gérée via des étiquettes ou des modèles de tâches (issues) spécifiques au sein de GitHub. Comprendre le type de travail est crucial pour définir des attentes de performance appropriées, car une correction de bogue pourrait avoir un temps de cycle attendu beaucoup plus court qu'une nouvelle fonctionnalité. Cet attribut permet une analyse comparative entre différents types de travail. Il aide à analyser si les corrections de bogues sont traitées plus rapidement que les nouvelles fonctionnalités, ou à comprendre l'allocation des ressources pour la dette technique par rapport au nouveau développement. C'est une dimension clé dans le tableau de bord « Débit par projet et par type ».
Pourquoi c'est important
Catégorise les éléments de travail, permettant des comparaisons de performance et l'analyse de la façon dont différents types de travail (par exemple,
Où obtenir
Généralement dérivé des étiquettes GitHub appliquées aux tâches (issues) ou aux demandes de tirage (pull requests). Nécessite une convention d'étiquetage cohérente (par exemple, 'type:bug', 'type:feature').
Exemples
BugFonctionnalitéTâcheDette technique
|
|||
|
Utilisateur assigné
Assignee
|
L'utilisateur ou le développeur assigné pour gérer l'élément de développement ou une tâche spécifique, comme une revue de demande de tirage. | ||
|
Description
Cet attribut identifie l'individu responsable du travail à une étape donnée. Il peut s'agir du responsable (assignee) d'une tâche (issue), de l'auteur d'une demande de tirage (pull request) ou du réviseur sollicité pour une revue de code. Le suivi du responsable est essentiel pour comprendre l'allocation des ressources et la charge de travail. Cet attribut est utilisé en analyse pour surveiller la charge de travail des développeurs, identifier les goulots d'étranglement des ressources et analyser l'efficacité des transferts entre les différents membres de l'équipe. Les tableaux de bord peuvent être filtrés par responsable pour évaluer la performance individuelle ou d'équipe et assurer une répartition équilibrée du travail.
Pourquoi c'est important
Crucial pour analyser la charge de travail des développeurs, la performance de l'équipe et l'efficacité des transferts entre les différents membres de l'équipe.
Où obtenir
Disponible dans l'objet 'assignee' ou 'user' au sein des charges utiles JSON pour les problèmes, les
Exemples
john.doejane.smithdev-team-lead
|
|||
|
Auteur
Author
|
L'utilisateur qui a créé la tâche (issue), la demande de tirage (pull request) ou le commit. | ||
|
Description
L'auteur est l'initiateur d'un artefact spécifique dans le processus de développement. Par exemple, l'auteur d'une tâche (issue) est la personne qui a signalé le bogue ou demandé la fonctionnalité. L'auteur d'une demande de tirage (pull request) est le développeur qui a écrit le code. En analyse, l'auteur peut être utilisé pour comprendre les sources de travail. Par exemple, l'analyse des auteurs de rapports de bogues peut révéler des schémas liés à des équipes ou des fonctionnalités spécifiques. Il peut également être utilisé en conjonction avec le responsable (assignee) pour analyser les modèles de transfert.
Pourquoi c'est important
Identifie l'auteur d'un élément de travail ou d'une modification de code, ce qui peut être utile pour analyser les sources de reprise, les rapports de
Où obtenir
Disponible dans l'objet 'user' au sein de l'objet principal des réponses API pour les problèmes, les
Exemples
sara.jonesmike.leeautomation-bot
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Le timestamp indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
|
Description
Cet attribut enregistre la date et l'heure de la dernière extraction ou mise à jour des données. Il fournit des métadonnées sur la fraîcheur des données analysées. Ceci est distinct de l'horodatage de l'événement, qui enregistre le moment où l'événement métier s'est produit. En analyse, ce champ est crucial pour comprendre la pertinence de la vue du processus. Il aide les utilisateurs à savoir s'ils consultent des données en temps réel ou un instantané d'un moment précis, ce qui est important pour les tableaux de bord opérationnels et le suivi.
Pourquoi c'est important
Indique la fraîcheur des données, ce qui est essentiel pour garantir que les analyses et les dashboards sont basés sur des informations à jour.
Où obtenir
Ce
Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Environnement de déploiement
DeploymentEnvironment
|
L'environnement cible pour un déploiement, tel que 'Staging' ou 'Production'. | ||
|
Description
Cet attribut spécifie l'endroit où le code est déployé. Le suivi des déploiements vers différents environnements est essentiel pour comprendre le cycle de vie complet, du développement à la publication en production. Cet attribut permet d'analyser le sous-processus de déploiement. Il peut être utilisé pour mesurer le temps nécessaire pour promouvoir le code de l'environnement de staging à la production et pour suivre le taux de succès des déploiements vers différents environnements. Il est essentiel pour savoir quand un élément de développement est réellement 'terminé' et livré aux utilisateurs.
Pourquoi c'est important
Distingue les livraisons de pré-production et de production, ce qui est critique pour mesurer le véritable 'délai de mise sur le marché' et analyser les modèles de déploiement.
Où obtenir
Ces informations sont récupérées via l'API GitHub Deployments, souvent déclenchée par des pipelines CI/CD ou d'autres automatisations.
Exemples
développementstagingproduction
|
|||
|
Est un retravail
IsRework
|
Un indicateur booléen qui est vrai si une activité représente une régression vers une étape précédente du processus. | ||
|
Description
Cet indicateur est défini à vrai lorsque un élément de développement recule dans le processus, par exemple lorsqu'une demande de tirage (pull request) reçoit une revue « Modifications demandées », ou lorsqu'une tâche (issue) est rouverte après avoir été fermée. Il est dérivé par l'analyse de la séquence des activités. Cet attribut est essentiel pour quantifier le gaspillage et l'inefficacité. Il soutient directement le tableau de bord « Boucles de retouches et de régression » et le KPI « Taux de retouches ». En filtrant sur 'IsRework = true', les analystes peuvent isoler et investiguer les causes des retouches.
Pourquoi c'est important
Signale explicitement les activités qui constituent des reprises, facilitant la quantification, la visualisation et l'analyse des causes des inefficacités de processus.
Où obtenir
Ceci est un attribut dérivé. La logique implique de définir un flux de processus standard, puis de signaler toute activité qui s'en écarte en revenant à une étape logique antérieure.
Exemples
truefaux
|
|||
|
État de l'élément
State
|
Le statut actuel d'une tâche (issue) ou d'une demande de tirage (pull request), tel que 'open', 'closed' ou 'merged'. | ||
|
Description
Cet attribut indique le statut de haut niveau d'un élément de développement. Pour les tâches (issues), les états typiques sont 'open' (ouvert) et 'closed' (fermé). Pour les demandes de tirage (pull requests), les états incluent 'open', 'closed' et 'merged' (fusionné). Cela fournit un aperçu de la progression de l'élément. En analyse, l'état est utilisé pour identifier le travail actif par rapport au travail terminé. Il est essentiel pour les tableaux de bord comme « Progression du développement actif » qui suivent le travail en cours. Il est également utilisé pour définir la fin d'un processus, par exemple, un état 'merged' ou 'closed' pourrait signifier l'achèvement d'un cas (case).
Pourquoi c'est important
Fournit une indication claire de l'état d'avancement ou d'achèvement d'un élément de travail, ce qui est fondamental pour l'analyse du cycle de vie et le suivi du travail actif.
Où obtenir
Directement disponible en tant que champ 'state' dans les charges utiles JSON pour les problèmes et les
Exemples
openferméfusionné
|
|||
|
État de révision
ReviewState
|
Le résultat d'une revue de code sur une demande de tirage (pull request), tel que 'Approved' (approuvé) ou 'Changes Requested' (modifications demandées). | ||
|
Description
Cet attribut capture la décision prise par un réviseur. Les états courants incluent « APPROVED » (approuvé), indiquant que le code est prêt à être fusionné, et « CHANGES_REQUESTED » (modifications demandées), indiquant qu'un retravail est nécessaire. D'autres états peuvent inclure « COMMENTED » ou « PENDING ». Ceci est un attribut critique pour l'analyse des retouches et de la qualité. Une fréquence élevée d'événements « CHANGES_REQUESTED » peut indiquer des problèmes de qualité de code initiale ou des exigences peu claires. Il soutient directement le tableau de bord « Boucles de retouches et de régression » en identifiant le moment où un élément de développement est renvoyé pour modification.
Pourquoi c'est important
Indique directement les boucles de reprise et les jalons qualité au sein du processus de révision de code, aidant à identifier les sources d'inefficacité et les problèmes de qualité.
Où obtenir
Disponible en tant que champ 'state' au sein d'un objet de révision de
Exemples
APPROUVÉCHANGES_REQUESTEDCOMMENTED
|
|||
|
Étiquettes
Labels
|
Une liste d'étiquettes ou de `tags` appliqués à un `issue` ou une `pull request` pour la catégorisation. | ||
|
Description
Les étiquettes dans GitHub sont un moyen flexible d'ajouter des métadonnées aux problèmes et aux Bien que des attributs spécifiques comme la priorité et le type soient dérivés des étiquettes, conserver la liste complète peut être utile pour l'analyse ad-hoc et la découverte d'autres modèles de processus. Cela permet un filtrage et une segmentation flexibles des cas basés sur toute combinaison d'étiquettes.
Pourquoi c'est important
Fournit une source de métadonnées riche et flexible pour la catégorisation des éléments de travail, permettant une analyse dimensionnelle approfondie et variée.
Où obtenir
Disponible sous forme de tableau 'labels' dans la charge utile JSON pour les problèmes et les
Exemples
bug, ui, high-priorityfeature, backend, needs-docsdette technique, refactorisation
|
|||
|
Hachage de Commit
CommitHash
|
L'identifiant unique (SHA) d'un commit de code spécifique. | ||
|
Description
Un Bien que très granulaire, le
Pourquoi c'est important
Fournit le lien le plus granulaire entre une étape de processus et le changement de code exact, permettant une traçabilité complète pour les audits et le débogage.
Où obtenir
Disponible dans les charges utiles d'événements de
Exemples
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Nom de la branche
BranchName
|
Le nom de la branche Git où les modifications de code pour l'élément de développement ont été effectuées. | ||
|
Description
Une branche est une ligne de développement indépendante, créée pour travailler sur une nouvelle fonctionnalité ou un correctif de bug sans affecter la base de code principale. Le nom de la branche contient souvent des informations utiles, telles que le numéro de problème ou une courte description du travail. L'analyse des noms de branches peut aider à comprendre les stratégies de branchement et le respect des conventions de développement. Elle aide également à relier des
Pourquoi c'est important
Fournit un contexte sur la ligne de développement spécifique et aide à appliquer et à analyser les stratégies de branchement et les conventions de nommage.
Où obtenir
Disponible dans le champ 'ref' pour les événements de
Exemples
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Numéro de demande de tirage
PullRequestNumber
|
L'identifiant unique d'une demande de tirage (pull request) associée à l'élément de développement. | ||
|
Description
Une Cet identifiant est crucial pour le suivi du sous-processus d'intégration et de révision du code au sein du cycle de vie de développement plus large. Il permet une analyse détaillée du processus de révision de code, y compris les temps de révision, les cycles de reprise identifiés pendant la révision, et les taux de fusion. Il connecte la phase de planification (
Pourquoi c'est important
Lie les problèmes aux modifications de code spécifiques et aux processus de révision, permettant une analyse détaillée du cycle de révision de code et de son impact sur le délai de livraison global.
Où obtenir
Disponible en tant que champ 'number' au sein de l'objet 'pull_request' dans de nombreuses réponses de l'API GitHub, ou en tant qu'identifiant principal de l'API Pull Requests.
Exemples
12345678910
|
|||
|
Réviseur
Reviewer
|
L'utilisateur sollicité pour effectuer une revue de code sur une demande de tirage (pull request). | ||
|
Description
Un relecteur est un développeur ou un membre de l'équipe désigné pour inspecter les modifications de code dans une Cet attribut est essentiel pour analyser le processus de révision de code. Il aide à identifier les goulots d'étranglement liés à des relecteurs spécifiques, à comprendre la répartition de la charge de travail de révision et à mesurer le temps nécessaire aux relecteurs pour répondre aux demandes. C'est un composant clé pour le calcul de l'ICP 'Temps de cycle moyen de révision de code'.
Pourquoi c'est important
Identifie les individus impliqués dans le processus d'assurance qualité, permettant l'analyse des charges de travail de révision, des retards et de l'efficacité globale des révisions de code.
Où obtenir
Disponible dans le tableau 'requested_reviewers' ou l'objet 'user' d'un événement de révision de
Exemples
alex.chenmaria.garciaéquipe-développement-senior
|
|||
|
Statut des vérifications CI
CiCheckStatus
|
Le statut d'une vérification d'intégration continue (CI) automatisée, tel que 'passed' (réussi) ou 'failed' (échoué). | ||
|
Description
Cet attribut reflète le résultat des builds, tests et scans automatisés exécutés sur les modifications de code dans une demande de tirage (pull request). Les vérifications CI sont une porte de qualité critique dans les workflows de développement modernes. L'analyse de cet attribut aide à comprendre l'efficacité des tests automatisés. Un taux d'échec élevé peut indiquer des problèmes de stabilité du code, de la suite de tests ou de l'environnement de développement. Il prend en charge les activités « Vérifications CI réussies » et « Vérifications CI échouées » et aide à analyser les retards causés par des builds défectueuses.
Pourquoi c'est important
Indique le succès ou l'échec des jalons qualité automatisés, offrant un aperçu de la qualité du code et de l'efficacité du pipeline CI.
Où obtenir
Obtenu à partir du champ 'state' ou 'conclusion' des objets d'exécution de vérification ou de statut via les API GitHub Checks ou Statuses.
Exemples
succèsfailurependingerror
|
|||
|
Système source
SourceSystem
|
Le système à partir duquel les données du processus de développement ont été extraites. | ||
|
Description
Cet attribut identifie l'origine des données d'événement. Pour ce processus, la valeur serait systématiquement 'GitHub'. Dans un environnement plus complexe où les activités de développement s'étendent sur plusieurs systèmes (par exemple, Jira pour la planification, GitHub pour le code, Jenkins pour le déploiement), ce champ est utilisé pour distinguer la source de chaque événement. En analyse, il aide à retracer les données jusqu'à leur origine pour la validation et le dépannage. Il permet également d'analyser les processus qui traversent différentes plateformes, fournissant un contexte clair pour chaque activité.
Pourquoi c'est important
Identifie l'origine des données, ce qui est essentiel pour la validation des données et pour l'analyse des processus qui peuvent s'étendre sur plusieurs systèmes intégrés.
Où obtenir
Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement (ETL) des données pour étiqueter la source des enregistrements.
Exemples
GitHubGitHub Enterprise
|
|||
|
Temps d'attente de transfert
HandoffWaitingTime
|
Le temps d'inactivité calculé qu'un élément de développement passe à attendre entre des activités réalisées par différentes personnes. | ||
|
Description
Cette métrique mesure le temps entre la fin d'une activité et le début de la suivante, mais uniquement lorsque la personne responsable change. Par exemple, le temps entre un événement 'Review Requested' et un événement 'Changes Requested in Review' par un utilisateur différent. C'est une métrique critique pour identifier les lacunes de communication et les problèmes de coordination. Elle soutient le tableau de bord 'Efficacité critique du transfert' et le KPI 'Temps d'attente moyen des transferts'. Des temps d'attente élevés aux points de transfert sont souvent un signe de contraintes de ressources ou de processus de notification inefficaces.
Pourquoi c'est important
Identifie les retards causés par une mauvaise coordination ou l'indisponibilité des ressources lors des transferts entre différentes équipes ou rôles, souvent sources majeures d'inefficacité.
Où obtenir
Calculé en identifiant les activités séquentielles où l'attribut 'Assignee' ou 'User' change, puis en mesurant l'intervalle de temps entre elles.
Exemples
PT1H15MP2DT4HPT25M
|
|||
|
Temps de cycle de développement
DevelopmentCycleTime
|
Le temps total écoulé entre la création d'un élément de développement et son déploiement ou sa clôture finale. | ||
|
Description
Ceci est une métrique au niveau du cas (case), calculée comme la différence de temps entre le tout premier événement (par exemple, « Tâche créée ») et l'événement final (par exemple, « Déploiement réussi » ou « Tâche fermée ») pour un seul élément de développement. C'est l'un des KPI les plus importants pour mesurer l'efficacité globale du processus de développement. Il soutient directement le tableau de bord « Temps de cycle de développement global » et le KPI « Temps de cycle de développement moyen ». Réduire cette métrique est souvent un objectif principal des initiatives d'amélioration des processus.
Pourquoi c'est important
Représente le 'time-to-market' de bout en bout pour un élément de développement, en faisant un KPI critique pour mesurer la vélocité et l'efficacité globale du processus.
Où obtenir
Calculé au niveau du cas en soustrayant l'horodatage de la première activité de l'horodatage de la dernière activité.
Exemples
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Temps de traitement
ProcessingTime
|
La durée calculée d'une activité, représentant le temps de travail actif. | ||
|
Description
Le Temps de Traitement est le temps écoulé entre le début et la fin d'une activité. Il est calculé comme 'EndTimestamp' moins 'EventTimestamp'. Cette métrique mesure le temps nécessaire pour accomplir une tâche, en excluant tout temps d'attente avant le début de la tâche. L'analyse du temps de traitement aide à identifier les activités les plus chronophages en termes d'effort actif. Cela diffère du temps de cycle, qui inclut le temps d'attente. Par exemple, une revue de code peut avoir un long temps de cycle mais un court temps de traitement, indiquant que le réviseur est occupé et que la demande de tirage (PR) est en attente.
Pourquoi c'est important
Mesure la durée de travail active, aidant à distinguer le temps passé à travailler sur une tâche du temps passé à l'attendre, ce qui est essentiel pour des améliorations ciblées de l'efficacité.
Où obtenir
Calculé en soustrayant le 'EventTimestamp' du 'EndTimestamp' pour un seul enregistrement d'activité.
Exemples
PT5M15SPT2H30MP1DT12H
|
|||
Activités du cycle de vie du développement logiciel
| Activité | Description | ||
|---|---|---|---|
|
Demande de tirage approuvée
|
Un relecteur a formellement approuvé les modifications d'une `pull request`, indiquant qu'elles respectent les normes de qualité et fonctionnelles. Ceci est capturé lorsqu'un relecteur soumet sa révision avec le statut 'approuvé'. | ||
|
Pourquoi c'est important
C'est une étape clé de qualité et un jalon majeur avant la fusion. Le temps nécessaire pour atteindre cet état depuis la création de la PR est un KPI critique pour l'efficacité du processus de revue.
Où obtenir
Capturé à partir de l'API GitHub Pull Request ou des webhooks lorsqu'une révision est soumise avec l'état 'APPROVED'.
Capture
Filtrer les événements de soumission de révision de
Type d'événement
explicit
|
|||
|
Demande de tirage fusionnée
|
Les modifications de code approuvées de la demande de tirage (pull request) sont officiellement intégrées dans la branche cible, telle que main ou develop. Il s'agit d'une action explicite et finale sur une demande de tirage qui incorpore le nouveau code. | ||
|
Pourquoi c'est important
Il s'agit d'une étape critique représentant l'achèvement du développement et de la revue. Pour de nombreuses équipes, c'est la dernière étape avant le déploiement automatisé.
Où obtenir
Capturé à partir du flux d'événements de l'API GitHub Pull Request ou des webhooks. L'action de l'événement est 'closed' et l'attribut 'merged' de la charge utile de la
Capture
Surveiller l'action 'closed' d'une demande de tirage (pull request) et vérifier si l'indicateur 'merged' est vrai.
Type d'événement
explicit
|
|||
|
Demande de tirage ouverte
|
Signale qu'un bloc de code initial est prêt pour la revue et l'intégration. Un développeur crée une demande de tirage (PR) pour proposer des modifications de sa branche de fonctionnalité vers une branche principale. Il s'agit d'un événement explicite dans GitHub. | ||
|
Pourquoi c'est important
Il s'agit d'une étape cruciale qui marque la fin de la phase de développement initiale et le début du pipeline de revue et d'intégration. Elle est essentielle pour analyser séparément les temps de cycle de développement et de revue.
Où obtenir
Capturé à partir du flux d'événements de l'API GitHub Pull Request ou des webhooks. L'action de l'événement est 'opened'.
Capture
Écouter l'action 'opened' pour une demande de tirage (pull request) via des webhooks ou l'interrogation de l'API.
Type d'événement
explicit
|
|||
|
Problème clos
|
L'élément de développement est considéré comme terminé, et la tâche (issue) correspondante est formellement fermée. Cela peut se produire automatiquement lorsqu'une demande de tirage (pull request) liée est fusionnée ou être effectué manuellement par un membre de l'équipe. | ||
|
Pourquoi c'est important
Cette activité sert de fin définitive au processus pour un élément de développement. Elle est cruciale pour le calcul des temps de cycle de bout en bout.
Où obtenir
Il s'agit d'un événement explicite capturé à partir du flux d'événements de l'API GitHub Issues. Le type d'événement est 'closed'.
Capture
Écouter l'événement 'closed' sur une tâche (issue) via des webhooks ou l'interrogation de l'API.
Type d'événement
explicit
|
|||
|
Problème créé
|
Marque le début du cycle de vie d'un élément de développement, représentant la création formelle d'une tâche, d'un bogue ou d'une demande de fonctionnalité. Cet événement est explicitement capturé lorsqu'un utilisateur crée une nouvelle tâche (issue) dans un dépôt GitHub. | ||
|
Pourquoi c'est important
C'est l'activité de démarrage principale du processus, essentielle pour mesurer le temps de cycle de développement total et comprendre les sources initiales de travail.
Où obtenir
Il s'agit d'un événement explicite capturé à partir du flux d'événements de l'API GitHub Issues. Le type d'événement est généralement 'opened' pour un numéro de tâche (issue) donné.
Capture
Écouter l'événement 'opened' sur une tâche (issue) via des webhooks ou l'interrogation de l'API.
Type d'événement
explicit
|
|||
|
Vérifications CI réussies
|
Représente la réussite des vérifications automatisées, telles que les builds, les tests unitaires ou l'analyse statique, exécutées sur le code d'une demande de tirage (pull request). Cet événement est déduit du statut des vérifications signalées par des systèmes comme GitHub Actions. | ||
|
Pourquoi c'est important
Cette porte de qualité automatisée est cruciale pour assurer la stabilité du code. Les échecs ou les longs temps d'exécution peuvent constituer des goulots d'étranglement significatifs dans le pipeline de livraison.
Où obtenir
Déduit de l'API GitHub Checks ou de l'API Statuses. Une exécution de vérification ou une mise à jour de statut signale un 'success' ou 'completed' avec une conclusion de 'success'.
Capture
Surveiller l'API Checks pour une conclusion 'success' sur les suites de vérification pertinentes.
Type d'événement
inferred
|
|||
|
Branche créée
|
Représente le début du travail de développement actif pour une tâche (issue), où un développeur crée une nouvelle branche à partir du code principal. Il s'agit d'un événement explicite capturé lorsqu'une nouvelle branche est poussée vers le dépôt, contenant souvent le numéro de la tâche dans son nom. | ||
|
Pourquoi c'est important
Indique la transition de la planification au codage actif. Mesurer le temps entre la création du problème et cet événement aide à analyser le temps de prise en charge par le développeur et les retards initiaux du
Où obtenir
Capturé via l'API Git de GitHub ou les webhooks à l'écoute des événements 'create' de type 'branch'. Il est souvent nécessaire de lier le nom de la branche à un problème via des conventions de nommage, comme 'feature/issue-123'.
Capture
Analyser les événements webhook 'create' pour les nouvelles branches et les associer à une tâche.
Type d'événement
explicit
|
|||
|
Code `pushé` vers la PR
|
Représente une mise à jour du code soumis pour revue, soit dans le cadre de la PR initiale, soit en réponse aux retours de revue. Cet événement est capturé chaque fois qu'un nouveau commit est poussé vers la branche associée à une demande de tirage (pull request) ouverte. | ||
|
Pourquoi c'est important
Le suivi de ces événements est crucial pour identifier les boucles de retravail. Des poussées multiples après une revue indiquent que des modifications étaient nécessaires, affectant le temps de cycle global.
Où obtenir
Il s'agit d'un événement explicite dans la chronologie de la demande de tirage (pull request), souvent étiqueté comme un commit ajouté. Il peut être capturé à partir du webhook 'push' ou en surveillant les commits associés à une PR.
Capture
Suivre les événements 'push' sur une branche associée à une demande de tirage (pull request) ouverte.
Type d'événement
explicit
|
|||
|
Déploiement réussi
|
Les modifications de code ont été déployées avec succès vers un environnement spécifique, tel que staging ou production. Cet événement est généralement capturé via l'API GitHub Deployments, souvent déclenché par une GitHub Action après une fusion. | ||
|
Pourquoi c'est important
Marque la transition du code du dépôt vers un environnement de production. Le suivi de cette étape est essentiel pour mesurer le délai de bout en bout, de l'idée à la production.
Où obtenir
Capturé via l'API Deployments. Un service externe ou une action GitHub crée un déploiement puis met à jour son statut à 'success'.
Capture
Surveiller les événements de statut de déploiement via des webhooks pour un état de 'success'.
Type d'événement
inferred
|
|||
|
Modifications demandées en révision
|
Un relecteur a terminé sa révision de code et a déterminé que des modifications sont nécessaires avant que la `pull request` puisse être approuvée. Le relecteur soumet officiellement sa révision avec le statut 'demande de modifications'. | ||
|
Pourquoi c'est important
Cet événement signale explicitement une boucle de retravail. L'analyse de sa fréquence aide à identifier les problèmes de qualité, les exigences peu claires ou les domaines nécessitant une formation des développeurs.
Où obtenir
Capturé à partir de l'API GitHub Pull Request ou des webhooks lorsqu'une révision est soumise avec l'état 'CHANGES_REQUESTED'.
Capture
Filtrer les événements de soumission de révision de
Type d'événement
explicit
|
|||
|
Problème rouvert
|
Un problème précédemment fermé est réactivé, généralement parce que le correctif était insuffisant ou qu'une régression a été trouvée. C'est un événement explicite qui redémarre le cycle de vie de l'élément de développement. | ||
|
Pourquoi c'est important
Ceci signale une boucle de retravail significative, indiquant une potentielle « échappement de défaut en production » ou une correction incomplète. Le suivi de sa fréquence est une mesure clé de la qualité logicielle globale.
Où obtenir
Il s'agit d'un événement explicite capturé à partir du flux d'événements de l'API GitHub Issues. Le type d'événement est 'reopened'.
Capture
Écouter l'événement 'reopened' sur une tâche (issue) via des webhooks ou l'interrogation de l'API.
Type d'événement
explicit
|
|||
|
Revue demandée
|
L'auteur d'une demande de tirage (pull request) sollicite formellement des membres d'équipe ou des équipes spécifiques pour revoir son code. Il s'agit d'une action explicite au sein de l'interface utilisateur ou de l'API GitHub qui déclenche des notifications aux réviseurs demandés. | ||
|
Pourquoi c'est important
Cette activité marque le début officiel du transfert vers le processus de revue de code. Le temps entre cette étape et la soumission d'une revue aide à mesurer la réactivité du réviseur et les goulots d'étranglement potentiels.
Où obtenir
Capturé à partir du flux d'événements de l'API GitHub Pull Request ou des webhooks. L'action de l'événement est 'review_requested'.
Capture
Écouter l'action 'review_requested' pour une demande de tirage (pull request).
Type d'événement
explicit
|
|||
|
Vérifications CI échouées
|
Représente l'échec d'une vérification automatisée, comme une erreur de build ou un échec de test unitaire, exécutée sur le code d'une demande de tirage (pull request). Cela est déduit d'un statut d'échec signalé par un système comme GitHub Actions. | ||
|
Pourquoi c'est important
Cette activité met en évidence des problèmes de qualité technique nécessitant l'intervention du développeur, créant une boucle de retravail. L'analyse de la fréquence des échecs peut orienter les améliorations des tests locaux ou de la qualité du code.
Où obtenir
Déduit de l'API GitHub Checks ou de l'API Statuses. Une exécution de vérification ou une mise à jour de statut signale un 'failure' ou 'completed' avec une conclusion de 'failure'.
Capture
Surveiller l'API Checks pour une conclusion 'failure' sur les suites de vérification pertinentes.
Type d'événement
inferred
|
|||