Votre modèle de données pour le cycle de développement logiciel

GitHub
Votre modèle de données pour le cycle de développement logiciel

Votre modèle de données pour le cycle de développement logiciel

Ce modèle vous guide dans la collecte et la préparation des données de votre cycle de développement logiciel dans GitHub. Vous y trouverez les attributs recommandés, les activités essentielles à suivre et des conseils pratiques pour extraire les données. Servez-vous de cette ressource pour constituer un journal d’événements précis et analyser et optimiser efficacement vos processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Conseils pour l’extraction
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs du cycle de développement logiciel

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail le cycle de développement logiciel et d’en découvrir le déroulement.
3 Obligatoire 5 Recommandé 15 Facultatif
Nom Description
Activité
ActivityName
Nom d’un événement ou d’une tâche précise survenu au cours du cycle de vie du développement logiciel.
Description

Le nom de l’activité décrit une étape du processus de développement, comme « Issue créée », « Code poussé sur la PR », « Pull request approuvée » ou « Déploiement réussi ». Ces événements forment la séquence d’étapes qui constitue le processus de bout en bout d’un élément de développement.

Cet attribut est fondamental pour le Process Mining, car il sert à construire la carte du processus. L’analyse de l’ordre, de la fréquence et de la durée des activités révèle le déroulement réel du processus, fait ressortir les parcours courants et les écarts, et permet de repérer les goulots d’étranglement.

Pourquoi est-ce important ?

Cet attribut constitue la base de la carte du processus et permet de visualiser et d’analyser la séquence des événements du cycle de vie du développement.

Où trouver ces données

Dérivé du champ « action » du contenu des événements webhook, par exemple « opened » ou « closed » pour une issue, ou du type d’événement lui-même, par exemple « PushEvent » ou « PullRequestReviewEvent ».

Exemples
Issue crééePull request ouverteCode poussé sur la PRRevue demandéePull request fusionnée
Élément de développement
DevelopmentItemId
Identifiant unique d’une unité de travail de développement, comme une fonctionnalité, une correction de bug ou une tâche. Il sert d’identifiant principal du cas.
Description

L’identifiant de l’élément de développement suit un élément de travail depuis sa création jusqu’à son déploiement final. Il relie toutes les activités associées, comme la création de branches, les commits, les pull requests, les revues et les déploiements, au sein d’une même instance de processus.

Lors de l’analyse, cet identifiant sert à calculer le temps de cycle de bout en bout d’une tâche de développement. Il permet de reconstituer tout le parcours d’une fonctionnalité ou d’une correction de bug et d’analyser en détail les goulots d’étranglement, les boucles de reprise et les variations du processus pour chaque élément de travail.

Pourquoi est-ce important ?

Cette clé essentielle au Process Mining relie tous les événements de développement associés à un même cas, afin de visualiser et d’analyser avec précision l’ensemble du cycle de vie du développement logiciel.

Où trouver ces données

Il s’agit généralement du numéro de l’issue ou de la pull request dans GitHub. Il peut être extrait du champ « number » dans le contenu des événements webhook ou des réponses de l’API liés aux issues ou aux pull requests.

Exemples
101PR-2345TASK-812
Heure de début
EventTimestamp
Date et heure exactes auxquelles une activité ou un événement de développement s’est produit.
Description

Cet horodatage indique le début d’une activité. Il est essentiel pour classer les événements dans l’ordre chronologique et reconstituer le déroulement du processus pour chaque élément de développement. La séquence et les écarts de temps entre ces horodatages servent à analyser la performance du processus.

Lors de l’analyse, cet attribut est indispensable au calcul de toutes les métriques temporelles, notamment les temps de cycle, les durées de traitement et les temps d’attente. Il permet de repérer les retards entre les étapes et fournit les données nécessaires à l’analyse des goulots d’étranglement et au suivi des performances dans les Dashboards.

Pourquoi est-ce important ?

Cet horodatage est essentiel pour ordonner correctement les événements et calculer les indicateurs de performance, comme les temps de cycle et la durée des goulots d’étranglement.

Où trouver ces données

On le trouve généralement dans les champs « created_at » ou « updated_at » des contenus JSON renvoyés par les API et les webhooks GitHub pour différents objets, comme les issues, les pull requests et les commits.

Exemples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Dépôt
RepositoryName
Nom du dépôt de code dans lequel se déroule l’activité de développement.
Description

