Uma política é um conjunto nomeado e versionado de portas de qualidade. As políticas são o que você associa aos projetos; as portas são o que realmente são executadas.
Para entender os conceitos — bloqueante versus consultivo, onde as portas se posicionam na execução — leia Portas 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 cada projeto. Selecione uma para ver como o novo trabalho é filtrado, o que é verificado em cada alteração, seu nível de QA e onde as verificações são executadas; cada item possui 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.
Criando uma política
Uma política é um conjunto de verificações mais, para cada uma, se a falha deve bloquear ou apenas orientar.
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 é normal
- ocasionalmente uma leve política para ferramentas internas e protótipos
Mais do que isso e ninguém consegue lembrar qual projeto tem qual política.
A configuração padrão da organização e a configuração própria do projeto
Um projeto segue a configuração padrão da organização até que você altere alguma de suas chaves. Essa alteração cria uma configuração própria para o projeto, copiada da padrão, e mudanças posteriores na padrão não afetarão mais essa configuração. Uma linha pode copiar uma verificação de volta da 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 reparo e versões, é aberta pelo mesmo menu do editor avançado. Para um projeto que segue a padrão, o editor começa a partir de uma cópia dela, e nada muda para o projeto até que você publique essa cópia.
Defina a padrão como sua padrão verificações, aquelas que a maioria dos projetos deve executar, não sua política mais estrita — a política estrita deve ser escolhida 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 da organização quanto para cada projeto:
- Coroid Controle de Qualidade executa as verificações acima em cada pull request e relata 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 que questiona. Ele analisa os Pull requests que a Coroid Controle de Qualidade verifica.
Configurações da Coroid Revisão:
- O que ele publica. O modo consultivo, padrão, comenta e nunca falha sua verificação. A opção de bloqueio altera o comportamento quando um problema é encontrado, fazendo com que a verificação falhe. Torne a Coroid Revisão uma verificação obrigatória no GitHub se uma revisão bloqueante deve impedir o merge.
- Quais Pull requests. Por padrão, ele aguarda até que um rascunho seja marcado como pronto, e ignora os Pull requests abertos pelo Coroid, pois o Revisor do Coroid já os revisou dentro da tarefa. Ele também pode ignorar Pull requests de bots.
- Quando ele revisa. Ele aguarda um período de silêncio após o último push, cinco minutos por padrão. Um novo push substitui uma revisão que ainda não começou. A opção de reexecutar no GitHub inicia uma revisão imediatamente.
- Profundidade da revisão. Quanto o Revisor pode ler e escrever em uma única revisão.
Ele segue as regras de revisão do Coroid e as regras do seu repositório em
review-rules pasta. Um projeto que segue a configuração padrão da organização recebe as
configurações da 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 sob Automações; o agente lê o código e abre uma tarefa, e a tarefa passa pelo mesmo processo de especificação, compilação, verificação e revisão que qualquer outra.
| 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 que indica o que deu errado e o que deve ser alterado |
| 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 deve mudar antes que seja lançado novamente |
Desligar um deles pausa sua automação; ligá-lo novamente a retoma. Toda alteração permite desfazer. A página da automação na Factory indica que ela é gerenciada pelo Controle de Qualidade. Pausá-la ali é o mesmo que desligá-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 no Novo trabalho. Uma automação criada a partir de um deles continua em execução. Se você nunca a modificou, ligar 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.
Implantação segura
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. Leia o que ele sinaliza.
- Ajuste-o com base no que aprendeu.
- Promova para bloqueante em um projeto.
- Implante em escala maior assim que funcionar conforme esperado.
- 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 interruptor publica uma nova versão, e sua confirmação permite desfazer voltando à 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. Se um novo gate estiver mal ajustado, reverter é uma única ação, em vez de um processo complexo de recuperação.
Sobrescritas
Um gate bloqueante 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 nada; está gerando atrito e papelada. Corrija o gate ou descarte-o.