Extraire des informations de votre référentiel avec l’API de GitHub
Dans tout projet logiciel, les scrum masters et les chefs de projet ont tendance à disposer d’outils pour mesurer la performance de leurs équipes. Il y en a plein, comme Jira, Azure DevOps, ou même un simple fichier Excel. Bien que certains de ces outils soient plus avancés que d’autres, ils essaient tous d’accomplir la même chose, en mesurant le pouls de l’équipe et du projet. Ne serait-ce pas cool d’avoir la même chose, mais plutôt pour la « santé technique » ?
Des améliorations dans la livraison de logiciels sont possibles pour chaque équipe et dans chaque entreprise, tant que la direction fournit un soutien cohérent, y compris le temps, les actions et les ressources. — Gene Kim et al. dans ‘Accélérer la science des logiciels lean et devops en créant et en faisant évoluer des organisations technologiques hautement performantes’
Il me manque un outil qui examine comment se porte l’équipe technique d’un projet. Avant de proposer un tas de suggestions, permettez-moi de reformuler cette dernière phrase : J’aimerais avoir un outil avec des mesures qui m’aident à trouver comment l’équipe se porte et qui n’ajoutent pas de coûts au projet.
Dans GitHub, nous avons Connaissances, qui sont essentiellement des mesures clés extraites de l’activité de votre référentiel. Si vous êtes comme moi et que vous n’avez pas un accès complet à toutes les fonctionnalités offertes par un abonnement d’entreprise, mais que vous souhaitez tout de même jouer avec les données, je vous suggère d’utiliser la méthode d’analyse exploratoire ou EDA. Personnellement, j’en apprends encore. Mais d’abord, nous avons besoin de quelques données pour jouer avec.
Comme vous pouvez le voir sur l’image, tout commence par un jeu de données. En tant que propriétaires ou peut-être contributeurs du référentiel, nous sommes conscients des informations générées, mais vous pouvez toujours consulter la documentation pour avoir une vue d’ensemble des données que vous pouvez utiliser. Dans cet article, je n’aborderai pas le processus EDA complet, mais je donnerai quelques conseils sur la création d’un jeu de données pour commencer à jouer.
Avant de vous salir les mains, sachez que :
- La limite quotidienne de requêtes que vous avez dans l’API. Essayez d’être aussi efficace que possible et de ne pas dépasser les limites. Vous serez bloqué jusqu’à ce que les limites soient réinitialisées.
- N’extrayez pas les données dont vous n’avez pas besoin.
- Trouvez des KPI clés qui vous aideront à comprendre comment votre équipe se porte.
À titre d’exemple, je pense qu’il serait bien d’avoir un petit résumé des PR qui ont été fusionnés au cours de la semaine. Je trouve qu’il y a souvent un écart entre ce que le scrum master voit dans JIRA et ce que les développeurs poussent réellement. Les causes peuvent varier, allant des correctifs de dernière minute non suivis aux fonctionnalités complexes qui doivent être divisées en plusieurs PR. En récupérant ces informations, j’espère obtenir un résumé concis de l’avancement de la semaine et une compréhension plus claire de l’activité réelle du référentiel. De plus, ces informations peuvent provenir d’autres données pertinentes comme la réactivité de l’équipe ou le nombre d’itérations sur certaines fonctionnalités !
Construire un ensemble de données significatif
Jetez un oeil au script suivant; il montre comment s’authentifier auprès de notre référentiel, récupérer des données sur les demandes d’extraction et mapper la réponse à un fichier CSV. Puisque nous utilisons l’API REST, le filtrage est limité aux en-têtesvous devrez donc peut-être filtrer davantage les résultats à l’aide de GraphQL ou d’une bibliothèque comme jQuery.
Remarquez que j’ai utilisé un fichier nommé credentials.json
pour stocker mon nom d’utilisateur et mon mot de passe puisque j’exécute le script localement.
Le tableau au-dessus de ces lignes montre un exemple du type de données que le script récupère, comme le titre, la date de création, la date de fusion, etc. À partir de là, vous pouvez vous lancer dans la manipulation des données ou créer des tableaux de bord faciles à lire pour partager avec l’équipe. Pouvez-vous penser à des KPI que votre équipe pourrait bénéficier de connaître ?
Si vous voulez plus d’idées sur ce que vous devriez mesurer, je vous suggère le livre « Accélérez la science des logiciels lean et DevOps en créant et en faisant évoluer des organisations technologiques hautement performantes. Cela m’a aidé à réfléchir à des façons plus significatives de penser à la performance technique.
Si vous ne voulez pas parcourir l’API GitHub ou si vous n’avez pas le temps, je vous suggère d’utiliser quelque chose comme Intégration de Notion avec GitHub. Vous pouvez synchroniser les demandes d’extraction et les problèmes de votre référentiel à suivre sous la forme d’un tableau. Il est facile à configurer et fournira des informations de base, mais ne vous attendez pas à pouvoir récupérer des informations sur les actions, les flux de travail ou d’autres activités plus détaillées.
J’espère que cet article a contribué à susciter un certain intérêt pour l’ingénierie basée sur les données et les moyens d’améliorer le cycle de vie de votre développement logiciel.