Le dépôt sert à identifier un projet ou un produit. Il contient l’ensemble du code, des issues et des pull requests d’une application ou d’un composant donné. Il permet de segmenter et de comparer les processus de développement de différents produits ou équipes.

Lors de l’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 des bugs du projet A se compare-t-il à celui du projet B ? ». Il constitue une dimension essentielle du Dashboard « Débit par projet et type ».

Pourquoi est-ce important ?

Permet de segmenter et de comparer les processus de développement entre différents projets, produits ou équipes, pour mener des analyses plus ciblées.

Où trouver ces données

Disponible dans l’objet « repository » de presque tous les contenus webhook et API GitHub. Le champ concerné 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
Date et heure exactes auxquelles une activité ou un événement de développement s’est terminé.
Description

L’horodatage de fin indique qu’une activité est terminée. De nombreux événements GitHub sont instantanés, comme « Issue créée », mais certaines activités ont une durée mesurable, comme l’exécution d’une vérification CI. La différence entre l’heure de fin et l’heure de début donne la durée de traitement de l’activité.

Cet attribut sert à calculer la métrique « ProcessingTime », essentielle pour comprendre le temps consacré activement à différentes tâches, comme les revues de code ou les vérifications automatisées. L’analyse des durées de traitement permet de repérer les activités inefficaces qui prennent trop de temps.

Pourquoi est-ce important ?

Permet de calculer précisément la durée de traitement des activités et de distinguer le temps de travail actif du temps d’attente.

Où trouver ces données

On peut trouver cette valeur dans le champ « completed_at » des objets d’exécution de vérification, ou la déduire de l’horodatage d’un événement ultérieur qui marque logiquement la fin de l’activité.

Exemples
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorité
Priority
Niveau de priorité attribué à un élément de développement, par exemple « Élevé », « Moyen » ou « Faible ».
Description

La priorité indique le degré d’urgence ou l’importance métier d’un élément de travail. Dans GitHub, la priorité n’est pas un champ natif ; elle est généralement gérée à l’aide d’étiquettes (par exemple, « P1-High », « P2-Medium »). Pour extraire cette information de manière fiable, il faut utiliser une convention d’étiquetage cohérente.

Cet attribut est essentiel à l’analyse des flux en fonction des priorités. Il permet de vérifier si les éléments prioritaires sont effectivement traités plus rapidement que les éléments moins prioritaires et de mesurer les écarts de temps de cycle selon la priorité. Il aide ainsi à évaluer l’efficacité du processus de priorisation.

Pourquoi est-ce important ?

Permet de vérifier si les éléments prioritaires sont traités plus rapidement que les autres et d’évaluer l’efficacité de la stratégie de priorisation.

Où trouver ces données

Dérivé des étiquettes GitHub appliquées aux issues ou aux pull requests. Une convention normalisée pour les étiquettes de priorité est nécessaire.

Exemples
ÉlevéMoyenFaibleCritique
Type d’élément de développement
DevelopmentItemType
Classification de l’élément de travail de développement, par exemple une fonctionnalité, un bug, une tâche ou une épopée.
Description

Cet attribut classe la nature du travail effectué. Ces informations sont généralement gérées au moyen de libellés ou de modèles d’issue spécifiques dans GitHub. Il est important de connaître le type de travail pour définir des attentes de performance adaptées : le temps de cycle prévu pour corriger un bug peut être bien plus court que celui d’une nouvelle fonctionnalité.

Cet attribut permet de comparer différents types de travail. Il aide à déterminer si les corrections de bugs sont traitées plus rapidement que les nouvelles fonctionnalités et à comprendre la répartition des ressources entre la dette technique et les nouveaux développements. Il constitue une dimension clé du Dashboard « Débit par projet et type ».

Pourquoi est-ce important ?

Classe les éléments de travail pour comparer leurs performances et analyser comment les différents types de travail, comme les bugs et les fonctionnalités, progressent dans le processus.

Où trouver ces données

Généralement déduit des libellés appliqués aux issues ou aux pull requests dans GitHub. Une convention de libellés cohérente est nécessaire, par exemple « type:bug » ou « type:feature ».

Exemples
BugFonctionnalitéTâcheDette technique
Utilisateur assigné
Assignee
Utilisateur ou développeur chargé de traiter l’élément de développement ou une tâche précise, comme la revue d’une pull request.
Description

Cet attribut identifie la personne responsable du travail à une étape donnée. Il peut s’agir de la personne à qui une issue est assignée, de l’auteur d’une pull request ou de la personne sollicitée pour une revue de code. Le suivi des personnes assignées est essentiel pour comprendre la répartition des ressources et la charge de travail.

