Reveja uma entrega da Taiga com evidências

Comece pelo resultado da iniciativa

O serviço fictício de equipamento já permite aos trabalhadores ver os seus próprios pedidos. Comece a revisão pelo resultado e pelo âmbito da iniciativa. Identifique o que tem de ser verdadeiro e o que a alteração tem de preservar.

Nesta entrega, um trabalhador não pode ler o pedido de outro. Os gestores têm de manter o acesso definido. Um teste que apenas abre a página não demonstra nenhuma destas condições.

Ligue os registos

A página Runs regista tentativas, incluindo falhas. Cada execução identifica o plano que executou. Uma página de execução é um registo para inspeção. As decisões que alteram o trabalho pertencem à iniciativa.

Leia as evidências dos passos de testes e formatação. A Taiga torna visíveis as verificações falhadas ou não executadas. Não transforme «não executado» em «aprovado» no resumo da revisão.

Examine os pressupostos e os limites

Procure pressupostos sobre o modelo de acesso, o esquema, o ambiente e os serviços externos. Compare-os com a intenção publicada e com o código real.

No serviço de equipamento, examine onde se verifica o titular do pedido. Teste um pedido autorizado, o pedido de outro trabalhador e um pedido inexistente. Verifique que os logs não revelam conteúdo confidencial dos pedidos.

Reveja também as alterações aos testes. Um resultado bem-sucedido tem valor limitado se a alteração removeu a asserção que detetaria o defeito. Inclua no âmbito da revisão as alterações aos fluxos e à configuração dos testes.

Dê comentários que permitam agir

Identifique o comportamento, o resultado esperado e as evidências necessárias. Por exemplo: «O endpoint verifica o login, mas não a titularidade do pedido. Acrescente a verificação de acesso no servidor e um teste com o pedido de outro trabalhador.»

A Taiga pode responder aos comentários de revisão de pull requests e a verificações falhadas com alterações na mesma branch. Depois das atualizações, examine o novo commit e as suas verificações. As evidências anteriores podem não abranger um artefacto alterado.

Se a execução parou porque o plano estava incompleto ou uma verificação foi enfraquecida, leia a razão indicada. Não retire o estado de rascunho apenas porque o resumo visível das verificações está verde.

Tome a decisão de aceitação correta

Registe os critérios verificados e os que continuam por resolver. Deixe as revisões e verificações obrigatórias do repositório impor o limite de merge. Preserve qualquer decisão separada de lançamento.

A Taiga observa os deployments executados pela sua pipeline. Verifique o ambiente e o artefacto antes de dizer aos utilizadores que a alteração está disponível. Um deployment falhado pode deixar a versão anterior bem-sucedida a servir tráfego.

Conclua com uma verificação ao nível do serviço: o trabalhador consegue usar a funcionalidade, o acesso não autorizado é recusado e o responsável operacional consegue observar falhas. Prossiga para tratar uma interrupção.