PRolice
v0.0.1 -
ooooooooo. ooooooooo. oooo o8o
`888 `Y88. `888 `Y88. `888 `"'
888 .d88' 888 .d88' .ooooo. 888 oooo .ooooo. .ooooo.
888ooo88P' 888ooo88P' d88' `88b 888 `888 d88' `"Y8 d88' `88b
888 888`88b. 888 888 888 888 888 888ooo888
888 888 `88b. 888 888 888 888 888 .o8 888 .o
o888o o888o o888o `Y8bod8P' o888o o888o `Y8bod8P' `Y8bod8P'
------------ What you gonna do when they come for you -------------
Prolice (Kontraktion der PR-Polizei ) ist ein Ingenieurmanagement-Tool zum Schrott und Messen von Pull-Request-Daten aus Github-Repositories.
Sourcelevel und ihren hervorragenden Blogpost über Metriken (die meisten von dieser Anwendung) rufen:
Viele Ingenieurmanager fördern Pull -Anfragen als Teil des Entwicklungsworkflows. Es ist eine konsolidierte Praxis, die viele Vorteile bringt. Es besteht darin, die Änderungen eines Zweigs mit dem Basiszweig des Repositorys (herkömmlichem Master genannt) zu vergleichen.
Pull -Anfragen bieten nützliche und umsetzbare Metriken. Nach den falschen Metriken verursacht jedoch Verzerrungen und bringen mehr Nachteile als Vorteile. Manager können Metriken mit Pull -Anfragen verwenden, um die Teamdynamik zu verstehen und angemessen zu handeln, um Verhaltensweisen zu korrigieren, bevor die Dinge nicht im Kurs kommen.
Prolice zielt darauf ab, eine Stichprobe von Pull -Anfragen von einem Ziel -Repository zu sammeln und sie zu analysieren, um im Laufe der Zeit Einblick in den Workflow des kollektiven Projekts zu erhalten.
Rufen Sie erneut zu Sourcelevels Blogpost (lesen Sie es ernsthaft, wenn Sie es noch nicht getan haben):
Bevor ich in die Metriken eingehe, möchte ich einen Haftungsausschluss machen: Verwenden Sie diese Nummern nicht, um Einzelpersonen zu vergleichen .
Manchmal erfordert ein schwer zu findender Fehler eine einzelne Codezeile, und diese einzelne Zeile dauerte eine Woche Arbeit. Ich habe es in meiner Karriere oft gesehen.
Ich habe auch Zeuge von Ingenieurmanagern miterlebt, die Entwickler dazu ermutigten, Pull -Anfragen mit zu vielen Änderungen zu eröffnen, dass es unpraktisch war, es zu überprüfen. Sie verstärken normalerweise, dass diese Entwickler produktiv sagen, dass sie den harten Job machen, wenn andere die einfachsten annehmen.
Die Messung von Personen durch Zuganfragen kann sogar unfair sein. Ein Entwickler, der sich der Aufrechterhaltung einer Legacy -Codebasis widmet, ist in der Regel langsamer als ein anderer, der in einem Greenfield -Projekt arbeitet.
Deshalb ist das Messen von Pull -Anfragen schwierig. Engineering Manager können keine Pull -Anforderungsdaten für Assses Einzelpersonen verwenden. Wenn Sie Anfragen ziehen, möchten Sie, dass Ihr Team zusammenarbeitet. In dieser Praxis ist die Zusammenarbeit der Kernwert. Die Bemühungen der Entwickler können nicht nur daran gemessen werden, wie viele Zuganfragen offen oder verschmolzen sind. Sogar das Schlimmste ist, dass sich die Anstrengung nicht auf seine Größe darstellt.
Das Wichtigste zuerst müssen Sie ein persönliches Zugriffs -Token erstellen. Dies ist eine einmalige Anforderung und sollte nicht länger als ein paar Minuten dauern.
Das Token muss einen Lesezugriff auf Repositorys haben und Anfragen ziehen, damit Prolice funktioniert. So etwas:
Mit Ihrem persönlichen Zugangs -Token und nach dem Herunterladen einer Binärdatei aus dem Abschnitt der Veröffentlichungen werden Prolice in Ihr bevorzugter Terminal Ihrer Wahl eingerichtet - derzeit werden Linux und MacOS (Darwin) unterstützt:
prolice --owner < owner > --repository < repository > --github-token < github-token >Wenn wir beispielsweise die offiziellen Repository -Metriken von Rust messen wollten ( Hinweis : Dies ist standardmäßig eine Probe von 100 PRs):
prolice --owner rust-lang --repository rust --github-token < github-token >Einzelne PR -Metriken werden ebenfalls unterstützt:
prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token > Prolics hat einige Flags und optionale Parameter, mit denen die Ausführlichkeit und die Probengröße angepasst werden können:
prolice --helpUSAGE:
prolice [FLAGS] [OPTIONS] --owner < owner > --repository < repository > --sample-size < sample-size > --github-token < github-token >
FLAGS:
-h, --help Prints help information
-m, --include-merge-prs Marks merge-PRs as valid targets for analysis (by default these are
excluded). Valid only for whole Repository analysis ; for individual
PR analysis this flag is ignored
-l, --print-legends Prints the metrics ' legends before sending the operation results to
stdout.
-s, --silent-mode Marks the operation as silent, which turns off all logging and
printing to stdout, with the sole exception of the analysis results.
This makes it useful for piping just the results, without the added
' noise ' . (NOTE: piping is automatically detected, which activates
silent-mode without having to explicitly add the flag to the command)
-V, --version Prints version information
OPTIONS:
-G, --github-token <github-token>
Sets the personal access token under which to perform the PR analysis
-L, --log-level <log-level>
Overrides the logging verbosity for the whole application [default: INFO] [possible
values: INFO, DEBUG, TRACE, WARN, ERROR, OFF]
-O, --owner <owner> The owner of the repository under scrutiny
-P, --pr-number <pr-number>
A specific pull-request to be selected as target for the analysis.
-R, --repository <repository> The repository under scrutiny
-S, --sample-size <sample-size>
The amount of PRs that will be fetched as sample for the analysis (unless a specific PR
number is selected as individual target) [default: 100]Die Ergebnisse von Prolic können in eine Datei geleitet werden. Die Rohrleitungen (oder das Fehlen eines TTY) werden von der Anwendung automatisch erkannt, wodurch alle Protokolle und Nachrichten ausgeschaltet werden, auch wenn der Benutzer diese Flags nicht als Teil des Befehls liefert. Dies ist nützlich, um rohe Ergebnisse zu erzielen, die möglicherweise in einen anderen Prozess eingespeist werden.
Zum Beispiel:
prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json Erstellt eine results.json -Datei mit den folgenden Inhalten (zum Zeitpunkt des Schreibens dieses Readme):
{
"score" : [
{
"AmountOfParticipants" : 4
},
{
"AmountOfReviewers" : 1
},
{
"Attachments" : 1
},
{
"AuthorCommentaryToChangesRatio" : 31.138690476190472
},
{
"PullRequestsDiscussionSize" : 4065
},
{
"PullRequestFlowRatio" : 1.9121686296350902
},
{
"PullRequestLeadTime" : 1
},
{
"PullRequestSize" : 255
},
{
"TestToCodeRatio" : 0.42988095238095236
},
{
"TimeToMerge" : 4
}
]
} Was jede Metrik "bedeutet" (auch bekannt als warum es wertvoll ist, zu messen) kann als Teil der Analyseergebnisse gedruckt werden, indem die Flagge --print-legends bestanden wird. Dennoch kann das das Terminal mit übermäßiger Ausführlichkeit verschmutzen; Als Referenz sind dies die Bedeutung der einzelnen Metrik:
AmountOfParticipantsDie Anzahl der nicht authorischen Personen, die an einer PR-Diskussion teilnehmen. Eine größere Teilnahme kann die Diskussion bereichern und Code von höherer Qualität erzeugen.
AmountOfReviewersDie Anzahl der nicht authorierenden Personen, die sich nach dem Ergebnis eines PR stellten, entweder durch Genehmigung oder Anfragen von Änderungen. Dies misst die Anzahl der Teilnehmer, die sich effektiv für das Schicksal eines PR entscheiden.
AttachmentsAnhänge können alles sein, von zusätzlichen Screenshots bis hin zu eingebetteten PDF -Dateien. Besonders nützlich für diejenigen PRs, die eine visuelle Komponente haben.
AuthorCommentaryToChangesRatioGuter Code sollte selbsterklärend sein; Eine gute PR kann aber auch zusätzliche Kommentare dazu beinhalten, was es erreichen soll, wie es es tut und/oder warum es es auf die gewählte Art und Weise macht.
Ein schlanker Kommentar kann für eine mehrdeutige PR führen, die die Last des Verständnisses auf den Rezensenten verlagert und zusätzliche Zeit davon verbraucht. Andererseits können zu viele Kommentare einen PR mit nicht benötigten Lärm zum gleichen Effekt verschmutzen.
PullRequestsDiscussionSizeÄhnlich wie das Verhältnis von Autoren Kommentar zu Änderungen misst es die Gesamtmenge der Kommentare in einer PR, jedoch unabhängig davon, von wem sie kommen. Im Gegensatz zu Social -Media -Posts führt zu viel Engagement für Pull -Anfragen zu Ineffizienz. Durch die Messung der Anzahl der Kommentare und Reaktionen für jede Pull -Anfrage eine Vorstellung davon, wie das Team zusammenarbeitet. Die Zusammenarbeit ist großartig und ihre Bestätigung ist etwas zu wünschen erwünscht. Nach einem bestimmten Niveau verlangsamen die Diskussionen jedoch die Entwicklung.
Diskussionen, die zu groß werden, sind möglicherweise auf etwas falsches Hinweis: Vielleicht ist das Team nicht ausgerichtet, oder die Softwareanforderungen sind nicht genau genug. In jedem Fall sind Fehlausrichtung in Diskussionen keine Zusammenarbeit. Sie sind Zeitverschwendung. In dem umgekehrten Szenario ist das Einbindung von fast kein Null die Codeüberprüfung nicht Teil der Gewohnheiten des Teams.
Zusammenfassend muss diese Metrik basierend auf der Größe und Verteilung des Teams eine "ideale Zahl" erreichen. Es kann nicht zu viel sein und es kann auch nicht zu wenig sein.
PullRequestFlowRatioDas Pull -Request -Fluss -Verhältnis ist die Summe der geöffneten Zuganfragen an einem Tag geteilt durch die Summe der geschlossenen Pull -Anfragen am selben Tag. Diese Metrik zeigt, ob das Team in einem gesunden Verhältnis arbeitet. Das Zusammenführen von Pull -Anfragen und die Bereitstellung für die Produktion ist eine gute Sache, denn es bietet dem endgültigen Benutzer einen Mehrwert. Wenn das Team jedoch mehr Zuganfragen als geöffnet schließt, verhungert die Pull -Anfrage -Warteschlange, was bedeutet, dass die Lieferung möglicherweise eine Pause eingeht. Im Idealfall ist es am besten, sicherzustellen, dass das Team Anfragen in einem Verhältnis, das so nah wie sie geöffnet sind, zusammenfasst. desto näher an 1: 1, desto besser.
PullRequestLeadTimeDie Vorlaufmetrik gibt eine Vorstellung davon, wie oft (normalerweise in Tagen) Anfragen zur verschmolzen oder geschlossenen Anfragen dauert. Um diese Nummer zu finden, ist das Datum und die Uhrzeit für jede Pull -Anfrage beim Öffnen und Fusionen erforderlich. Die Formel ist einfach: Ein einfacher Durchschnitt für die Differenz der Daten. Die Berechnung dieser Metrik über alle Repositories in einer Organisation kann einem Team eine klarere Vorstellung von ihrer Dynamik geben.
PullRequestSizeEine große Anzahl von Änderungen pro PR belastet dem Rezensenten, der seine Liebe zum Detail sieht, die größeren ein ChangeLog erhöht. Ironischerweise fusionieren Entwickler dazu, längere Zuganfragen schneller zu verschmelzen als kürzere, da es schwieriger ist, gründliche Bewertungen durchzuführen, wenn zu viele Dinge vor sich gehen. Unabhängig davon, wie gründlich die Bewertungen sind, führen große PRs zur Zeit, sich zu verschmelzen, und die Qualität.
TestToCodeRatioAls Faustregel sollte mindestens die Hälfte eines PR aus Tests bestehen, wann immer möglich.
TimeToMergeIm Allgemeinen sind Pull -Anfragen mit einigen laufenden Arbeiten geöffnet, was bedeutet, dass die Messung der Vorlaufzeit von Pull Request nicht die ganze Geschichte erzählt. Zeit zu verschmelzen ist, wie viel Zeit es braucht, um den ersten Einsatz eines Zweigs zu erreichen, um den Zielzweig zu erreichen. In der Praxis ist die Mathematik einfach: Es ist der Zeitstempel des ältesten Ausschusses eines Zweigs abzüglich des Zeitstempels des Merge -Commits.
Die Zeit zum Zusammenführen ist normalerweise nützlich im Vergleich zur Vorlaufzeit der Pull -Anfrage. Nehmen Sie das folgende Beispiel:
- Anforderungsvorlaufzeit = 3 Tage
- Zeit zu verschmelzen = 15 Tage
Im obigen Szenario dauerte eine durchschnittliche Anfrage von 3 Tagen, um zusammengeführt zu werden (was ziemlich gut ist). Aber die Zeit zum Zusammenführen betrug 15 Tage. Dies bedeutet, dass die Entwickler durchschnittlich 12 Tage (15 - 3) bearbeitet haben, bevor die Anfrage geöffnet wurde.
HINWEIS: Diese Metrik wird etwas veraltet, wenn Entwickler an WIP -Zweigen arbeiten, bevor sie alle Änderungen in ein einzelnes Komitee drücken, das später als Basis für die PR verwendet wird (dies würde sich die Zeit nutzen, um die Vorlaufzeit der Pull -Anforderung effektiv zu verschmelzen). Die Metrik bleibt jedoch immer noch unglaublich nützlich für Merge PRS (z. B. Merge entwickeln sich zum Meister): Said PRS hätte eine sehr kurze Vorlaufzeit (sie erhalten keine gründliche Wiederholungen), aber das Messen gegen das erste Ausschussesdatum (Zeit, um zusammen zu sein), wie lange es dauert, um in einen Meilenstein zu sein, das sich ausreichend in den Bigg-Zweigen ansammelt, um in einen der "großen" Zweige zu gelangen.
cargo zusammenstellen Prolice ist in Rost geschrieben. Das Kompilieren der Anwendung zur Verwendung auf der Host-Plattform ist so einfach wie die Verwendung eines einfachen cargo build :
cargo build --releasecargo-make (Linux zu macOS)Beginnen wir diesen Abschnitt zuerst mit einem kleinen Vorwort aus diesem fantastischen Blogpost:
Ich hasse Cross Compiling
Es gibt Millionen von Möglichkeiten, um das Betriebssystem zu ruinieren, an dem Sie arbeiten, und Cross Compiling ist einer davon. Normalerweise beginnt es mit der unschuldigen Idee, diese eine Build -Kette in Gang zu bringen.
Wenn Sie mit Ihnen herumgraben, finden Sie in einem Github -Projekt mehrere verschiedene Snippets auf Reddit oder ein Problem, bei dem eine zufällige Person ein paar Bash -Zeilen gepostet hat, die wie fehlende Informationen aussehen, die Sie benötigten.
Das Ausführen der Bash kann dann eines der folgenden Dinge verursachen:
- Erstellen Sie eine Working Build -Kette (sehr unwahrscheinlich)
- Erstellen Sie eine Build -Kette, die nach 80% Ihres Builds fehlschlägt
- Fügen Sie einen lokalen Bitcoin -Bergmann hinzu, während Sie vorgeben, tatsächlich eine Working Build -Kette zu erstellen
Nachdem diese Schmerzen auf persönlicher Ebene empfunden wurden, wurde die Cross-Compilation durch die in der Cargo-MakeFile cargo-makefile.toml in diesem Projekt definierten Ziele auf relativ schmerzfreier Ebene zur Verfügung gestellt.
Wenn es immer die erste cargo build ist, ist es immer die erste Wahl. Angenommen, das Ziel bestand darin, von Linux zu MacOS (Darwin) von Grund auf neu zu kompilieren. Zusätzlich zu der normalen Rost-Toolchain müssten Sie cargo-make als Folgendes installieren:
cargo install --force cargo-makeAnschließend werden die Kompilierungsschritte durch Aufrufen vollständig für Sie gepflegt:
cargo make --makefile cargo-makefile.toml release-darwinDies würde nach Abschluss des Prozesses die komprimierte Binärdatei erzeugen und platzieren.
<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip
Berücksichtigen Sie jedoch, dass Cross-Compilation-Linux-zu-Darwin-Docker Docker benötigt. Sie können sich also erneut einige MBs sparen, indem Sie sich an Binärdateien für Ihre Host-Maschine festhalten, indem Sie nur einen einfachen alten cargo build anrufen.
