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é
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. | ||
|
Descriptionn
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 complet pour un élément de développement. Cet attribut est indispensable 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 écarts et localise les points de blocage.
Pourquoi est-ce important ? :
Cet attribut sert de base à la carte de processus, pour visualiser et l'analyse de la séquence des événements dans le cycle de vie du développement.
Source des données :
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éePull Request 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). | ||
|
Descriptionn
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 complet d'une tâche de développement. Il permet de reconstituer le parcours complet d'une fonctionnalité ou d'une correction de bogue, permettant une analyse détaillée des points de blocage, des boucles de retravail et des variations de processus pour les éléments de travail individuels.
Pourquoi est-ce 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.
Source des données :
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. | ||
|
Descriptionn
Cet horodatage marque le début d'une activité. Il est impératif 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 indispensable pour calculer toutes les métriques temporelles, 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 points de blocage et aux dashboards de suivi des performances.
Pourquoi est-ce important ? :
Cet horodatage est indispensable 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 points de blocage.
Source des données :
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. | ||
|
Descriptionn
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 indispensable pour le tableau de bord « Débit par projet et par type ».
Pourquoi est-ce 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.
Source des données :
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é. | ||
|
Descriptionn
L'horodatage de fin marque la fin 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 est-ce 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.
Source des données :
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'. | ||
|
Descriptionn
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 indispensable 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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 dans GitHub. Comprendre le type de travail est impératif 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 est-ce 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,
Source des données :
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
BugFeatureTâ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. | ||
|
Descriptionn
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 indispensable 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 points de blocage des ressources et analyser l'efficacité des transferts entre les différents membres de l'équipe. Les dashboards peuvent être filtrés par responsable pour évaluer la performance individuelle ou d'équipe et assurer une répartition équilibrée du travail.
Pourquoi est-ce important ? :
Primordial 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.
Source des données :
Disponible dans l'objet 'assignee' ou 'user' danss 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. | ||
|
Descriptionn
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 est-ce 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
Source des données :
Disponible dans l'objet 'user' dans l'objet principal des réponses API pour les problèmes, les
Exemples
sara.jonesmike.leeautomatisation-bot
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L'horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
|
Descriptionn
Cet attribut consigne la date et l'heure de la dernière extraction ou mise à jour des données. Il fournit des métadonnées sur la la réactualisation 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 impératif 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 dashboards opérationnels et le suivi.
Pourquoi est-ce important ? :
Indique la la réactualisation des données, ce qui est indispensable pour garantir que les analyses et les dashboards sont basés sur des informations à jour.
Source des données :
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'. | ||
|
Descriptionn
Cet attribut spécifie l'endroit où le code est déployé. Le suivi des déploiements vers différents environnements est indispensable 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 indispensable pour savoir quand un élément de développement est réellement 'terminé' et livré aux utilisateurs.
Pourquoi est-ce important ? :
Distingue les livraisons de prélèvement.-production et de production, ce qui est indispensable pour mesurer le véritable 'délai de mise sur le marché' et analyser les modèles de déploiement.
Source des données :
Ces informationsns 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 reprises
IsRework
|
Un indicateur booléen qui est vrai si une activité représente une régression vers une étape précédente du processus. | ||
|
Descriptionn
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 indispensable pour quantifier le gaspillage et l'inefficacité. Il contribue directement au le tableau de bord « Boucles de retouches et de régression » et le KPI « Taux de re-traitements ». En filtrant sur 'IsRework = true', les analystes peuvent isoler et investiguer les causes des retouches.
Pourquoi est-ce 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.
Source des données :
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'. | ||
|
Descriptionn
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 indispensable pour les dashboards 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 est-ce important ? :
Fournit une indication claire de l'état d'avancement ou d'achèvement d'un élément de travail, ce qui est indispensable pour l'analyse du cycle de vie et le suivi du travail actif.
Source des données :
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). | ||
|
Descriptionn
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 reprises 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 contribue directement au 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 est-ce 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é.
Source des données :
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. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
Un Bien que très granulaire, le
Pourquoi est-ce important ? :
Fournit le lien le plus granulairesre entre une étape de processus et le changement de code exact, permettant une traçabilité complète pour les audits et le débogage.
Source des données :
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. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
Une Cet identifiant est impératif pour le suivi du sous-processus d'intégration et de révision du code dans le 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 est-ce 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.
Source des données :
Disponible en tant que champ 'number' dans 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). | ||
|
Descriptionn
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 indispensable pour analyser le processus de révision de code. Il aide à identifier les points de blocage 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 du KPI 'Temps de cycle moyen de révision de code'.
Pourquoi est-ce 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.
Source des données :
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é). | ||
|
Descriptionn
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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 est-ce important ? :
Identifie l'origine des données, ce qui est indispensable pour la validation des données et pour l'analyse des processus qui peuvent s'étendre sur plusieurs systèmes intégrés.
Source des données :
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 Grande entreprise
|
|||
|
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. | ||
|
Descriptionn
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 indicateur clé 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 est-ce 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é.
Source des données :
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. | ||
|
Descriptionn
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 contribue directement au 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 est-ce important ? :
Représente le 'délai de mise sur le marché' complet pour un élément de développement, en faisant un KPI clé pour mesurer la vélocité et l'efficacité globale du processus.
Source des données :
Calculé au niveau du cas en soustrayant l'horodatage de la première activité de l'horodatage de la dernière activité.
Exemples
P5DT6H30MP14DT12HP1DT2H
|
|||
Activités du Cycle de vie du développement logiciel
| Activité | Descriptionn | ||
|---|---|---|---|
|
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 est-ce 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 indispensablele pour analyser séparément les temps de cycle de développement et de revue.
Source des données :
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 est-ce important ? :
Cette activité sert de fin définitive au processus pour un élément de développement. Elle est indispensablele pour le calcul des temps de cycle complet.
Source des données :
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 est-ce 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.
Source des données :
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
|
|||
|
Pull Request 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 est-ce 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 clé pour l'efficacité du processus de revue.
Source des données :
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
|
|||
|
Pull Request 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 est-ce 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é.
Source des données :
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
|
|||
|
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 est-ce important ? :
Cette porte de qualité automatisée est indispensablele pour assurer la stabilité du code. Les échecs ou les longs temps d'exécution peuvent constituer des points de blocage significatifs dans le pipeline de livraison.
Source des données :
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 est-ce 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
Source des données :
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 est-ce important ? :
Le suivi de ces événements est impératif pour identifier les boucles de reprise. Des poussées multiples après une revue indiquent que des modifications étaient nécessaires, affectant le temps de cycle global.
Source des données :
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 est-ce important ? :
Marque la transition du code du dépôt vers un environnement de production. Le suivi de cette étape est indispensable pour mesurer le délai complet, de l'idée à la production.
Source des données :
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 est-ce important ? :
Cet événement signale explicitement une boucle de reprises. 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.
Source des données :
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 est-ce important ? :
Ceci signale une boucle de reprises 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.
Source des données :
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 dans l'interface utilisateur ou de l'API GitHub qui déclenche des notifications aux réviseurs demandés. | ||
|
Pourquoi est-ce 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 points de blocage potentiels.
Source des données :
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 est-ce important ? :
Cette activité met en évidence des problèmes de qualité technique nécessitant l'intervention du développeur, créant une boucle de reprises. L'analyse de la fréquence des échecs peut orienter les améliorations des tests locaux ou de la qualité du code.
Source des données :
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
|
|||