Cet attribut sert à suivre la charge des développeurs, à repérer les goulots d’étranglement liés aux ressources et à analyser l’efficacité des transmissions entre les membres de l’équipe. Les Dashboards peuvent être filtrés par personne assignée pour évaluer les performances individuelles ou collectives et veiller à une répartition équilibrée du travail.

Pourquoi est-ce important ?

Indispensable pour analyser la charge de travail des développeurs, les performances de l’équipe et l’efficacité des transmissions entre ses membres.

Où trouver ces données

Disponible dans l’objet « assignee » ou « user » des contenus JSON associés aux issues, aux pull requests et aux événements de revue renvoyés par l’API GitHub.

Exemples
john.doejane.smithdev-team-lead
Auteur
Author
L’utilisateur qui a créé l’issue, la pull request ou le commit.
Description

L’auteur est à l’origine d’un artefact précis du processus de développement. Par exemple, l’auteur d’une issue est la personne qui a signalé le bogue ou demandé la fonctionnalité. L’auteur d’une pull request est le développeur qui a écrit le code.

L’analyse de l’auteur permet de comprendre d’où vient le travail. L’étude des auteurs des rapports de bogues, par exemple, peut révéler des tendances propres à certaines équipes ou fonctionnalités. Cet attribut peut également être associé à la personne chargée du traitement pour analyser les transferts de responsabilité.

Pourquoi est-ce important ?

Identifie l’origine d’un élément de travail ou d’une modification de code, ce qui peut aider à analyser les sources de reprises, les rapports de bogues ou les demandes de fonctionnalités.

Où trouver ces données

Disponible dans l’objet « user » de l’objet principal des réponses de l’API pour les issues, les pull requests et les commits. Le champ est généralement « user.login ».

Exemples
sara.jonesmike.leeautomation-bot
Dernière mise à jour des données
LastDataUpdate
Horodatage 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 renseigne sur leur fraîcheur. Il se distingue de l’horodatage de l’événement, qui indique quand l’événement métier s’est produit.

Lors de l’analyse, ce champ permet de savoir si la vue du processus est à jour. Les utilisateurs peuvent ainsi déterminer s’ils consultent des données en temps réel ou un instantané pris à un moment donné, une distinction importante pour les Dashboards opérationnels et le suivi.

Pourquoi est-ce important ?

Indique si les données sont à jour, ce qui est essentiel pour que les analyses et les Dashboards reposent sur des informations récentes.

Où trouver ces données

Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement des données (ETL).

Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Environnement de déploiement
DeploymentEnvironment
Environnement cible d’un déploiement, par exemple « Préproduction » ou « Production ».
Description

Cet attribut précise l’environnement dans lequel le code est déployé. Le suivi des déploiements dans différents environnements est essentiel pour comprendre l’ensemble du cycle, du développement à la mise en production.

Il permet d’analyser le sous-processus de déploiement, de mesurer le délai nécessaire pour passer de la préproduction à la production et de suivre le taux de réussite des déploiements dans chaque environnement. Il aide à déterminer quand un élément de développement est réellement terminé et livré aux utilisateurs.

Pourquoi est-ce important ?

Distingue les mises en production des déploiements en préproduction, ce qui est essentiel pour mesurer le délai réel de mise sur le marché et analyser les schémas de déploiement.

Où trouver ces données

Ces informations proviennent de l’API GitHub Deployments, souvent déclenchée par des pipelines CI/CD ou d’autres mécanismes automatisés.

Exemples
developmentstagingproduction
Est une reprise
IsRework
Indicateur booléen qui vaut vrai lorsqu’une activité correspond à un retour à une étape antérieure du processus.
Description

Cet indicateur passe à vrai lorsqu’un élément de développement recule dans le processus, par exemple lorsqu’une revue de pull request demande des modifications ou qu’une issue est rouverte après sa clôture. Il est calculé à partir de la séquence des activités.

Cet attribut est essentiel pour quantifier les pertes et les inefficacités. Il alimente directement le Dashboard « Reprises et boucles de régression » et le KPI « Taux de reprise ». En filtrant sur « IsRework = true », les analystes peuvent isoler les reprises et en examiner les causes.

Pourquoi est-ce important ?

Signale explicitement les activités qui constituent des reprises, ce qui facilite leur quantification, leur visualisation et l’analyse des causes d’inefficacité du processus.

Où trouver ces données

