Freqüentemente, como parte da verificação de solicitação de recebimento, além da própria revisão de código, é necessário fazer um conjunto de verificações de rotina. Algumas verificações podem estar relacionadas ao design do PR. Outros - verifique as condições relacionadas que formam a base do processo de adoção de alterações.
Se as verificações de rotina não forem automatizadas, uma pessoa pode começar a esquecê-las ou contorná-las. Porque a rotina é chata.
O Visual Studio Team Services oferece uma infraestrutura bastante conveniente para lidar com solicitação de recebimento. Isso inclui políticas personalizadas de criação de mesclagem, nomeação de revisores, regras de mesclagem para alterações aceitas. Tudo isso é complementado por um sistema conveniente para discutir e comentar o código.
A ferramenta mais poderosa para estender o processo de solicitação de recebimento são as políticas de plug-in externo.
Falaremos sobre sua criação e uso (e veremos o código)
Status de solicitação de extração expansível
Os status de relações públicas são sinalizadores definidos dentro do contexto. Contexto - uma combinação única do nome do contexto e do "gênero". O gênero geralmente é um por aplicativo que manipula status.
Por exemplo:
Status 1: gênero = 'minha política', nome = 'verificação-1'
Status 2: gênero = 'minha política', nome = 'verificação 2'
O status assume um dos valores predefinidos. Com o objetivo de apoiar o processo, estaremos interessados em dois: bem-sucedidos e fracassados.
Os status podem ser usados ao configurar uma política de brunch: os sinalizadores selecionados devem ter um status bem-sucedido para que o PR seja aceito. Da mesma forma, são implementadas políticas internas que verificam o número de drivers, a presença de um ticket anexado etc.
Vá para editar a política de ramificação. Adicione política externa.
Se o status tiver sido definido pelo menos uma vez, ele estará disponível no menu suspenso.
Na parte inferior, você pode especificar um título para o status, como ele será exibido no bloco de conclusão da solicitação de recebimento.
Os status adicionados serão visíveis na página de solicitação de recebimento no bloco de verificação:
Se o status não for usado como uma política, seu valor será exibido na página na seção Status. Se o status for especificado como uma política, ele estará visível na parte superior do bloco.
Gerenciamento de status do programa
Os status de PR podem ser manipulados programaticamente usando a API REST. Assim, é possível implementar verificações adicionais de RP e traduzir seus resultados diretamente no processo de fazer alterações.
O novo valor do status é adicionado pelo método Create . Além do resultado e do contexto, é necessário transmitir o texto que o usuário vê. Opcionalmente, você pode transmitir um URL: nesse caso, o rótulo de status no formulário de relações públicas se tornará um link e o usuário poderá acessar a página com os detalhes do status.
Uma chamada de método resulta na criação de um novo registro de status de PR. Dentro de um contexto, o último valor adicionado do status é considerado ativo. As entradas de status anteriores não são visíveis na interface do usuário, mas podem ser obtidas usando o método List .
Para o status dos status na imagem anterior, a lista real de status para a solicitação pull é a seguinte:
{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }
Depois de examinar a lista de status atuais, você pode atualizar o selecionado por índice na lista. Para fazer isso, use o método Update .
Por fim, os registros de status podem ser excluídos usando o método Delete .
Um histórico de alterações no status de RP pode ser útil para análises adicionais. Portanto, usamos o seguinte método para alterar status:
- Encontre o registro de status mais recente para o mesmo contexto
- Se ela tiver os mesmos valores de resultado, descrições e links que queremos adicionar, não fazemos nada
- Caso contrário, adicione um novo registro de status.
Isso permite que você mantenha um histórico de alterações, sem inflar muito.
function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }
Aplicação prática
Adotamos uma abordagem bastante conservadora para aceitar mudanças no ramo de integração. Tentamos testar a alteração ao máximo na ramificação do recurso ao máximo.
Aqui estão algumas das tarefas que resolvemos com a ajuda dos status de relações públicas, como parte das políticas personalizadas:
- Todos os PRs devem ser decorados no mesmo estilo. Portanto, o primeiro controle que foi criado é o design do cabeçalho PR. Nós comparamos com a expressão regular.
- O ramo PR não deve ficar atrás do ramo onde é derramado (a integração é realizada).
- Se, na estrutura do PR, os arquivos do projeto de banco de dados forem alterados, os arquivos de autoteste também deverão estar presentes.
- Existe uma montagem bem-sucedida da filial para a última alteração.
- Esta montagem foi bombeada com sucesso para o banco de testes e os testes automáticos foram aprovados.
As condições listadas podem ser verificadas manualmente. Nós fizemos isso antes. Mas essa é uma rotina e foi substituída por um processo automatizado. Agora podemos complementar e alterar o conjunto de verificações - ele sempre será integrado ao processo, sempre executado.
Uma enorme vantagem adicional de políticas - elas são transparentes para todos e sempre à vista - na página de relações públicas. Eles não precisam mais ser lembrados.
Além disso, para políticas que falham na verificação, exibimos um link para nossas páginas do Wiki com uma descrição da política e das ações esperadas.
Implementação técnica da aplicação de políticas
Atualmente, a lógica da política é implementada na forma de scripts do PowerShell. Devido aos cmdlets de alto nível e a um bom modelo de dados do objeto, o código do script é muito compacto. E a capacidade de executar o script interativamente em etapas e mexer com variáveis - simplifica bastante o processo de desenvolvimento e depuração.
A propósito, após o lançamento do núcleo do powershell, os scripts podem ser executados em outras plataformas (testadas no MacOS).
Execute os scripts em uma versão especial do VSTS em um agendamento aproximadamente uma vez a cada duas horas. Talvez comecemos a percorrer o sheduler com mais frequência.
Essa abordagem, é claro, fornece uma resposta significativamente mais lenta do que se você implementar o mesmo na forma da Função do Azure e conectá-lo ao VSTS por meio de um gancho da Web. Mas para nós era mais importante implementar verificações e ver como isso funcionaria no processo (MVP). A eficiência da verificação ainda não é importante. Este será o próximo passo.
A implementação de bibliotecas para trabalhar com a API REST do VSTS, usada em verificações, além de um pequeno exemplo que implementa algumas dessas políticas, pode ser encontrada no repositório do GitHub . Espero que alguém ache útil.