Orbit
Orbit Build Insights et Delivery Insights
Orbit has two insight views: a per-project Build Insights tab that answers "why are our builds slow", and an account-wide Insights page that answers "how well are we shipping". This guide covers…
Orbit dispose de deux vues d'analyse : un onglet Build Insights par projet qui répond à « pourquoi nos builds sont-ils lents », et une page Insights au niveau du compte qui répond à « à quelle vitesse livrons-nous ». Ce guide couvre les deux et indique quand utiliser laquelle.
Où se trouvent les deux vues
Build Insights est par projet. Ouvrez Orbit, cliquez sur le projet, et choisissez Build Insights sous le groupe Observability dans la bande d'onglets du projet.
Insights est au niveau du compte. Ouvrez Orbit et choisissez Insights dans la navigation de niveau supérieur, à côté de Mission control et Usage.
Build Insights : Les cartes de synthèse
L'onglet se décrit comme les percentiles de durée de build, le taux de réussite du cache, le taux de réussite et la tendance sur votre fenêtre sélectionnée, et la fenêtre est ajustable en haut de la page.
| Carte | Ce qu'elle vous indique |
|---|---|
| Total des builds | Combien de builds ont été exécutés, divisés en réussis et échoués |
| Taux de réussite | Noté Healthy, OK ou Needs attention |
| Build duration p50 | La médiane du build, avec p95 et p99 en dessous |
| Cache hit rate | Les accès réussis par rapport aux accès échoués |
| Cache savings | Le temps de calcul que le cache vous a épargné |
L'appairage du p50 avec p95 et p99 est le point clé. Un p50 de 90 secondes avec un p99 de 95 secondes est un build bien comporté. Un p50 de 90 secondes avec un p99 de onze minutes signifie que quelque chose va occasionnellement très mal, et la moyenne l'aurait complètement caché.
Si la fenêtre ne contient aucun build, la page l'indique et suggère de choisir une fenêtre plus grande si vos déploiements sont plus anciens.
Tendance du volume et de la durée des builds
Le graphique de tendance trace le nombre de builds quotidiens sur la fenêtre avec une superposition de durée moyenne. Survoler un jour affiche le nombre, la division réussis et échoués, et la moyenne.
Lisez les deux séries ensemble. Un volume en hausse avec une durée stable est une équipe saine qui livre davantage. Un volume stable avec une durée croissante est un build qui se détériore tranquillement, généralement en raison de la croissance des dépendances ou d'un cache qui a cessé de fonctionner.
Frameworks et gestionnaires de paquets
Deux ventilations se trouvent sous la tendance :
- By framework, regroupant les builds réussis selon le framework qu'Orbit a détecté.
- Package managers, sur tous les builds.
Sur un projet monoapp, celles-ci ne sont qu'une ligne chacune et ne sont pas très intéressantes. Sur un monorepo ou un compte avec plusieurs projets, c'est ainsi que vous repérez l'anomalie : une application utilisant un gestionnaire de paquets différent, ou un framework qui tire la moyenne vers le bas.
La détection du framework est également ce qui pilote les paramètres de build par défaut d'Orbit : voir Frameworks Orbit Supports.
Builds les plus lents
La table Slowest 10 successful builds liste vos plus mauvaises performances avec leur branche, durée et temps de file d'attente, décrits sur la page comme des candidats d'ancrage pour l'optimisation.
Notez la colonne Queued spécifiquement. Un build qui a pris huit minutes dont six ont été passées en file d'attente n'est pas un build lent, c'est un hôte de build occupé, et aucune optimisation de votre npm ci n'y aidera. Un build qui a pris huit minutes sans temps de file d'attente est véritablement lent et vaut la peine d'être attaqué.
Attaquez d'abord la phase d'installation du build le plus lent, puis sa phase de build. L'installation est l'endroit où un cache chaud paie, et c'est généralement la victoire la plus facile. Configuring Your Build Command and Output Directory couvre les paramètres impliqués.
Économies du cache
L'onglet quantifie ce que le cache de build vous a épargné en temps de calcul sur la fenêtre. Ce nombre est l'argument pour maintenir le cache en bon état.
Si le taux de réussite du cache est faible, les causes habituelles sont :
- Un lockfile qui change à chaque commit, invalidant le cache à chaque fois.
- Des builds qui ont été effacés délibérément et n'ont pas encore réchauffé.
- De longs écarts entre les déploiements.
L'effacement du cache réinitialise ceci, ce qui vaut la peine de se souvenir avant de l'effacer par habitude lors du débogage.
Delivery Insights : Métriques DORA
La page Insights au niveau du compte couvre les 30 derniers jours sur tous les projets, et encadre les chiffres sous forme de métriques DORA avec une bande de performance de Elite, High, Medium ou Low, plus une comparaison avec les 30 jours précédents.
| Métrique | Définition sur la page |
|---|---|
| Deploy frequency | À quelle fréquence vous déployez, tous les environnements, tous les projets |
| Lead time (P50) | Commit en file d'attente jusqu'au déploiement, avec P95 à côté |
| Change failure rate | Les déploiements en production qui ont échoué |
| MTTR (médiane) | De l'échec au prochain succès en production |
Ces quatre sont volontairement en tension. Vous pouvez rendre le taux d'échec des changements parfait en déployant une fois par mois, et vous pouvez rendre la fréquence de déploiement excellente en livrant constamment et en cassant les choses. L'ensemble n'a de sens que lorsqu'il est lu ensemble, et la tendance par rapport aux 30 jours précédents compte plus que la bande absolue.
Ventilation par projet
Sous les métriques se trouve un tableau de chaque projet sur les mêmes 30 jours : déploiements, réussites, échecs et temps de build moyen.
C'est le moyen le plus rapide de trouver le projet qui traîne le compte : celui avec un taux de réussite faible, ou celui dont le build moyen est plusieurs fois celui de tous les autres. Ouvrez ensuite son onglet Build Insights pour plus de détails.
S'il n'y a aucune donnée du tout, la page l'indique et vous invite à pousser vers une branche pour commencer.
Quelle vue ouvrir
- Un build est lent. Build Insights, sur le projet. Regardez le p50 par rapport au p95, puis le temps d'attente en file d'attente, puis la table des builds les plus lents.
- Les builds échouent continuellement. Build Insights pour le taux, puis l'onglet Analytics avec la classification des causes d'échec pour la raison : voir Orbit Project Analytics.
- Quelqu'un demande comment l'équipe livre. Insights, au niveau du compte. Les quatre métriques DORA avec leurs flèches de tendance répondent directement à cette question.
- Vous choisissez ce sur quoi travailler ensuite. Insights d'abord pour trouver le projet, Build Insights ensuite pour trouver la cause.
Dépannage
La page est vide mais je sais que nous déployons. Élargissez la fenêtre. Build Insights par défaut sur une fenêtre plus courte que vous ne le penseriez peut-être, et la page au niveau du compte est fixée à 30 jours.
Le taux de réussite du cache est zéro. Soit le cache a été récemment effacé, soit votre plan n'inclut pas la mise en cache des builds. Voir Orbit Plan Limits.
Lead time semble énorme. Le lead time est mesuré du commit à la production, donc une branche longue qui a été fusionnée des semaines après son premier commit l'augmente. C'est une information réelle, pas un bug : c'est vous dire que le travail attend d'être fusionné.
MTTR est vide. Il n'y a pas eu d'échecs en production dans la fenêtre, il n'y a donc rien à récupérer. C'est le bon cas.
Où aller ensuite
- Orbit Project Analytics pour une image par projet plus complète.
- Troubleshooting Failed Builds une fois que vous savez quels builds échouent.
- Orbit Deployment Pipeline pour les portes qui se situent entre un commit et la production.