Il s’agit d’un attribut calculé. La logique consiste à définir un flux de processus standard, puis à signaler toute activité qui s’en écarte en revenant à une étape logique antérieure.

Exemples
truefalse
État de l’élément
State
État actuel d’une issue ou d’une pull request, par exemple « open », « closed » ou « merged ».
Description

Cet attribut indique le statut général d’un élément de développement. Les issues ont généralement l’état « open » ou « closed ». Les pull requests peuvent être « open », « closed » ou « merged ». Il donne un aperçu de l’avancement de l’élément.

Lors de l’analyse, l’état permet de distinguer le travail en cours du travail terminé. Il est essentiel pour les Dashboards comme « Avancement du développement actif », qui suivent les travaux en cours. Il sert également à définir la fin d’un processus : un état « merged » ou « closed » peut, par exemple, marquer la fin d’un cas.

Pourquoi est-ce important ?

Indique clairement si un élément de travail est en cours ou terminé, une information fondamentale pour analyser le cycle de vie et suivre le travail actif.

Où trouver ces données

Disponible directement dans le champ « state » des contenus JSON des issues et des pull requests renvoyés par l’API GitHub.

Exemples
OuverteFerméeFusionnée
État de la revue
ReviewState
Résultat d’une revue de code sur une pull request, par exemple « Approuvé » ou « Modifications demandées ».
Description

Cet attribut enregistre la décision du réviseur. Parmi les états courants, « APPROVED » signifie que le code peut être fusionné, tandis que « CHANGES_REQUESTED » indique que des reprises sont nécessaires. D’autres états sont possibles, comme « COMMENTED » ou « PENDING ».

Cet attribut est essentiel à l’analyse des reprises et de la qualité. Une fréquence élevée d’événements « CHANGES_REQUESTED » peut signaler des problèmes de qualité du code initial ou des exigences peu claires. Il alimente directement le Dashboard « Reprises et boucles de régression » en indiquant quand un élément de développement est renvoyé pour modification.

Pourquoi est-ce important ?

Met directement en évidence les boucles de reprise et les points de contrôle qualité du processus de revue de code, afin de repérer les sources d’inefficacité et les problèmes de qualité.

Où trouver ces données

Disponible dans le champ « state » d’un objet de revue de pull request provenant de l’API GitHub, par exemple dans le contenu d’un « PullRequestReviewEvent ».

Exemples
APPROVEDCHANGES_REQUESTEDCOMMENTED
État du contrôle CI
CiCheckStatus
Résultat d’un contrôle d’intégration continue (CI) automatisé, par exemple « réussi » ou « échoué ».
Description

Cet attribut indique le résultat des compilations, tests et analyses automatisés exécutés sur les modifications de code d’une pull request. Dans les flux de développement actuels, les contrôles CI constituent un point de contrôle qualité essentiel.

Son analyse aide à évaluer l’efficacité des tests automatisés. Un taux d’échec élevé peut révéler des problèmes de stabilité du code, de suite de tests ou d’environnement de développement. Cet attribut alimente les activités « Contrôles CI réussis » et « Contrôles CI échoués » et permet d’analyser les retards dus aux compilations défaillantes.

Pourquoi est-ce important ?

Indique la réussite ou l’échec des contrôles qualité automatisés et renseigne sur la qualité du code ainsi que sur l’efficacité du pipeline CI.

Où trouver ces données

Récupéré dans le champ « state » ou « conclusion » des objets check run ou status via l’API GitHub Checks ou Statuses.

Exemples
successfailurependingerror
Étiquettes
Labels
Liste d’étiquettes appliquées à une issue ou à une pull request pour la catégoriser.
Description

Dans GitHub, les étiquettes permettent d’ajouter des métadonnées aux issues et aux pull requests. Elles peuvent indiquer la priorité, le type de travail, les composants, les équipes ou l’état. La liste complète des étiquettes fournit un contexte riche, mais non structuré.

Des attributs précis, comme la priorité et le type, peuvent être déduits des étiquettes. Conserver la liste complète reste utile pour les analyses ponctuelles et la recherche d’autres schémas de processus. Elle permet de filtrer et de segmenter les cas selon toute combinaison d’étiquettes.

Pourquoi est-ce important ?

Fournit une source souple et riche de métadonnées pour catégoriser les éléments de travail et réaliser des analyses détaillées selon différentes dimensions.

Où trouver ces données

Disponible dans le tableau « labels » du contenu JSON des issues et des pull requests provenant de l’API GitHub. Chaque élément du tableau est un objet doté d’un champ « name ».

