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 리포지토리에서 풀 요청 데이터를 폐기하고 측정하기위한 엔지니어링 관리 도구입니다.
Sourcelevel과 메트릭에 대한 우수한 블로그 포스트 (이 응용 프로그램에서 구현 된 대부분)에게 소리 쳤다.
많은 엔지니어링 관리자는 개발 워크 플로의 일부로 풀 요청을 홍보합니다. 많은 혜택을 제공하는 통합 연습입니다. 지점의 변경 사항을 리포지토리의 기본 브랜치 (기존 마스터라고 함)와 비교하는 것으로 구성됩니다.
풀 요청은 유용하고 실행 가능한 메트릭을 제공합니다. 그러나 잘못된 메트릭에 따라 왜곡이 발생하고 혜택보다 더 많은 단점을 가져옵니다. 관리자는 풀 요청 메트릭을 사용하여 팀 역학을 이해하고 일이 시작되기 전에 행동을 수정하기 위해 적절하게 행동 할 수 있습니다.
Prolice는 시간이 지남에 따라 집단 프로젝트의 워크 플로에 대한 통찰력을 가져 오는 목표로 대상 저장소에서 풀 요청 샘플을 수집하고 분석하는 것을 목표로합니다.
Sourcelevel의 블로그 포스트로 다시 소리 쳤다 (아직 읽지 않은 경우 진지하게 읽으십시오) :
메트릭에 들어가기 전에 면책 조항을 만들고 싶습니다. 이 숫자를 사용하여 개인을 비교하지 마십시오 .
때로는 찾기 어려운 버그는 단일 줄의 코드를 수정해야하며 해당 한 줄은 일주일의 작업이 필요했습니다. 나는 내 경력에서 그것을 여러 번 목격했다.
또한 엔지니어링 관리자가 개발자가 너무 많은 변경 사항으로 풀 요청을 열도록 격려하는 것을 목격했습니다. 그들은 일반적으로 모든 사람들 에게이 개발자들이 생산적이라고 말함으로써 다른 사람들이 가장 쉬운 일을 할 때 어려운 일을하고 있다고 강화합니다.
풀 요청을 통해 개인을 측정하는 것은 불공평 할 수도 있습니다. 레거시 코드베이스를 유지하는 데 전념하는 개발자는 Greenfield 프로젝트에서 작동하는 다른 것보다 느린 경향이 있습니다.
그렇기 때문에 풀 요청을 측정하는 것이 까다 롭습니다. 엔지니어링 관리자는 개인을 맞추기 위해 풀 요청 데이터를 사용할 수 없습니다. 요청을 가져 오면 팀이 협력하기를 원합니다. 이 관행에서 협업이 핵심 가치입니다. 개발자의 노력은 얼마나 많은 풀 요청이 열리거나 병합되었는지에 따라 측정 할 수 없습니다. 최악의 경우, 노력은 그 크기를 나타내지 않습니다.
먼저 먼저 개인 액세스 토큰을 만들어야합니다. 이것은 일회성 요구 사항이며 몇 분 이상 걸리지 않아야합니다.
토큰은 Prolice가 작동하기 위해 리포지토리에 대한 액세스를 읽고 요청을 가져와야합니다. 이와 같은 것 :
개인 액세스 토큰을 사용할 수 있고 릴리스 섹션에서 바이너리를 다운로드 한 후, 선호하는 선택 터미널 내부에서 Prolice를 호출하십시오. 현재 Linux 및 MacOS (Darwin)가 지원됩니다.
prolice --owner < owner > --repository < repository > --github-token < github-token >예를 들어 Rust의 공식 저장소 메트릭을 측정하려면 ( 참고 :이 기본값은 100 PRS 샘플) :
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의 토론에 참여하는 비 승인자의 금액. 더 큰 참여는 토론을 풍부하게하고 고품질 코드를 생산할 수 있습니다.
AmountOfReviewers변경을 승인하거나 요청함으로써 PR의 결과에 대한 입장을 취한 비 승인 사람들의 금액. 이것은 PR의 운명을 효과적으로 결정하는 참가자의 양을 측정합니다.
Attachments첨부 파일은 스크린 샷이 추가 된 것부터 임베디드 PDF 파일에 이르기까지 다양한 것일 수 있습니다. 시각적 구성 요소가 관련된 PR에 특히 유용합니다.
AuthorCommentaryToChangesRatio좋은 코드는 자기 설명이어야합니다. 그러나 좋은 PR에는 달성하고자하는 목표, 그것이 어떻게 수행하는지 및/또는 선택한 방식에 대한 추가 논평이 포함될 수 있습니다.
슬림 한 논평은 모호한 PR을 만들어서 이해의 부담을 검토 자에게 전환하고 그로부터 추가 시간을 소비 할 수 있습니다. 반면에, 너무 많은 의견은 불필요한 소음으로 PR을 동일한 효과로 오염시킬 수 있습니다.
PullRequestsDiscussionSize저자 논평 대 변경 비율과 마찬가지로 PR의 총 의견량을 측정하지만 누가 출신지에 관계없이. 소셜 미디어 게시물과는 반대로 풀 요청에 너무 많은 참여가 발생하면 비 효율성이 발생합니다. 각 풀 요청에 대한 의견 수와 반응을 측정하면 팀이 협력하는 방법에 대한 아이디어가 제공됩니다. 협력은 훌륭하고, 그 승인은 원하는 것입니다. 그러나 일정 수준 후에 토론은 발전이 느려집니다.
너무 커지는 토론은 무언가 잘못된 것을 나타낼 수 있습니다. 팀이 정렬되지 않았거나 소프트웨어 요구 사항이 충분히 정확하지 않을 수도 있습니다. 어쨌든, 토론에서 오정렬은 협력이 아닙니다. 그들은 시간 낭비입니다. 반대 시나리오에서는 거의 제로 참여가 없다는 것은 코드 검토가 팀의 습관의 일부가 아니라는 것을 의미합니다.
요약하면,이 메트릭은 팀의 규모와 분포에 따라 '이상적인 숫자'에 도달해야합니다. 너무 많을 수없고 너무 적을 수는 없습니다.
PullRequestFlowRatio풀 요청 흐름 비율은 같은 날에 폐쇄 풀 요청의 합으로 나뉘어 진 하루에 열린 풀 요청의 합입니다. 이 메트릭은 팀이 건강한 비율로 작동하는지 여부를 보여줍니다. 풀 요청을 병합하고 생산에 배포하는 것은 좋은 일입니다. 최종 사용자에게 가치가 추가되기 때문입니다. 그러나 팀이 열리는 것보다 더 많은 풀 요청을 닫으면 곧 풀 요청 대기열이 굶주림이므로 배송에 hiatus가있을 수 있습니다. 이상적으로는 팀이 풀 요청을 열기만큼 비율로 병합하는 것이 가장 좋습니다. 1 : 1에 가까울수록 좋습니다.
PullRequestLeadTime리드 타임 메트릭은 몇 번 (보통 며칠) 풀 요청이 병합되거나 닫히는 데 걸리는지에 대한 아이디어를 제공합니다. 이 숫자를 찾으려면 열린 다음 병합 된 각 풀 요청의 날짜와 시간이 필요합니다. 공식은 쉽습니다. 날짜 차이의 단순한 평균입니다. 조직의 모든 저장소 에서이 메트릭을 계산하면 팀에게 역학에 대한 명확한 아이디어를 제공 할 수 있습니다.
PullRequestSizePR 당 다수의 변화는 검토 자에게 부담을 부과하며, 세부 사항에 대한 관심은 Changelog가 얻을수록 더 큰 세부 사항을 감소시킨다. 아이러니하게도, 개발자는 더 긴 풀 요청을 짧은 것보다 더 빨리 병합하는 경향이 있습니다. 너무 많은 일이 진행되고있을 때 철저한 리뷰를 수행하기가 더 어렵 기 때문입니다. 리뷰가 얼마나 철저한 지에 관계없이, 큰 PRS는 병합 될 시간과 품질이 하락할 시간으로 이어집니다.
TestToCodeRatio경험상 PR의 절반 이상은 가능할 때마다 테스트로 구성되어야합니다.
TimeToMerge일반적으로 풀 요청은 일부 작업 진행 상황에서 열려 있습니다. 즉, 풀 요청 리드 타임을 측정하는 것이 전체 스토리를 알려주지 않습니다. 병합 할 시간은 지점의 첫 번째 커밋이 대상 지점에 도달하는 데 걸리는 시간입니다. 실제로, 수학은 간단합니다. 그것은 Merge 커밋의 타임 스탬프를 뺀 지점의 가장 오래된 커밋의 타임 스탬프입니다.
병합 시간은 일반적으로 풀 요청 리드 타임과 비교할 때 일반적으로 유용합니다. 다음 예를 들어보세요 :
- 요청 리드 타임 = 3 일을 당기십시오
- 합병 시간 = 15 일
위의 시나리오에서 풀 요청은 병합되는 데 평균 3 일이 걸렸습니다 (꽤 좋습니다). 그러나 합병 시간은 15 일이었습니다. 이는 개발자가 풀 요청을 열기 전에 평균 12 일 (15 - 3)을 근무했음을 의미합니다.
참고 : 이 메트릭은 개발자가 WIP 지점에서 작업하면 모든 변경 사항을 단일 커밋으로 스쿼시하기 전에 나중에 PR의 기본으로 사용되는 단일 커밋으로 작업하면 다소 쓸모 없게됩니다 (이를 통해 풀 요청 리드 타임과 효과적으로 병합 할 시간이됩니다). 그러나 메트릭은 여전히 합병 PRS (예 : Merge 개발 마스터로 개발)에 여전히 유용하게 유용하게 남아 있습니다.
cargo 사용하여 prolice를 컴파일합니다 Prolice 는 Rust로 작성되었습니다. 호스트 플랫폼에서 사용 애플리케이션을 컴파일하는 것은 평범한 오래된 cargo build 사용하는 것만 큼 쉽습니다.
cargo build --releasecargo-make (Linux to MacOS)를 사용하여 크로스 컴파일 Prolice이 멋진 블로그 포스트의 작은 서문 으로이 섹션을 먼저 시작하겠습니다.
나는 크로스 컴파일이 싫어
작업중 인 운영 체제를 망치는 방법에는 수백만 가지가 있으며 크로스 컴파일은 그 중 하나입니다. 일반적으로 Linksys WRT 1900 ACS (OpenWrt and Armv7)에서 실행되는 작은 프로그램이 필요한 하나의 빌드 체인을 얻는 무고한 아이디어로 시작합니다.
당신 주위를 파는 것은 Reddit에서 몇 가지 다른 스 니펫이나 Github 프로젝트에서 몇 가지 다른 스 니펫을 발견했습니다. 여기서 임의의 사람은 필요한 정보가 누락 된 비트처럼 보이는 몇 줄의 bash를 게시했습니다.
배쉬를 실행 한 다음 다음 중 하나를 유발할 수 있습니다.
- 작업 빌드 체인 만들기 (매우 가능성이 낮음)
- 빌드의 80% 후에 실패한 빌드 체인 생성
- 실제로 작업 빌드 체인을 만드는 척하면서 로컬 비트 코인 광부 추가
이러한 고통을 개인적 차원에서 느끼면서, 교차 컴파일은이 프로젝트의화물 메이크 파일 cargo-makefile.toml 내부에 정의 된 목표에 의해 비교적 통증이없는 수준에서 이용할 수있게되었습니다.
물론, 호스트 머신에만 컴파일하는 경우 일반적인 cargo build 고수하는 것이 항상 첫 번째 선택입니다. 그러나 목표가 Linux에서 MacOS (Darwin)로 컴파일하는 것이 정상적인 녹 도구 체인 외에도 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를 절약 할 수 있습니다.
