Aujourd’hui

Sur la période

Livraison

Lignes de code

Revue

Dépôts

Dépôts avec des PR de code ou des reviews sur la période

En ce moment

PR de code ouvertes, hors brouillons et PR des personnes parties, d’après la dernière synchro. Chaque PR n’apparaît que dans une liste, selon la dernière décision de chaque relecteur, les code owners qu’elle attend et le nombre d’approbations qu’il faut pour merger, et seulement après un délai en jours ouvrés : un jour approuvée, bloquée par un code owner ou sans review, trois jours avec des changements demandés ou en discussion. Celles sans aucune review ni commentaire depuis plus d’un mois sont à part, oubliées.

Chaque mois compte les PR ouvertes ce mois-là, et les reviews, merges, déploiements et exécutions de CI de ce mois-là, comme une période choisie sur les autres pages. Une évolution en vert va dans le bon sens, en orange dans le mauvais ; les autres sont neutres.

Ce qui ressort

Chaque constat vient d’une règle fixe, décrite dans la Méthode, et ne s’affiche qu’au-delà de son seuil, sur assez de PR ou d’exécutions. Une piste n’est pas un verdict : un chiffre dit où regarder, pas pourquoi.

Rien à signaler

Les règles vérifiées sur la période sans rien trouver

Taille des PR

PR de code mergées, par nombre de lignes modifiées

Chaque étape, en médiane

De bout en bout

PR de code ouvertes sur la période. Chacune ne compte que dans les étapes qu’elle a franchies : mergée sans review, elle n’a ni prise en charge ni relecture ; pas encore mergée, elle n’a que sa prise en charge. Un brouillon compte dès son ouverture. Le filtre de dépôts s’applique à toute la page.

Où passe le temps

Part de chaque étape dans le temps d’une PR relue, de son ouverture à son arrivée en prod, en moyenne

Chaque PR pèse autant, qu’elle ait pris une heure ou un mois. Au survol, la médiane de chaque étape.

Médiane de chaque étape

Selon la date d’ouverture des PR : les plus récentes n’ont pas encore toutes franchi chaque étape

Par dépôt

Dépôts avec des PR de code ouvertes sur la période

Pour repérer les binômes figés et le savoir qui circule peu, pas pour classer des personnes. Les personnes qui pèsent moins de 2 % des relectures de la période ont trop peu de données pour une ligne ou une colonne : elles sont regroupées dans « Peu de relectures » (« Autres » quand la largeur en écarte aussi d’autres), et une recherche les fait apparaître. Le filtre de dépôts s’applique à toute la page.

Relecteurs de chaque auteur

Combien de personnes relisent le code de chaque auteur, et la part du relecteur principal

Anciens collaborateurs

Plus aucune PR, review, commentaire ni merge depuis un mois : ces personnes n’apparaissent plus dans les tableaux, les listes et les cartes du tableau de bord. Leurs PR restent comptées dans les totaux.

Les chiffres des cartes

Sur la période et les dépôts choisis, pour chaque personne qui a écrit ou relu du code, triées par nombre de PR de code : celles qui en ont le moins en bas. La stack de chaque personne se calcule sur tous ses dépôts : le filtre de dépôts ne restreint que les chiffres.

Champions du mois

Tableau d’honneur

Les badges de chaque personne de l’équipe : bronze pour un mois en tête, argent pour deux d’affilée, or pour trois ou plus

Mois après mois

Un badge revient à qui a fait le plus de toute l’équipe sur un mois complet, ex æquo compris ; les lignes ajoutées et supprimées comptent le mois du merge de leur PR. Le Requin compte toutes les PR ouvertes, merges de branches compris, releases à part ; les autres badges, les PR de code seulement. Un mois reste acquis une semaine après sa fin, quelles que soient la période et les dépôts choisis ailleurs. Les personnes parties comptent dans la course : elles apparaissent sous leur nom dans ce tableau seulement.

Dépôts portés par une seule personne

Les chiffres des cartes

Sur la période et les dépôts choisis, pour chaque dépôt avec des PR de code, triés par nombre de PR de code. Sous « Qui l’écrit », les personnes de l’équipe qui ont écrit le plus de ces PR.

Hotfix

Sur la période

Mises en production

Intégration continue

Dependabot

Déploiements

PR mergées dans master ou main, et les indicateurs DORA de chaque dépôt

Calendrier des mises en production

Chaque case compte les PR mergées dans master ou main de ce dépôt sur cette période, plus foncée quand il y en a davantage ; au survol, combien sont des correctifs (hotfix et reverts).

Intégration continue

Exécutions GitHub Actions déclenchées par une PR ou un push

Exécutions

Dependabot

Mises à jour de dépendances proposées par Dependabot, comptées à part des PR de code

Par écosystème

Périmètre

Tous les dépôts de l’organisation, PR créées au cours des 36 derniers mois. La période choisie, ou les dates choisies dans ces 36 mois, filtre les PR créées et la date des reviews, commentaires et merges. Les PR et reviews des bots sont exclues. Les deux années avant la dernière se rechargent d’un mois à chaque synchro : tant qu’elles ne sont pas toutes là, les périodes de 24 et 36 mois attendent.