Exemples
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Hash du commit
CommitHash
Identifiant unique (SHA) d’un commit de code.
Description

Un hash de commit est une empreinte SHA-1 de 40 caractères qui identifie de manière unique un commit dans Git. Il sert d’identifiant permanent pour une version précise du code. Les commits sont les unités élémentaires de modification du processus de développement.

Bien qu’il soit très détaillé, le hash de commit offre le niveau de traçabilité le plus précis. Il permet de relier directement un événement de processus à la modification de code exacte. Cette information peut être précieuse pour les audits, la conformité ou l’analyse détaillée des causes premières d’incidents en production.

Pourquoi est-ce important ?

Établit le lien le plus précis entre une étape du processus et la modification de code correspondante, pour assurer une traçabilité complète lors des audits et du débogage.

Où trouver ces données

Disponible dans le contenu des événements push (« head_commit.id ») ou via l’API Commits pour une pull request ou une branche.

Exemples
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nom de la branche
BranchName
Nom de la branche Git dans laquelle les modifications de code de l’élément de développement ont été apportées.
Description

Une branche est une ligne de développement indépendante, créée pour travailler sur une nouvelle fonctionnalité ou corriger un bogue sans modifier la base de code principale. Son nom contient souvent des informations utiles, comme le numéro de l’issue ou une brève description du travail.

L’analyse des noms de branches aide à comprendre les stratégies de branchement et à vérifier le respect des conventions de développement. Elle permet aussi de relier des commits précis à un élément de développement et d’obtenir une vue complète de l’activité de codage.

Pourquoi est-ce important ?

Précise la ligne de développement concernée et aide à appliquer et à analyser les stratégies de branchement ainsi que les conventions de nommage.

Où trouver ces données

Disponible dans le champ « ref » des événements push, ou dans les objets « head » et « base » d’une réponse de l’API pull request.

Exemples
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Numéro de pull request
PullRequestNumber
Identifiant unique de la pull request associée à l’élément de développement.
Description

Une pull request (PR) propose de fusionner un ensemble de modifications de code dans une branche précise. Le numéro de pull request relie les activités de développement, comme les envois de code et les revues, à l’élément de développement ou à l’issue d’origine.

Cet identifiant permet de suivre l’intégration du code et le sous-processus de revue dans le cycle de développement global. Il rend possible une analyse détaillée de la revue de code, notamment des délais de revue, des cycles de reprise relevés pendant la revue et des taux de fusion. Il relie la phase de planification (issue) à la phase de mise en œuvre (PR).

Pourquoi est-ce important ?

Relie les issues aux modifications de code et aux revues correspondantes, afin d’analyser en détail le cycle de revue de code et son incidence sur le délai global de livraison.

Où trouver ces données

Disponible dans le champ « number » de l’objet « pull_request » de nombreuses réponses de l’API GitHub, ou comme identifiant principal dans l’API Pull Requests.

Exemples
12345678910
Réviseur
Reviewer
L’utilisateur auquel une revue de code d’une pull request a été demandée.
Description

Un réviseur est un développeur ou un membre de l’équipe chargé d’examiner les modifications de code d’une pull request afin d’en vérifier la qualité, l’exactitude et la conformité aux normes. Une pull request peut avoir plusieurs réviseurs.

Cet attribut est essentiel à l’analyse du processus de revue de code. Il aide à repérer les goulots d’étranglement liés à certains réviseurs, à comprendre la répartition de la charge de revue et à mesurer le délai de réponse aux demandes. Il entre dans le calcul du KPI « Temps de cycle moyen de revue de code ».

Pourquoi est-ce important ?

Identifie les personnes qui participent au contrôle qualité et permet d’analyser la charge de revue, les retards et l’efficacité globale des revues de code.

Où trouver ces données

Disponible dans le tableau « requested_reviewers » ou dans l’objet « user » d’un événement de revue de pull request provenant de l’API GitHub.

Exemples
alex.chenmaria.garciasenior-dev-team
Système source
SourceSystem
Système d’où proviennent les données du processus de développement.
Description

Cet attribut indique l’origine des données d’événement. Pour ce processus, sa valeur serait toujours « 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 et Jenkins pour le déploiement, ce champ permet de distinguer la source de chaque événement.

Lors de l’analyse, il aide à retracer l’origine des données pour les valider et résoudre les problèmes. Il permet également d’analyser les processus qui couvrent plusieurs plateformes et de situer clairement chaque activité.

