Revise uma entrega da Taiga com evidências

Comece pelo resultado da iniciativa

O serviço fictício de equipamentos agora permite que funcionários vejam as próprias solicitações. Comece a revisão pelo resultado e pelo escopo da iniciativa. Identifique o que precisa ser verdadeiro e o que a alteração deve preservar.

Nesta entrega, um funcionário não deve ler a solicitação de outro. Gerentes precisam manter seu acesso definido. Um teste que apenas abre a página não comprova nenhuma das condições.

Conecte os registros

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

Leia as evidências das etapas de testes e formatação. A Taiga deixa visíveis verificações que falharam ou não foram executadas. Não transforme “não executado” em “aprovado” no resumo da revisão.

Inspecione premissas e limites

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

Para o serviço de equipamentos, inspecione onde se verifica quem é dono da solicitação. Teste uma requisição autorizada, uma solicitação de outro funcionário e uma solicitação inexistente. Verifique se os logs não revelam conteúdo confidencial das solicitações.

Revise também as alterações de testes. Um resultado aprovado tem valor limitado se a alteração removeu a asserção que detectaria o defeito. Trate alterações de workflow e de configuração de testes como parte do escopo da revisão.

Dê feedback que oriente a ação

Identifique comportamento, resultado esperado e evidências necessárias. Por exemplo: “O endpoint verifica o login, mas não quem é dono da solicitação. Acrescente a verificação de acesso no servidor e um teste com a solicitação de outro funcionário.”

A Taiga pode responder a comentários de revisão de pull requests e verificações com falha com alterações na mesma branch. Após as atualizações, inspecione o novo commit e suas verificações. Evidências anteriores podem não cobrir um artefato alterado.

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

Tome a decisão correta de aceitação

Registre quais critérios estão verificados e quais continuam não resolvidos. Deixe as revisões e verificações obrigatórias do repositório impor o limite de merge. Preserve qualquer decisão separada de release.

A Taiga observa os deployments executados pelo seu pipeline. Verifique ambiente e artefato antes de dizer aos usuários que a alteração está disponível. Um deployment com falha pode deixar a versão anterior bem-sucedida atendendo tráfego.

Conclua a avaliação do resultado com uma verificação no nível do serviço: o funcionário consegue usar a funcionalidade, o acesso não autorizado é negado e o responsável operacional consegue observar falhas. Continue com tratamento de uma interrupção.