Uma política é um conjunto nomeado e versionado de regras de qualidade. As políticas são associadas aos projetos; as regras são as que realmente são executadas.
Para entender os conceitos — bloqueante versus consultivo, onde as regras se posicionam na execução — leia Regras de qualidade primeiro. Esta página aborda o gerenciamento delas.
Gerencie-as em Controle de Qualidade. Sua lista exibe a configuração padrão da organização e todas as configurações de projeto. Selecione uma para ver como o novo trabalho é analisado, quais verificações são feitas em cada alteração, seu nível de QA e onde as verificações são executadas; cada item tem uma chave que aplica a configuração assim que você a ativa. A confirmação permite desfazer a alteração, e as configurações de uma linha modificam o funcionamento dessa verificação.
- Padrão da organização3 projetos seguem essa configuração2 de 5
- Loja virtualConfiguração personalizada4 de 5
- Site de documentaçãoSegue o padrão2 de 5
- API de faturamentoSegue o padrão2 de 5
- Aplicativo móvelSegue o padrão2 de 5
- Anti-slopRetorna uma alteração quando ela enfraquece os testes, oculta erros, envia placeholders ou gera dívida técnica.
- Testes unitáriosLocaliza e executa os testes unitários do repositório em cada alteração.
- Testes de navegador2 de 3diferente do padrãoExecuta suas jornadas de navegador contra a alteração.
- Traduçõesdiferente do padrãoVerifica se as strings alteradas foram traduzidas e se seus placeholders e formas plurais correspondem.
- Verificações de repositórioExecuta seus próprios comandos, como formatação, tamanho de arquivos, migrações, testes de integração e varreduras de segurança.
- QA completoCompletoO QA coleta evidências e capturas de tela em tempo real conforme a Especificação. Quando desativado, o trabalho passa pelo QA Padrão.
Controle de Qualidade: as políticas em vigor e a última execução de gate. Dados ilustrativos.
Criar uma política
Uma política é um conjunto de verificações e, para cada uma, indica se a falha deve bloquear ou apenas gerar aviso.
A maioria das organizações precisa de duas ou três políticas, não uma por projeto:
- uma estrita política para serviços de produção
- uma padrão política para tudo o que é comum
- ocasionalmente uma leve política para ferramentas internas e protótipos
Mais do que isso e ninguém consegue lembrar qual projeto usa qual política.
A configuração padrão da organização e a configuração própria de cada projeto
Um projeto segue a configuração padrão da organização até que você altere alguma chave. Essa alteração cria uma configuração própria, copiada do padrão, e mudanças futuras no padrão não afetarão esse projeto. Uma linha pode copiar uma verificação de volta do padrão, e o menu do projeto pode redefinir todo o projeto para a configuração padrão da organização. A política completa por trás das chaves, com expectativas, dependências entre verificações, orçamentos de correção e versões, é aberta pelo mesmo menu do editor avançado. Para um projeto que segue o padrão, o editor começa a partir de uma cópia dele, e nada muda para o projeto até que essa cópia seja publicada.
Defina o padrão como sua padrão verificações, aquelas que a maioria dos projetos deve executar, não a mais estrita — esta deve ser selecionada deliberadamente, projeto por projeto.
Pull requests
Os Pull requests abertos por pessoas e outras ferramentas chegam ao Coroid através do aplicativo Coroid GitHub. O grupo Pull requests em Controle de Qualidade decide o que acontece com eles, tanto para a configuração padrão quanto para cada projeto:
- Coroid Controle de Qualidade executa as verificações acima em todo pull request e reporta o resultado como a verificação de Coroid Controle de Qualidade em GitHub.
- Coroid Revisão faz com que o revisor do Coroid leia cada pull request e comente sobre as linhas questionáveis. Ele analisa os Pull requests que a Coroid Controle de Qualidade verifica.
Configurações da Coroid Revisão:
- O que é postado. O modo consultivo, padrão, comenta e nunca falha na verificação, com uma exceção: um problema crítico ou grave de segurança faz com que a verificação falhe quando a Segurança exigir revisão de segurança (ver Varredura de código e revisão de segurança). A opção de solicitações bloqueantes altera o comportamento quando um problema é encontrado, fazendo com que a verificação falhe. Torne a Coroid Revisão uma verificação obrigatória em GitHub se uma revisão bloqueante deve impedir a fusão.
- Quais Pull requests. Por padrão, espera-se até que um rascunho seja marcado como pronto e ignora os Pull requests abertos pelo próprio Coroid, pois o revisor do Coroid já os analisou dentro da tarefa. Também pode ignorar Pull requests de bots.
- Quando ocorre a revisão. Espera-se um período de silêncio após o último envio; cinco minutos é o padrão. Um envio mais recente substitui uma revisão que ainda não começou. A opção 'Reexecutar em GitHub' inicia uma revisão imediatamente.
- Profundidade da revisão. Quanto o revisor pode ler e escrever em uma revisão.
Ele segue as regras de revisão do Coroid e as regras do seu repositório em
review-rules Uma pasta. Um projeto que segue a configuração padrão da organização recebe as configurações do padrão, assim como qualquer outro controle.
Quando algo falha
Três chaves sob a configuração padrão da organização transformam falhas em tarefas de acompanhamento para todos os projetos. Cada chave aciona uma automação listada na Factory em Automações; o agente lê o código e abre uma tarefa, que passa pelos mesmos processos de especificação, compilação, verificação e revisão que qualquer outra tarefa.
| Chave | Quando | O que o agente faz |
|---|---|---|
| Quando uma tarefa falha, abrir uma tarefa de correção | Uma tarefa falha | Descobre o motivo e, se a causa estiver no código, abre uma tarefa para corrigi-la |
| Quando uma implantação falha, investigar | Uma implantação falha | Lê o que mudou nessa versão e abre uma tarefa indicando o que deu errado e o que alterar |
| Quando uma versão é revertida, planejar a correção | Uma versão é revertida | Abre uma tarefa que registra o que foi revertido, o motivo e o que precisa ser alterado antes de ser lançado novamente. |
Desativar um automação a pausa; reativá-la retoma seu funcionamento. Toda alteração permite desfazer. A página da automação na Factory indica que ela é gerenciada pelo Controle de Qualidade. Pausá-la ali equivale a desativá-la; alterar suas instruções a torna personalizada após confirmação, e o interruptor não a ligará ou desligará mais.
Esses eram modelos em Novo trabalho. Uma automação criada a partir de um deles continua em execução. Se você nunca a modificou, ativar o interruptor correspondente a assumirá o controle em vez de iniciar uma segunda automação. Se a modificou, ela permanecerá sua: o nome da linha do interruptor a identifica, e você pode adotá-la para que o interruptor a gerencie.
Lançamento seguro
O problema dos gates não é serem fracos demais, mas sim que um gate de bloqueio bem-intencionado paralisa todas as tarefas da organização de uma só vez.
Uma sequência segura:
- Adicione o gate como orientativo.
- Deixe-o rodar em tarefas reais por uma ou duas semanas. Veja o que ele sinaliza.
- Ajuste-o com base no que aprendeu.
- Promova para bloqueante em um projeto.
- Implante em escala maior assim que funcionar corretamente.
- 1Adicionar a portaAviso
- 2Monitorá-la por uma ou duas semanasAviso
- 3Ajustá-la conforme o que ela sinalizouAviso
- 4Bloquear em um projetoBloqueanteUm projeto
- 5Implantar de forma mais amplaBloqueanteMais projetos
Controle de versão e reversão
As políticas têm versão controlada. Cada alteração no interruptor publica uma nova versão, e sua confirmação permite reverter para a versão anterior; versões antigas podem ser restauradas pelo histórico de versões do editor avançado.
A reversão é o motivo pelo qual você pode ser decisivo ao publicar mudanças. Se um novo gate estiver mal ajustado, reverter é uma ação simples, em vez de um processo complexo de recuperação.
Sobrescritas
Um gate de bloqueio pode ser sobrescrito por alguém com autoridade. A sobrescrita é registrada — quem, quando e contra o quê.
Monitore sua taxa de sobrescritas. Um gate que é sobrescrito na maioria das vezes em que é acionado não está impondo nenhuma regra; apenas gera atrito e papelada. Corrija o gate ou descarte-o.