Pourquoi est-ce important ?

Indique l’origine des données, ce qui est essentiel pour les valider et analyser les processus qui peuvent s’étendre à plusieurs systèmes intégrés.

Où trouver ces données

Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement des données (ETL) pour identifier la source des enregistrements.

Exemples
GitHubGitHub Enterprise
Temps d’attente lors d’un transfert
HandoffWaitingTime
Temps d’inactivité calculé pendant lequel un élément de développement attend entre des activités réalisées par des personnes différentes.
Description

Cette métrique mesure le temps entre la fin d’une activité et le début de la suivante, uniquement lorsque la personne responsable change. Par exemple, elle mesure le délai entre un événement « Revue demandée » et un événement « Modifications demandées lors de la revue » effectué par un autre utilisateur.

Elle est essentielle pour repérer les problèmes de communication et de coordination. Elle alimente le Dashboard « Efficacité des transferts critiques » et le KPI « Temps d’attente moyen lors d’un transfert ». Des attentes prolongées aux points de transfert signalent souvent un manque de ressources ou des processus de notification inefficaces.

Pourquoi est-ce important ?

Repère les retards dus à une mauvaise coordination ou à l’indisponibilité des ressources lors des transferts entre équipes ou rôles, souvent à l’origine d’importantes inefficacités.

Où trouver ces données

Calculé en repérant les activités consécutives pour lesquelles l’attribut « Assignee » ou « User » change, puis en mesurant le délai qui les sépare.

Exemples
PT1H15MP2DT4HPT25M
Temps de cycle de développement
DevelopmentCycleTime
Durée totale entre la création d’un élément de développement et son déploiement final ou sa clôture.
Description

Cette métrique au niveau du cas correspond au temps écoulé entre le premier événement (par exemple, « Issue créée ») et le dernier (par exemple, « Déploiement réussi » ou « Issue clôturée ») pour un même élément de développement.

C’est l’un des KPI les plus importants pour mesurer l’efficacité globale du processus de développement. Cette métrique alimente directement le Dashboard « Temps de cycle global du développement » et le KPI « Temps de cycle moyen de développement ». Les initiatives d’amélioration des processus visent souvent à la réduire.

Pourquoi est-ce important ?

Représente le délai de mise sur le marché d’un élément de développement, un KPI important pour mesurer la rapidité et l’efficacité globales du processus.

Où trouver ces données

Calculé au niveau du cas en soustrayant l’horodatage de la première activité de celui de la dernière.

Exemples
P5DT6H30MP14DT12HP1DT2H
Obligatoire Recommandé Facultatif

Activités du cycle de développement logiciel

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir précisément le déroulement du processus et repérer les goulots d’étranglement.
6 Recommandé 7 Facultatif
Activité Description
Issue créée
Marque le début du cycle de vie d’un élément de développement : la création officielle d’une tâche, d’un bug ou d’une demande de fonctionnalité. Cet événement est enregistré lorsqu’un utilisateur crée une nouvelle issue dans un dépôt GitHub.
Pourquoi est-ce important ?

Il s’agit de l’activité de départ principale du processus. Elle est indispensable pour mesurer le temps de cycle total du développement et comprendre d’où provient le travail initial.

Où trouver ces données

Il s’agit d’un événement explicite enregistré dans le flux d’événements de l’API GitHub Issues. Pour une issue donnée, le type d’événement est généralement « opened ».

Données à recueillir

Surveillez l’événement « opened » d’une issue au moyen de webhooks ou de requêtes périodiques à l’API.

Type d’événement explicit
Issue fermée
L’élément de développement est considéré comme terminé et l’issue correspondante est officiellement fermée. La fermeture peut être automatique après la fusion d’une pull request associée ou effectuée manuellement par un membre de l’équipe.
Pourquoi est-ce important ?

Cette activité marque la fin définitive du processus pour un élément de développement. Elle est indispensable au calcul des temps de cycle de bout en bout.

Où trouver ces données

Il s’agit d’un événement explicite enregistré dans le flux d’événements de l’API GitHub Issues. Le type d’événement est « closed ».

Données à recueillir

Surveillez l’événement « closed » d’une issue au moyen de webhooks ou de requêtes périodiques à l’API.

Type d’événement explicit
Pull request approuvée
Une personne chargée de la revue a officiellement approuvé les modifications d’une pull request, confirmant qu’elles répondent aux exigences de qualité et de fonctionnement. L’événement est enregistré lorsqu’elle soumet sa revue avec le statut « approve ».
Pourquoi est-ce important ?

