Trois minutes et quarante secondes. C’est la durée moyenne d’un build du pipeline principal de ce projet aujourd’hui, contre deux minutes et trente-cinq secondes six mois plus tôt. Personne, sur toute cette période, n’a remarqué la moindre alerte ni le moindre incident : chaque build individuel restait raisonnablement rapide, chaque augmentation d’une exécution à l’autre restait minime, souvent inférieure à quelques secondes. C’est justement ce qui rend ce type de dérive difficile à repérer sans un historique structuré : aucune régression brutale ne déclenche d’alerte, seulement une lente accumulation.
Ce constat, découvert presque par hasard, a motivé la mise en place d’un suivi systématique des temps de build, plutôt que de continuer à se fier à une impression subjective de plus en plus pénible mais jamais objectivée. L’optimisation du pipeline lui-même, une fois le ralentissement confirmé, ne fait pas l’objet de cet article.
Pourquoi une alerte ponctuelle ne suffit pas
Une alerte configurée pour se déclencher au-delà d’un seuil fixe, par exemple cinq minutes, aurait mis des mois supplémentaires à se déclencher, le temps que la dérive lente franchisse ce seuil arbitraire. Le problème réel n’était pas qu’un build dépasse un seuil donné, mais que la tendance générale progresse continuellement dans le mauvais sens, semaine après semaine, sans jamais redescendre. Seul un historique complet, consulté sous forme de graphique, permet de visualiser ce type de tendance progressive, invisible build par build mais évidente une fois mise bout à bout.
Consigner chaque durée de build
La plupart des plateformes d’intégration continue exposent la durée totale d’exécution d’un pipeline via leur propre interface, mais rarement sous une forme facilement exploitable sur plusieurs mois. Un script complémentaire a donc été ajouté en toute fin de chaque exécution du pipeline, chargé de consigner la durée totale mesurée dans un fichier JSON structuré, une ligne par exécution, accumulée dans le temps.
#!/usr/bin/env bash
set -euo pipefail
DUREE_SECONDES="$1"
DATE_ISO=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
echo "{\"date\":\"$DATE_ISO\",\"duree_secondes\":$DUREE_SECONDES}" \
>> ./historique-builds.jsonl
Ce fichier au format JSON Lines, une ligne par événement, s’accumule au fil des exécutions et reste versionné dans un dépôt séparé dédié aux métriques internes de l’équipe, distinct du code applicatif lui-même.
Transformer cet historique en graphique lisible
Un historique brut sous forme de fichier texte reste peu parlant sans mise en forme visuelle. Un petit script complémentaire lit l’ensemble des lignes accumulées, calcule une moyenne glissante sur sept jours pour lisser les variations ponctuelles d’une exécution à l’autre, puis produit un graphique consulté chaque semaine lors du point d’équipe technique.
- Une ligne par jour, moyenne des builds exécutés ce jour-là
- Une moyenne glissante sur sept jours pour dégager la tendance de fond
- Un seuil visuel d’alerte fixé arbitrairement, pour repérer une dérive rapide en plus de la dérive lente
C’est précisément ce graphique, consulté un mardi matin ordinaire, qui a révélé une progression continue depuis six mois, jusque-là masquée par la lenteur même de sa progression.
Ce que la mesure a révélé une fois analysée
Le temps de build moyen a progressé de quarante et un pour cent sur les six mois observés, une fois la mesure mise en place et l’historique reconstitué à partir des journaux d’exécution conservés par la plateforme de CI. Cette progression coïncidait presque exactement avec l’accumulation progressive de dépendances front supplémentaires ajoutées projet après projet, chacune ajoutant une fraction de seconde négligeable prise isolément, mais significative une fois cumulée sur plusieurs dizaines d’ajouts successifs.
En résumé
Un ralentissement qui progresse lentement échappe presque toujours à une vigilance ponctuelle, aussi attentive soit-elle, faute de point de comparaison fiable dans le temps. Consigner systématiquement chaque durée de build, même sous une forme aussi simple qu’un fichier texte structuré, suffit à rendre visible une tendance qu’aucune observation isolée n’aurait permis de détecter à temps.
