Orbit
Orbit Build Insights und 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 hat zwei Insight-Ansichten: eine projektspezifische Build Insights-Registerkarte, die die Frage "Warum sind unsere Builds langsam" beantwortet, und eine kontoweite Insights-Seite, die die Frage "Wie gut versenden wir" beantwortet. Diese Anleitung behandelt beide und wann welche Ansicht zu verwenden ist.
Wo sich die beiden Ansichten befinden
Build Insights ist projektspezifisch. Öffnen Sie Orbit, klicken Sie auf das Projekt und wählen Sie Build Insights unter der Gruppe Observability in der Projektregisterkarte.
Insights ist kontoweite. Öffnen Sie Orbit und wählen Sie Insights aus der obersten Navigation neben Mission control und Usage.
Build Insights: Die Zusammenfassungskarten
Die Registerkarte beschreibt sich selbst als Build-Dauer-Perzentile, Cache-Hit-Rate, Erfolgsquote und Trend über Ihr ausgewähltes Zeitfenster, und das Fenster ist oben auf der Seite anpassbar.
| Karte | Was sie Ihnen sagt |
|---|---|
| Gesamte Builds | Wie viele Builds ausgeführt wurden, unterteilt in erfolgreich und fehlgeschlagen |
| Erfolgsquote | Bewertet als Healthy, OK oder Needs attention |
| Build-Dauer p50 | Der mittlere Build mit p95 und p99 darunter |
| Cache-Hit-Rate | Treffer gegen Fehlschläge |
| Cache-Ersparnis | Rechenzeit, die der Cache Ihnen gespart hat |
Die Paarung von p50 mit p95 und p99 ist der Sinn. Ein p50 von 90 Sekunden mit einem p99 von 95 Sekunden ist ein gut funktionierender Build. Ein p50 von 90 Sekunden mit einem p99 von elf Minuten bedeutet, dass gelegentlich etwas sehr schief geht, und das Durchschnittsverfahren hätte dies vollständig verborgen.
Wenn das Fenster keine Builds enthält, teilt die Seite dies mit und schlägt vor, ein größeres Fenster zu wählen, wenn Ihre Deployments älter sind.
Build-Volumen und Dauer-Trend
Das Trend-Diagramm zeigt täglich Build-Zählungen über das Fenster hinweg mit einer durchschnittlichen Dauer-Überlagerung. Wenn Sie mit der Maus über einen Tag fahren, werden die Anzahl, die erfolgreich und fehlgeschlagen aufgesplittete Anzahl und der Durchschnitt angezeigt.
Lesen Sie die beiden Reihen zusammen. Volumen oben mit Dauer flach ist ein gesundes Team, das mehr versendet. Volumen flach mit Dauer kletternd ist ein Build, der leise verrottet, normalerweise durch Abhängigkeitswachstum oder einen Cache, der nicht mehr funktioniert.
Frameworks und Paketmanager
Zwei Aufschlüsselungen befinden sich unter dem Trend:
- Nach Framework, Gruppierung erfolgreicher Builds nach dem Framework, das Orbit erkannt hat.
- Paketmanager, über alle Builds hinweg.
Auf einem Single-App-Projekt sind diese jeweils eine Zeile und nicht besonders interessant. Auf einem Monorepo oder einem Konto mit mehreren Projekten ist dies, wie Sie den Ausreißer erkennen: eine App mit einem anderen Paketmanager oder ein Framework, das den Durchschnitt nach unten zieht.
Framework-Erkennung ist das, was auch Orbits Standard-Build-Einstellungen antreibt: siehe Frameworks Orbit Supports.
Langsamste Builds
Die Tabelle Slowest 10 successful builds listet Ihre schlechtesten Performer mit ihrem Branch, ihrer Dauer und Warteschlangen-Zeit auf, beschrieben auf der Seite als Kandidaten für Optimierungsversuche.
Beachten Sie insbesondere die Spalte Queued. Ein Build, der acht Minuten dauerte, von denen sechs in der Warteschlange verbracht wurden, ist kein langsamer Build, es ist ein beschäftigter Build-Host, und keine Menge an Optimierungen Ihres npm ci wird helfen. Ein Build, der acht Minuten dauerte, ohne Warteschlangen-Zeit, ist wirklich langsam und es lohnt sich, ihn anzugreifen.
Greifen Sie zuerst die Install-Phase des langsamsten Builds an, dann die Build-Phase. Install ist, wo sich ein warmer Cache auszahlt, und es ist normalerweise der einfachste Gewinn. Configuring Your Build Command and Output Directory behandelt die beteiligten Einstellungen.
Cache-Ersparnis
Die Registerkarte quantifiziert, was der Build-Cache Ihnen an Rechenzeit über das Fenster hinweg gespart hat. Diese Zahl ist das Argument dafür, den Cache in guter Form zu halten.
Wenn die Cache-Hit-Rate niedrig ist, sind die üblichen Ursachen:
- Eine Lockdatei, die bei jedem Commit geändert wird und den Cache jedes Mal invalidiert.
- Builds, die absichtlich gelöscht wurden und seitdem nicht aufgewärmt wurden.
- Lange Pausen zwischen Deployments.
Das Löschen des Cache setzt dies zurück, was wichtig ist, um sich zu merken, bevor Sie ihn aus Gewohnheit beim Debuggen leeren.
Delivery Insights: DORA-Metriken
Die kontoweite Insights-Seite behandelt die letzten 30 Tage über alle Projekte hinweg und rahmt die Zahlen als DORA-Metriken mit einem Leistungsband von Elite, High, Medium oder Low ein, plus einen Vergleich mit den vorherigen 30 Tagen.
| Metrik | Definition auf der Seite |
|---|---|
| Deploy-Häufigkeit | Wie oft Sie deployieren, alle Umgebungen, alle Projekte |
| Lead-Zeit (P50) | Commit in die Warteschlange gestellt bis deployed, mit P95 nebenan |
| Change-Fehlerquote | Production-Deployments, die fehlgeschlagen sind |
| MTTR (Median) | Fehler zum nächsten Production-Erfolg |
Diese vier sind absichtlich in Spannung. Sie können die Change-Fehlerquote perfekt aussehen lassen, indem Sie einmal im Monat deployieren, und Sie können die Deploy-Häufigkeit hervorragend aussehen lassen, indem Sie ständig versenden und Dinge zerstören. Die Menge ist nur sinnvoll zusammen gelesen, und der Trend gegen die vorherigen 30 Tage ist wichtiger als das absolute Band.
Projektaufschlüsselung
Unter den Metriken befindet sich eine Tabelle aller Projekte über die gleichen 30 Tage: Deployments, Erfolge, Fehler und durchschnittliche Build-Zeit.
Dies ist der schnellste Weg, um das Projekt zu finden, das das Konto nach unten zieht: das mit einer niedrigen Erfolgsquote oder das, dessen durchschnittlicher Build mehrmals so lange ist wie bei allen anderen. Öffnen Sie als nächstes seine Build Insights-Registerkarte, um die Details anzuzeigen.
Wenn es überhaupt keine Daten gibt, teilt die Seite dies mit und fordert Sie auf, zu einem Branch zu pushen, um zu beginnen.
Welche Ansicht zu öffnen
- Ein Build ist langsam. Build Insights auf dem Projekt. Schauen Sie sich p50 gegen p95 an, dann Warteschlangen-Wartezeit, dann die Tabelle der langsamsten Builds.
- Builds schlagen ständig fehl. Build Insights für die Rate, dann die Registerkarte Analytics des Fehlergrunds-Klassifizierung für den Grund: siehe Orbit Project Analytics.
- Jemand fragt, wie das Team bereitstellt. Insights, kontoweite. Die vier DORA-Metriken mit ihren Trend-Pfeilen beantworten diese Frage direkt.
- Sie wählen aus, was Sie als nächstes tun möchten. Insights zuerst, um das Projekt zu finden, Build Insights zweitens, um die Ursache zu finden.
Fehlerbehebung
Die Seite ist leer, aber ich weiß, dass wir deployieren. Verbreitern Sie das Fenster. Build Insights wird standardmäßig auf ein kürzeres Fenster als erwartet eingestellt, und die kontoweite Seite ist auf 30 Tage festgelegt.
Cache-Hit-Rate ist Null. Der Cache wurde entweder kürzlich gelöscht oder Ihr Plan enthält kein Build-Caching. Siehe Orbit Plan Limits.
Lead-Zeit sieht riesig aus. Lead-Zeit wird vom Commit bis live gemessen, daher inflationiert ein langlebiger Branch, der Wochen nach seinem ersten Commit zusammengefügt wurde, diesen. Das ist echte Information, kein Fehler: es teilt Ihnen mit, dass Arbeit unzusammengefügt herumliegt.
MTTR ist leer. Es gab keine Production-Fehler im Fenster, also gibt es nichts, von dem man sich erholen könnte. Das ist der gute Fall.
Wo geht es als nächstes hin
- Orbit Project Analytics für das umfassendere projektspezifische Bild.
- Troubleshooting Failed Builds sobald Sie wissen, welche Builds fehlschlagen.
- Orbit Deployment Pipeline für die Gates, die zwischen einem Commit und der Production liegen.