Cette étape constitue un contrôle qualité important et un jalon majeur avant la fusion. Le temps écoulé entre la création de la PR et son approbation est un indicateur clé de l’efficacité du processus de revue.

Où trouver ces données

L’événement est enregistré via l’API GitHub Pull Request ou des webhooks lorsqu’une revue est soumise avec l’état « APPROVED ».

Données à recueillir

Filtrez les événements de soumission de revue de pull request pour ne conserver que ceux dont l’état est « APPROVED ».

Type d’événement explicit
Pull request fusionnée
Les modifications approuvées de la pull request sont officiellement intégrées à la branche cible, par exemple main ou develop. Cette action finale explicite sur la pull request intègre le nouveau code.
Pourquoi est-ce important ?

Cette étape importante marque la fin du développement et de la revue. Pour de nombreuses équipes, elle précède immédiatement le déploiement automatisé.

Où trouver ces données

L’événement est enregistré dans le flux d’événements de l’API GitHub Pull Request ou via des webhooks. L’action est « closed » et l’attribut « merged » du contenu de la pull request est défini sur true.

Données à recueillir

Surveillez l’action « closed » d’une pull request et vérifiez si l’indicateur « merged » est défini sur true.

Type d’événement explicit
Pull request ouverte
Signale qu’un premier ensemble de modifications est prêt à être examiné et intégré. Un développeur crée une pull request (PR) pour proposer l’intégration des changements de sa branche de fonctionnalité dans une branche principale. Cet événement est explicitement enregistré dans GitHub.
Pourquoi est-ce important ?

Cette étape importante marque la fin de la phase initiale de développement et le début du processus de revue et d’intégration. Elle permet d’analyser séparément les temps de cycle du développement et de la revue.

Où trouver ces données

L’événement est enregistré dans le flux d’événements de l’API GitHub Pull Request ou via des webhooks. L’action correspondante est « opened ».

Données à recueillir

Surveillez l’action « opened » d’une pull request au moyen de webhooks ou de requêtes périodiques à l’API.

Type d’événement explicit
Vérifications CI réussies
Indique la réussite des vérifications automatisées, comme les compilations, les tests unitaires ou l’analyse statique, exécutées sur le code d’une pull request. Cet événement est déduit du statut des vérifications signalées par des systèmes tels que GitHub Actions.
Pourquoi est-ce important ?

Ce contrôle qualité automatisé contribue à garantir la stabilité du code. Les échecs ou les longues durées d’exécution peuvent constituer des goulots d’étranglement importants dans le processus de livraison.

Où trouver ces données

L’événement est déduit des API GitHub Checks ou Statuses. Une exécution de vérification ou une mise à jour de statut indique « success », ou « completed » avec une conclusion « success ».

Données à recueillir

Surveillez l’API Checks pour repérer une conclusion « success » dans les suites de vérifications concernées.

Type d’événement inferred
Branche créée
Marque le début du travail de développement actif sur une issue, lorsqu’un développeur crée une branche à partir du code principal. Cet événement explicite est enregistré lorsqu’une nouvelle branche est poussée vers le dépôt. Son nom contient souvent le numéro de l’issue.
Pourquoi est-ce important ?

Indique le passage de la planification au développement actif. Le temps écoulé entre la création de l’issue et cet événement permet d’analyser le délai avant la prise en charge par un développeur et les retards initiaux dans le backlog.

Où trouver ces données

L’événement est enregistré via l’API Git de GitHub ou des webhooks qui surveillent les événements « create » de type « branch ». Il est souvent nécessaire d’associer le nom de la branche à une issue en s’appuyant sur une convention de nommage, par exemple « feature/issue-123 ».

Données à recueillir

Analysez les événements webhook « create » correspondant aux nouvelles branches et associez chaque branche à une issue.

Type d’événement explicit
Code poussé sur la PR
Correspond à une mise à jour du code soumis à la revue, qu’elle fasse partie de la PR initiale ou qu’elle réponde aux commentaires de revue. Cet événement est enregistré chaque fois qu’un nouveau commit est poussé sur la branche associée à une pull request ouverte.
Pourquoi est-ce important ?

Le suivi de ces événements est essentiel pour repérer les boucles de reprise. Plusieurs pushes après une revue indiquent que des modifications ont été demandées et influent sur le temps de cycle global.

Où trouver ces données

Il s’agit d’un événement explicite dans l’historique de la pull request, souvent indiqué comme l’ajout d’un commit. Il peut être enregistré à partir du webhook « push » ou en surveillant les commits associés à une PR.