PR de code

Toutes les PR sauf celles de release (release/*, release-please, develop vers master) et de synchronisation de branches (merge*, back-merges, project/…/main vers develop ou master, branches de projet qui en ramènent une autre, comme project/…/merge-develop, project/…/develop-into-main ou project/…/sync-develop), comptées à part dans « Release / intég. ». Merges, délais, tailles, lignes et reviews ne portent que sur les PR de code.

PR relue

Au moins une review ou un commentaire de quelqu’un d’autre que l’auteur. Dans l’évolution, elle compte dans la période de la première intervention.

Délais et tailles

Médianes, moins sensibles que la moyenne aux quelques très grosses PR. Les délais ne comptent que les heures ouvrées, du lundi au vendredi de 9 h à 18 h, heure de Paris : une PR ouverte le vendredi soir et relue le lundi matin n’a pas attendu le week-end. Un jour compte 9 h ouvrées (« j ») ; les jours fériés comptent comme ouvrés. Seules les durées des exécutions de CI restent en temps réel. Taille : lignes ajoutées plus supprimées.

Lignes ajoutées et supprimées

Total des lignes des PR de code ouvertes sur la période et mergées, comptées comme GitHub : une ligne modifiée compte une fois supprimée et une fois ajoutée. Les PR de release et de synchronisation de branches n’y comptent pas, pour ne pas compter deux fois les mêmes lignes, ni celles des bots. Tous les fichiers comptent, fichiers générés et verrous de dépendances (package-lock.json, composer.lock…) compris : un gros chiffre peut en venir. Ils sont arrondis (12 k, 1,2 M), sauf dans le Bilan du mois.

Type de dépôt

Déduit des langages détectés par GitHub : Vue donne front ; PHP, Go, Rust donnent back ; Dart (Flutter) donne mobile ; la documentation, l’infrastructure et l’outillage sont classés « autres ». TypeScript et JavaScript comptent en front à côté de Vue, en back sinon. Quelques dépôts sont classés à la main.

Stack

Répartition des PR de code (auteurs) ou des PR relues (relecteurs) entre dépôts front, back et mobile, et technologies principales de ces dépôts. Les dépôts « autres » n’y comptent pas. « Full-stack » : au moins 30 % des PR côté back et au moins 30 % côté client (front ou mobile).

Technologies

Les langages d’un dépôt sont regroupés sous le framework que déclarent ses fichiers de dépendances (composer.json, package.json, pubspec.yaml) : PHP et Blade sous Laravel, Vue et TypeScript sous Nuxt, Dart sous Flutter, TypeScript sous NestJS… Chaque PR de code est répartie entre les technologies de son dépôt, au prorata de leur part dans le code (moins de 2 % : ignorée), tout comme, au choix, les lignes ajoutées par les PR de code mergées. Logos : Simple Icons.

Cycle de vie

Le temps d’une PR de code, de son ouverture à la prod, découpé en quatre étapes : la prise en charge, jusqu’à la première review ou au premier commentaire d’une autre personne ; la relecture, jusqu’à la dernière approbation avant le merge, ou jusqu’au merge sans approbation ; le merge, de cette approbation au merge ; la mise en prod, du merge à l’arrivée en prod, comme pour les indicateurs DORA. Chaque PR ouverte sur la période ne compte que dans les étapes qu’elle a franchies, et ce qui suit son merge n’y compte pas. Chaque étape a sa médiane : elles ne s’additionnent pas.

Bilan du mois

Un mois compte, comme une période choisie, les PR ouvertes ce mois-là et les reviews, merges, déploiements et exécutions de CI de ce mois-là. Il se compare au mois précédent (en pourcentage, ou en points pour les parts) et à la médiane des 12 derniers mois complets. Une évolution est en vert quand elle va dans le bon sens (délais, hotfix, reprises, PR sans review, échecs de CI en baisse), en orange sinon ; les volumes restent neutres. Le mois en cours, incomplet, ne se compare pas.

Analyse

Dix règles fixes croisent les chiffres de la période ; chacune ne parle que sur au moins 20 PR (10 pour un dépôt, 30 exécutions pour un workflow), et dit sinon qu’elle manque de données. Les délais sont ceux des PR relues, en heures ouvrées. Taille : les PR de 500 lignes ou plus mettent au moins deux fois plus de temps à être mergées que celles de moins de 100 lignes. PR géantes : les PR de 1 000 lignes ou plus sont mergées sans review ni commentaire au moins deux fois plus souvent que les autres, et au moins une fois sur dix. Étape avant le merge : la prise en charge, la relecture ou le merge prend en moyenne la moitié ou plus du temps des PR relues jusqu’à leur merge, quand celles-ci mettent une demi-journée ouvrée ou plus à être mergées. La mise en prod, qui suit le calendrier de déploiement de chaque dépôt, n’y compte pas. Relecteur : une seule personne de l’équipe intervient sur 60 % ou plus des PR relues d’un dépôt. Dépôts sans review : la moitié ou plus des PR mergées d’un dépôt l’ont été sans review. Workflows : un sur cinq ou plus de leurs exécutions échoue, ou leur durée médiane atteint 10 minutes. Abandon : 10 % ou plus des PR de code fermées sans merge. Tendance : la seconde moitié de la période face à la première, sa dernière semaine à part (ses PR ne sont pas toutes relues ou mergées), sur au moins 50 PR mergées par moitié ; une médiane bouge quand elle varie de moitié, une part de 5 points et d’un tiers. Un constat est prioritaire quand il dépasse nettement son seuil.

Mises en production

PR de release mergées dans master ou main, y compris celles de release-please.

Hotfix

PR de code dont la branche commence par hotfix. Part de hotfix : rapportées à toutes les PR de code.

Mergées par leur auteur sans approbation

PR de code des dépôts front, back et mobile que leur auteur a mergées lui-même au cours des 30 derniers jours, quelle que soit la période choisie, sans approbation d’une autre personne avant le merge. Chacune dit ce qu’elle avait reçu à la place : aucune review, des commentaires ou une demande de changements.

Déploiement

PR mergée dans master ou main : release, hotfix ou merge direct, hors back-merges entre ces deux branches. Les déploiements GitHub ne sont pas utilisés.

Indicateurs DORA

Une PR mergée dans develop arrive en prod avec le déploiement suivant de son dépôt ; mergée dans une branche de projet, une fois cette branche mergée à son tour. Les correctifs sont les déploiements imprévus pour réparer la prod : hotfix et reverts. Leur part est le taux de reprise, ajouté par DORA en 2024 ; il remplace ici le taux d’échec des déploiements, que des hotfix fréquents rendent difficile à isoler. Le rétablissement est le délai des correctifs jusqu’à leur merge en prod.

Intégration continue

Exécutions GitHub Actions déclenchées par une PR ou un push, hors exécutions planifiées, manuelles et de Dependabot. Seules celles qui aboutissent à un verdict comptent : annulées et ignorées sont exclues. Elles sont regroupées par jour, et une période compte ses jours en entier. GitHub efface les exécutions au bout d’environ 13 mois : la CI ne remonte qu’aux exécutions que la synchro a déjà lues, et s’allonge avec le temps jusqu’à 36 mois. Une période qui commence avant compte la CI depuis sa première exécution gardée, et le bilan d’un mois plus ancien n’en a pas. Check rouge : au moins un check en échec sur le dernier commit de la PR, checks facultatifs compris (Sentry, CodeRabbit…).

Dependabot

PR de mise à jour de dépendances ouvertes par Dependabot, comptées à part des PR de code. Celles mergées dans master ou main comptent aussi comme déploiements.

Binôme

Un auteur et une personne qui intervient sur ses PR de code. Chaque PR ouverte sur la période compte une fois pour chaque relecteur distinct, quel que soit le nombre de reviews ou de commentaires, et quelle que soit la date de ces interventions. L’auteur ne compte jamais comme son propre relecteur.

Dépendance au relecteur principal

Part des PR relues d’un auteur sur lesquelles intervient son relecteur le plus fréquent. Proche de 100 % avec plusieurs PR, elle signale un binôme figé : le code de l’auteur n’est connu que d’une autre personne. Ces indicateurs servent à repérer des risques d’équipe, pas à classer des personnes.

Bus factor

Le plus petit nombre de personnes de l’équipe qui ont écrit à elles seules au moins la moitié des PR de code d’un dépôt sur la période. À 1, le dépôt repose sur une seule personne ; « Auteurs partis » : les personnes encore là en ont écrit moins de la moitié. Il ne dit rien de la qualité du code, seulement du risque de le voir n’être connu de personne.

À débloquer

PR de code ouvertes, hors brouillons et PR des personnes parties, classées comme GitHub selon la dernière décision de chaque relecteur : des changements demandés par quelqu’un, sinon des code owners qui ne l’ont pas encore relue alors que GitHub ne la laisse pas merger, sinon autant d’approbations qu’il en faut pour merger, sinon moins, sinon des reviews ou commentaires sans décision, sinon rien. Une PR n’y apparaît qu’après un jour ouvré approuvée, bloquée par un code owner ou sans review, trois jours ouvrés avec des changements demandés ou en discussion, comptés depuis cette décision, l’ouverture ou le dernier échange. Sans aucune review ni commentaire depuis plus d’un mois, elle est rangée à part, parmi les oubliées.

Noms

Nom du profil GitHub, sinon identifiant.

Anciens collaborateurs

Une personne sans aucune PR, review, commentaire ni merge depuis un mois est considérée comme partie : plus de ligne, de carte ni de place dans les listes et la matrice à son nom, seulement une mention dans la partie « Anciens collaborateurs » de la page Équipe et parmi les champions de chaque mois du Palmarès. Ses PR restent comptées dans les totaux, les graphiques et les dépôts. Dans les dépôts portés par une seule personne, celle qui en a écrit le plus reste nommée même partie, marquée « hors équipe » : son code est toujours là. Le bus factor ne compte que l’équipe actuelle.