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 -------------
A prolice (contração da polícia de relações públicas ) é uma ferramenta de gerenciamento de engenharia para descartar e medir dados de solicitação de puxar dos repositórios do GitHub.
Gritando para o Sourcelevel e seu excelente post sobre métricas (a maioria são implementadas por este aplicativo):
Muitos gerentes de engenharia promovem solicitações de tração como parte do fluxo de trabalho de desenvolvimento. É uma prática consolidada que traz muitos benefícios. Consiste em comparar as alterações de um ramo com o ramo base do repositório (convencionalmente chamado de mestre).
As solicitações de tração fornecem métricas úteis e acionáveis. No entanto, seguir as métricas erradas, causam distorções e trazem mais desvantagens do que benefícios. Os gerentes podem usar as métricas de solicitações de puxar para entender a dinâmica da equipe e agir adequadamente para corrigir comportamentos antes que as coisas saiam do caminho.
A Prolice pretende coletar uma amostra de solicitações de tração de um repositório de destino e analisá -las, com o objetivo de trazer informações sobre o fluxo de trabalho do projeto coletivo ao longo do tempo.
Mais uma vez, gritando para o pós do blog de Sourcelevel (seriamente, leia se ainda não o fez):
Antes de entrar nas métricas, quero fazer um aviso: não use esses números para comparar indivíduos .
Às vezes, um bug difícil de encontrar exige que uma única linha de código seja corrigida, e essa linha única levou uma semana de trabalho. Já testemunhei muitas vezes na minha carreira.
Também testemunhei gerentes de engenharia incentivando os desenvolvedores a abrir solicitações de tração com muitas mudanças que não era prática de revisar. Eles geralmente reforçam que, ao dizer a todos que esses desenvolvedores são produtivos, que estão fazendo o trabalho duro quando os outros estão levando os mais fáceis.
Medir indivíduos por meio de solicitações de tração pode até ser injusto. Um desenvolvedor dedicado a manter uma base de código herdado tende a ser mais lenta que outra, que funciona em um projeto Greenfield.
É por isso que medir solicitações de tração é complicado. Os gerentes de engenharia não podem usar dados de solicitação de puxar para avaliar os indivíduos. Se você retirar solicitações, deseja que sua equipe colabore. Nesta prática, a colaboração é o valor principal. O esforço dos desenvolvedores não pode ser medido apenas por quantas solicitações de tração estão abertas ou mescladas. Mesmo o pior, o esforço não representa seu tamanho.
Primeiro, você terá que criar um token de acesso pessoal. Este é um requisito único e não deve levar mais de alguns minutos.
O token precisará ter acesso a repositórios e solicitações para que a Prolice funcione. Algo assim:
Com seu token de acesso pessoal disponível e, tendo baixado um binário na seção de lançamentos, invocar prolice dentro do seu terminal de escolha favorito - atualmente Linux e MacOS (Darwin) são suportados:
prolice --owner < owner > --repository < repository > --github-token < github-token >Por exemplo, se quiséssemos medir as métricas oficiais de repositório da RUR ( Nota : isso padrão é uma amostra de 100 PRs):
prolice --owner rust-lang --repository rust --github-token < github-token >As métricas de relações públicas individuais também são suportadas:
prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token > A prolice tem algumas bandeiras e parâmetros opcionais que podem ser usados para ajustar sua verbosidade e tamanho de amostra:
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]Os resultados da prolice podem ser canalizados para um arquivo. A tubulação (ou qualquer ausência de um TTY) é detectada automaticamente pelo aplicativo, que desativará todos os logs e mensagens, mesmo que o usuário não forneça esses sinalizadores como parte do comando. Isso é útil para obter resultados brutos que podem ser alimentados em outro processo.
Por exemplo:
prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json produzirá um results.json arquivo com o seguinte conteúdo (no momento da redação deste 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
}
]
} O que cada métrica "significa" (também conhecida por que é valiosa de medir) pode ser impressa como parte dos resultados da análise, passando a --print-legends . Ainda assim, isso pode poluir o terminal com verbosidade excessiva; Portanto, para referência, estes são o significado de cada métrica:
AmountOfParticipantsA quantidade de pessoas que não são autorizadas participando da discussão de um PR. A participação maior pode enriquecer a discussão e produzir um código de maior qualidade.
AmountOfReviewersA quantidade de pessoas que não são de autores que se posicionaram no resultado de um PR, aprovando ou solicitando alterações. Isso mede a quantidade de participantes que decidem efetivamente sobre o destino de um PR.
AttachmentsOs anexos podem ser qualquer coisa que varia de capturas de tela adicionadas a arquivos PDF incorporados. Particularmente útil para os PRs que possuem um componente visual associado a ele.
AuthorCommentaryToChangesRatioUm bom código deve ser auto-explicativo; Mas um bom PR também pode incluir comentários extras sobre o que pretende alcançar, como faz e/ou por que faz da maneira escolhida.
Um comentário pequeno pode ser um RP ambíguo, mudando o ônus do entendimento para o revisor e consumindo tempo extra. Por outro lado, muitos comentários podem poluir um PR com ruído desnecessário, com o mesmo efeito.
PullRequestsDiscussionSizeSemelhante ao comentário do autor para a proporção de alterações, ele mede a quantidade total de comentários em um PR, mas independentemente de quem eles vêm. Pelo contrário às postagens das mídias sociais, muito envolvimento nas solicitações de tração leva à ineficiência. Medir o número de comentários e reações para cada solicitação de tração fornece uma idéia de como a equipe colabora. A colaboração é ótima e seu endosso é algo a desejar. No entanto, após um certo nível, as discussões diminuem o desenvolvimento.
As discussões que ficam muito grandes podem ser indicativas de algo errado: talvez a equipe não esteja alinhada ou talvez os requisitos de software não sejam precisos o suficiente. De qualquer forma, o desalinhamento nas discussões não é colaboração; Eles são uma perda de tempo. No cenário oposto, ter quase zero de engajamento significa que a revisão do código não faz parte dos hábitos da equipe.
Em resumo, essa métrica deve atingir um 'número ideal' com base no tamanho e distribuição da equipe. Não pode ser muito, e também não pode ser muito pouco.
PullRequestFlowRatioA taxa de fluxo de solicitação de tração é a soma das solicitações de tração aberta em um dia dividido pela soma das solicitações de tração fechada no mesmo dia. Essa métrica mostra se a equipe trabalha em uma proporção saudável. A mesclagem de solicitações de tração e a implantação da produção é uma coisa boa, pois agrega valor ao usuário final. No entanto, quando a equipe fecha mais solicitações de tração do que as aberturas, logo a fila de solicitação de tração passa a fome, o que significa que pode haver um hiato na entrega. Idealmente, é melhor garantir que a equipe funcione solicitações de puxar em uma proporção o mais próximo possível; Quanto mais perto de 1: 1, melhor.
PullRequestLeadTimeA métrica de entrega dá uma idéia de quantas vezes (geralmente em dias) solicita solicitações de tração para serem mescladas ou fechadas. Para encontrar esse número, é necessária a data e a hora para cada solicitação de tração, quando abertas e depois mescladas. A fórmula é fácil: uma média simples para a diferença de datas. Cálculo dessa métrica em todos os repositórios em uma organização pode dar a uma equipe uma idéia mais clara de sua dinâmica.
PullRequestSizeUma grande quantidade de mudanças por relações públicas impõe uma tensão no revisor, que vê sua atenção aos detalhes diminuiu o maior que um changelog aumenta. Ironicamente, os desenvolvedores tendem a mesclar solicitações de puxar mais rápidas que as mais curtas, pois é mais difícil realizar críticas completas quando há muitas coisas acontecendo. Independentemente de quão completas as críticas sejam, os grandes PRs levam ao tempo para se fundir e a qualidade que está diminuindo.
TestToCodeRatioComo regra geral, pelo menos metade de um PR deve ser composta por testes sempre que possível.
TimeToMergeEm geral, as solicitações de tração estão abertas com algum trabalho em andamento, o que significa que a medição do tempo de entrega da solicitação de tração não conta a história toda. O tempo para se fundir é quanto tempo leva para a primeira confirmação de uma filial para atingir a filial de destino. Na prática, a matemática é simples: é o carimbo de data e hora do comando mais antigo de um ramo menos o carimbo de data e hora da confirmação da mesclagem.
O tempo de mesclar é geralmente útil enquanto comparado com o tempo de entrega da solicitação de tração. Veja o seguinte exemplo:
- Puxe o tempo de entrega da solicitação = 3 dias
- Hora de mesclar = 15 dias
No cenário acima, uma solicitação de tração levou um tempo médio de 3 dias para serem mesclados (o que é muito bom); Mas a hora de se fundir foi de 15 dias. O que significa que os desenvolvedores trabalharam em média 12 dias (15 - 3) antes de abrir uma solicitação de tração.
Nota: Esta métrica é tornada um pouco obsoleta se os desenvolvedores trabalharem em ramificações de WIP antes de esmagar todas as alterações em um único compromisso que é posteriormente usado como base para o PR (isso levaria tempo para mesclar efetivamente o tempo de lead de solicitação de tração). No entanto, a métrica ainda permanece incrivelmente útil para mesclar os PRs (por exemplo, mesclar se desenvolver no mestre): os PRs teriam um tempo de protagonista muito curto (eles não recebem re-revisões completas), mas medindo-se contra a data do primeiro compromisso (o tempo de mesclagem) informará o ramo de 'grandes recursos para se acumular em um marco, que vale a pena a fusão de um dos' grandes ''
cargo Prolice está escrito em ferrugem. Compilar o aplicativo para uso na plataforma host é tão fácil quanto usar cargo build antiga:
cargo build --releasecargo-make (Linux para macOS)Vamos iniciar esta seção primeiro com um pouco de prefácio deste incrível post do blog:
Eu odeio compilar cruzado
Existem milhões de maneiras de arruinar o sistema operacional em que você está trabalhando e a compilação cruzada é uma delas. Normalmente, começa com a idéia inocente de fazer com que uma cadeia de compilação seja necessária para que um pequeno programa seja executado em um Linksys WRT 1900 ACS (OpenWRT e ARMV7).
Cavando em volta, você encontra vários trechos diferentes no Reddit ou em algum problema em um projeto do GitHub, onde uma pessoa aleatória postou algumas linhas de festa que parecem exatamente a falta de informações necessárias.
Executar a festa pode causar uma das seguintes coisas:
- Crie uma cadeia de construção de trabalho (muito improvável)
- Crie uma cadeia de construção que falhe após 80% da sua construção
- Adicione um mineiro de bitcoin local enquanto finge criar uma cadeia de compilação de trabalho
Tendo sentido essas dores em nível pessoal, a compilação cruzada foi disponibilizada em um nível relativamente livre de dor pelos alvos definidos dentro cargo-makefile.toml de carga deste projeto.
Obviamente, se compilar apenas para a máquina host, ficar com cargo build antiga é sempre a primeira escolha. Mas supondo que o objetivo fosse compilar de Linux para MacOS (Darwin) do zero, além da cadeia de ferramentas de ferrugem normal, você precisaria instalar cargo-make como a seguinte:
cargo install --force cargo-makeDepois, as medidas de compilação são completamente cuidadas por você, invocando:
cargo make --makefile cargo-makefile.toml release-darwinIsso criaria e colocaria, depois que o processo terminar, o binário compactado em:
<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip
Leve em consideração , no entanto, que o Linux-to-Darwin requer o Docker, para que, mais uma vez, você pode se salvar vários MBs, mantendo-se em binários de construção da sua máquina hospedeira, apenas invocando cargo build antiga e simples.
