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 （ PR Policeの収縮）は、GitHubリポジトリからのプル要求データを廃棄および測定するためのエンジニアリング管理ツールです。
SourceleEvelとメトリックに関する優れたブログ投稿に叫ぶ（そのほとんどがこのアプリケーションによって実装されている）：
多くのエンジニアリングマネージャーは、開発ワークフローの一部としてプルリクエストを促進します。それは多くの利点をもたらす統合された慣行です。ブランチの変更をリポジトリのベースブランチ（従来はマスターと呼ばれる）と比較することで構成されています。
プルリクエストは、便利で実用的なメトリックを提供します。ただし、間違ったメトリックに従って歪みを引き起こし、利益よりも多くの欠点をもたらします。マネージャーは、プル要求メトリックを使用してチームのダイナミクスを理解し、物事が軌道に乗る前に行動を修正するために適切に行動することができます。
Proliceは、ターゲットリクエストのサンプルをターゲットリポジトリから収集し、それらを分析することを目的としています。
再びSourcelevelのブログポストに叫びます（真剣に、まだお読みになっていない場合は読んでください）：
メトリックに入る前に、免責事項を作成したい：これらの数値を使用して個人を比較しないでください。
見つけにくいバグでは、単一のコードを修正する必要があり、その単一の行が1週間の作業を必要とする場合があります。私は自分のキャリアで何度もそれを目撃しました。
また、エンジニアリングマネージャーが開発者に、レビューするのが実用的ではないあまりにも多くの変更を伴うプルリクエストを開くことを奨励するのを目撃しました。彼らは通常、これらの開発者が生産的であることを全員に伝えることで、他の人が最も簡単な仕事をしているときに困難な仕事をしていることを強化します。
プルリクエストを介して個人を測定することは不公平な場合さえあります。レガシーコードベースの維持に専念する開発者は、グリーンフィールドプロジェクトで動作する別のコードベースよりも遅くなる傾向があります。
そのため、プルリクエストを測定するのは難しい理由です。エンジニアリングマネージャーは、プルリクエストデータを使用して個人を評価できません。リクエストをプルする場合は、チームにコラボレーションしたいです。このプラクティスでは、コラボレーションがコア値です。開発者の努力は、いくつのプルリクエストが開いているか統合されているかだけでは測定できません。最悪の場合でも、努力はそのサイズを表していません。
まず最初に、個人的なアクセストークンを作成する必要があります。これは1回限りの要件であり、数分以上かかるべきではありません。
トークンは、 Proliceが機能するために、リポジトリへの読み取りアクセスとリクエストをプルする必要があります。このようなもの：
個人的なアクセストークンを利用できるようになり、リリースのセクションからバイナリをダウンロードした場合、お気に入りのターミナル内にProliceを呼び出します - 現在LinuxとMacos（Darwin）がサポートされています。
prolice --owner < owner > --repository < repository > --github-token < github-token >たとえば、Rustの公式リポジトリメトリックを測定したい場合（注：これは、デフォルトで100 PRのサンプルになります）：
prolice --owner rust-lang --repository rust --github-token < github-token >個々のPRメトリックもサポートされています：
prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token > Proliceには、冗長性とサンプルサイズを調整するために使用できるいくつかのフラグとオプションのパラメーターがあります。
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]Proliceの結果はファイルにパイプできます。配管（またはTTYの不在）は、アプリケーションによって自動的に検出されます。これにより、ユーザーがこれらのフラグをコマンドの一部として提供しなかった場合でも、すべてのログとメッセージがオフになります。これは、別のプロセスに供給される可能性のある生の結果を得るのに役立ちます。
例えば：
prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json results.jsonファイルは、次の内容（この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
}
]
}各メトリックが「意味する」（別名、測定する価値がある理由）は--print-legendsフラグを渡すことにより、分析の結果の一部として印刷できます。それでも、それは端子を過度の冗長性で汚染する可能性があります。したがって、参照のために、これらはそれぞれメトリックの意味です。
AmountOfParticipantsPRの議論に参加している非著者の人々の量。より大きな参加は、議論を豊かにし、より高品質のコードを生み出すかもしれません。
AmountOfReviewersPRの結果を承認するか、変更を要求することにより、PRの結果に立ち向かった非著者の人々の量。これは、PRの運命を効果的に決定する参加者の量を測定します。
Attachments添付ファイルは、追加されたスクリーンショットから埋め込まれたPDFファイルに至るまでの範囲にあります。視覚的なコンポーネントが関連付けられているPRに特に便利です。
AuthorCommentaryToChangesRatio優れたコードは自明である必要があります。しかし、優れたPRには、それが何を達成することを目指しているか、それがどのようにそれを行うか、および/またはそれが選ばれた方法でそれを行う理由についての追加の解説も含めるかもしれません。
わずかな解説は、曖昧なPRになり、理解の負担をレビュアーに移し、そこから余分な時間を消費するかもしれません。一方、コメントが多すぎると、不要なノイズでPRを汚染する可能性があります。
PullRequestsDiscussionSize著者の解説の変更比と同様に、PRのコメントの合計量を測定しますが、誰から来たのかに関係なく。ソーシャルメディアの投稿とは対照的に、プルリクエストへの関与が多すぎると非効率性が発生します。各プルリクエストのコメントと反応の数を測定すると、チームがどのように協力するかについてのアイデアが得られます。コラボレーションは素晴らしいものであり、その支持は望まれるものです。ただし、特定のレベルの後、議論は開発を遅くします。
大きくなりすぎる議論は、何か間違ったことを示すかもしれません。おそらく、チームが調整されていないか、ソフトウェアの要件が十分に正確ではないかもしれません。いずれにせよ、議論の不整合はコラボレーションではありません。彼らは時間の無駄です。反対のシナリオでは、エンゲージメントがほとんどゼロであることは、コードレビューがチームの習慣の一部ではないことを意味します。
要約すると、このメトリックは、チームのサイズと分布に基づいて「理想的な数」に到達する必要があります。それはあまりにも多くのことはできませんし、それも少なすぎることはありません。
PullRequestFlowRatioプル要求フロー比は、同じ日の閉じたプルリクエストの合計で割った1日で開いたプル要求の合計です。このメトリックは、チームが健全な割合で動作するかどうかを示しています。プルリクエストをマージして生産に展開することは良いことです。最終ユーザーに価値が追加されるからです。ただし、チームが開くよりも多くのプルリクエストを閉じると、すぐにプルリクエストキューが飢えています。理想的には、チームが開くのと同じくらい近い比率でリクエストをプルすることを確認することをお勧めします。 1：1に近いほど良い。
PullRequestLeadTimeリードタイムメトリックは、プルリクエストがマージまたは閉じられるのに何回（通常は）プルリクエストがどれくらいかかるかを知ることができます。この番号を見つけるには、開いたときに各プル要求の日付と時刻が必要です。式は簡単です。日付の差の単純な平均です。組織内のすべてのリポジトリでこのメトリックを計算することで、チームにダイナミクスのより明確なアイデアを与えることができます。
PullRequestSizePRごとの大量の変更は、レビュアーに負担をかけます。レビュアーは、チェンジログが大きくなるほど細部に注意を向けると見ています。皮肉なことに、開発者は、より多くのレビューが行われている場合に徹底的なレビューを実行することがより困難であるため、より短いリクエストよりも長いプルのリクエストをマージする傾向があります。レビューがどれほど徹底的であるかに関係なく、大きなPRは、上昇する時間と品質が低下する時間につながります。
TestToCodeRatio経験則として、PRの少なくとも半分は、可能な限りテストで構成される必要があります。
TimeToMerge一般に、プルリクエストは開かれていますが、いくつかの作業が進行中です。つまり、プルリクエストのリードタイムを測定してもストーリー全体がわかりません。マージする時間は、ターゲットブランチに到達するのにブランチの最初のコミットにかかる時間です。実際には、数学は簡単です。それは、ブランチの最も古いコミットのタイムスタンプから、マージのコミットのタイムスタンプを差し引いています。
通常、マージする時間は有用ですが、プル要求のリードタイムと比較してください。次の例を挙げてください。
- リクエストのリードタイム= 3日
- マージする時間= 15日
上記のシナリオでは、プルリクエストの平均時間が3日間かかりました（これはかなり良い）。しかし、マージする時間は15日でした。つまり、開発者はプルリクエストを開く前に平均12日間（15〜3）働いたことを意味します。
注：開発者がWIPブランチで作業する前に、すべての変更をPRのベースとして後で使用する単一のコミットに押しつぶした場合、このメトリックはやや廃止されます（これにより、プルリクエストのリードタイムと効果的に融合する時間が得られます）。ただし、メトリックは依然としてMerge PRSに非常に有用なままです（たとえば、Merge Merge Developing to Master）：PRSは非常に短いプルリクエストのリードタイム（徹底的なリビューは取得されません）を持っていますが、最初のコミットの日付に対して測定することで（マージする時間）、マイルストーンに十分なマイルストーンに蓄積されるのにかかる時間がかかります。
cargoを使用してプロリスをコンパイルしますProliceは錆で書かれています。ホストプラットフォームで使用するアプリケーションをコンパイルすることは、普通のcargo buildを使用するのと同じくらい簡単です。
cargo build --releasecargo-makeを使用したクロスコンパイルプロリス（LinuxからmacOS）この素晴らしいブログポストのちょっとした序文で、このセクションを最初に開始しましょう：
私はクロスコンパイルが嫌いです
取り組んでいるオペレーティングシステムを台無しにする方法は何百万もあり、クロスコンパイルもその1つです。通常、Linksys WRT 1900 ACS（OpenWRTおよびARMV7）で実行するために小さなプログラムが必要な1つのビルドチェーンを導入するという無邪気なアイデアから始まります。
あなたの周りを掘ると、Redditでいくつかの異なるスニペットまたはGitHubプロジェクトでいくつかの問題があり、ランダムな人があなたが必要としていないもののように見えるいくつかのバッシュを投稿しました。
バッシュを実行すると、次のもののいずれかが発生する可能性があります。
- ワーキングビルドチェーンを作成する（非常にありそうもない）
- ビルドの80％後に失敗するビルドチェーンを作成します
- 実際にワーキングビルドチェーンを作成するふりをしながら、ローカルビットコインマイナーを追加します
これらの痛みを個人レベルで感じていたため、このプロジェクトのカーゴメイクファイルのcargo-makefile.toml内で定義されたターゲットによって、相互コンパイルが比較的痛みのないレベルで利用可能になりました。
もちろん、ホストマシンのみをコンパイルする場合は、普通のcargo buildに固執することが常に最初の選択です。しかし、目的は、LinuxからMacos（Darwin）にゼロからコンパイルすることであり、通常のRustツールチェーンに加えて、これとしてcargo-makeをインストールする必要があります。
cargo install --force cargo-makeその後、編集手順は、次のように呼び出すことで完全にあなたの世話をします。
cargo make --makefile cargo-makefile.toml release-darwinこれにより、プロセスが終了した後、圧縮されたバイナリが作成されて配置されます。
<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip
ただし、クロスコンパイルのLinux-to-DarwinにはDockerが必要であることを考慮に入れてください。したがって、再び、プレーンな古いcargo buildを呼び出すだけで、ホストマシンのバイナリの構築に固執することで、いくつかのMBを節約できます。