Données à recueillir

Suivez les événements « push » sur une branche associée à une pull request ouverte.

Type d’événement explicit
Déploiement réussi
Les modifications du code ont été déployées avec succès dans un environnement donné, comme la préproduction ou la production. Cet événement est généralement enregistré via l’API GitHub Deployments, souvent à la suite d’une action GitHub déclenchée après une fusion.
Pourquoi est-ce important ?

Marque le passage du code du dépôt à un environnement en service. Son suivi est indispensable pour mesurer le délai total entre l’idée et la mise en production.

Où trouver ces données

L’événement est enregistré via l’API Deployments. Un service externe ou une action GitHub crée un déploiement, puis met son statut à jour sur « success ».

Données à recueillir

Surveillez les événements de statut de déploiement via des webhooks pour repérer l’état « success ».

Type d’événement inferred
Issue rouverte
Une issue précédemment fermée est réactivée, généralement parce que la correction était insuffisante ou qu’une régression a été détectée. Cet événement explicite relance le cycle de vie de l’élément de développement.
Pourquoi est-ce important ?

Cet événement signale une boucle de reprise importante, qui peut indiquer qu’un défaut a échappé aux contrôles avant la mise en production ou que la correction est incomplète. Le suivi de sa fréquence est un indicateur clé de la qualité globale du logiciel.

Où trouver ces données

Il s’agit d’un événement explicite enregistré dans le flux d’événements de l’API GitHub Issues. Le type d’événement est « reopened ».

Données à recueillir

Surveillez l’événement « reopened » d’une issue au moyen de webhooks ou de requêtes périodiques à l’API.

Type d’événement explicit
Modifications demandées lors de la revue
Après avoir examiné le code, la personne chargée de la revue estime que des modifications sont nécessaires avant de pouvoir approuver la pull request. Elle soumet officiellement son avis avec le statut « request_changes ».
Pourquoi est-ce important ?

Cet événement signale explicitement une boucle de reprise. L’analyse de sa fréquence aide à repérer les problèmes de qualité, les exigences peu claires ou les besoins de formation des développeurs.

Où trouver ces données

L’événement est enregistré via l’API GitHub Pull Request ou des webhooks lorsqu’une revue est soumise avec l’état « CHANGES_REQUESTED ».

Données à recueillir

Filtrez les événements de soumission de revue de pull request pour ne conserver que ceux dont l’état est « CHANGES_REQUESTED ».

Type d’événement explicit
Revue demandée
L’auteur d’une pull request demande officiellement à certains membres ou équipes d’examiner son code. Cette action explicite, effectuée dans l’interface ou via l’API GitHub, envoie une notification aux personnes sollicitées.
Pourquoi est-ce important ?

Cette activité marque le début officiel de la transmission au processus de revue de code. Le temps écoulé jusqu’à l’envoi d’une revue permet de mesurer la réactivité des personnes chargées de la revue et de repérer d’éventuels goulots d’étranglement.

Où trouver ces données

L’événement est enregistré dans le flux d’événements de l’API GitHub Pull Request ou via des webhooks. L’action correspondante est « review_requested ».

Données à recueillir

Surveillez l’action « review_requested » d’une pull request.

Type d’événement explicit
Vérifications CI échouées
Indique l’échec d’une vérification automatisée, par exemple une erreur de compilation ou un test unitaire échoué, exécutée sur le code d’une pull request. Cet événement est déduit d’un statut d’échec signalé par un système tel que GitHub Actions.
Pourquoi est-ce important ?

Cette activité met en évidence des problèmes de qualité technique qui nécessitent l’intervention d’un développeur et entraînent une boucle de reprise. L’analyse de la fréquence des échecs peut orienter les améliorations des tests locaux ou de la qualité du code.

Où trouver ces données

L’événement est déduit des API GitHub Checks ou Statuses. Une exécution de vérification ou une mise à jour de statut indique « failure », ou « completed » avec une conclusion « failure ».

Données à recueillir

Surveillez l’API Checks pour repérer une conclusion « failure » dans les suites de vérifications concernées.

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis GitHub

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données et commencer à optimiser votre cycle de développement logiciel. Repérez les inefficacités et accélérez vos mises en production dès aujourd’hui.

Améliorez votre cycle de développement logiciel : repérez immédiatement les inefficacités

Réduisez le temps de cycle de 30 % et optimisez votre processus de développement dans GitHub.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.