◇ OpenCyber Academy
Engenharia · Capítulo 45 · Português

Capítulo 45 — Revisão independente de projeto

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 45 — Revisão independente de projeto

Mapa da aula

Aula 45 publicada. Mapa, exemplo, EX133.

flowchart TD
  N0["45.1 Direitos de revisão"]
  N1["45.2 Lista de verificação"]
  N2["45.3 Divergência"]
  N3["45.2b Preparação do revisor"]
  N4["45.3b SLOs de revisão"]
  N5["45.1b Revisores externos"]
  N6["Nota de prática"]
  N7["45.4b Encerrar comentários de revisão"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX133"]

Desenho lógico

flowchart LR
  N0["45.1 Direitos de revisão"]
  N1["45.2 Lista de verificação"]
  N2["45.3 Divergência"]
  N3["45.2b Preparação do revisor"]
  N4["45.3b SLOs de revisão"]
  N5["45.1b Revisores externos"]
  N6["Nota de prática"]
  N7["45.4b Encerrar comentários de revisão"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX133"]

[45.1 Direitos de revisão]
    |
    v
[45.2 Lista de verificação]
    |
    v
[45.3 Divergência]
    |
    v
[45.2b Preparação do revisor]
    |
    v
[45.3b SLOs de revisão]
    |
    v
[45.1b Revisores externos]
    |
    v
[Nota de prática]
    |
    v
[45.4b Encerrar comentários de revisão]
    |
    v
[Exemplo resolvido] --> [Exercício EX133]

Objetivos de aprendizagem

Você vai (1) conduzir uma revisão que pode rejeitar; (2) usar uma lista de verificação ligada aos requisitos de segurança; (3) registrar opiniões divergentes.

45.1 Direitos de revisão

Os revisores podem bloquear o merge por caminhos de falha aberta, testes ausentes ou pontuações vazias na interface. "LGTM" sem rodar a lista de verificação é inválido. O LGTM sem lista de verificação é como a falha aberta volta sob prazo. O PR do selo de cobertura de Sam recebeu dois bloqueios sob essa regra antes que a interface honesta fosse lançada. Um terceiro bloqueio teria sido aceitável; velocidade não é motivo para pular a lista de verificação. Os autores não podem marcar as caixas da própria lista de verificação; os revisores precisam marcá-las. Um bloqueio precisa nomear o item da lista de verificação que falhou, para que o autor saiba o que corrigir.

45.2 Lista de verificação

Falha fechada; autenticação da política; o esquema proíbe payloads; a cobertura tem denominador; redação de segredos; caminho de rollback documentado. As seis linhas são portões de merge, não sugestões. As regras de falha fechada e de denominador remetem a capítulos anteriores; a redação de segredos e o rollback fecham o ciclo de operações. O bot de revisão de Sam publica a lista de verificação e recusa a aprovação até que cada caixa tenha um link para evidência no PR. Links para testes valem mais que marcações digitadas à mão sem URL. Uma caixa sem link é tratada como desmarcada pelo bot.

45.3 Divergência

Se um revisor discordar, registre a divergência no ADR mesmo que ela seja vencida — incidentes futuros precisam dessa trilha. Uma divergência que foi vencida ainda pertence ao ADR, por causa do incidente que pode vir depois. Os bloqueios do selo de cobertura estão registrados com a visão minoritária de que um selo poderia voltar por meio de uma flag. A terceira revisão de Sam removeu inteiramente o caminho da flag, de modo que a divergência foi resolvida por exclusão, não por decisão contrária.

Caso sintético — Riverstone Transit. Um PR de selo de cobertura foi bloqueado duas vezes sob essa lista de verificação; a terceira revisão lançou a interface honesta (Capítulo 35).

45.4 Erros e limites

Revisões depois do merge são arqueologia, não controle. Comentar depois do merge não consegue parar um binário ruim que já saiu do galpão. A revisão só é um controle enquanto o botão ainda está vermelho. A equipe de Sam trata comentários pós-merge como novos tickets, nunca como revisão de faz de conta da tag lançada. Tags lançadas são imutáveis; correções chegam como novas versões com novas revisões. Hotfixes recebem a mesma lista de verificação com um SLO comprimido, não uma dispensa. O SLO comprimido ainda exige que todos os links da lista de verificação estejam presentes.

45.2b Preparação do revisor

Os revisores rodam os testes críticos localmente, sobre fixtures sintéticos, antes da reunião — não apenas leem o diff. Uma revisão que nunca executou a falha fechada está incompleta, seja qual for o volume de comentários. Testes de falha fechada não executados são teatro com comentários. Rodá-los sobre fixtures sintéticos antes da reunião é o padrão de preparação. O relógio do SLO de revisão de Sam só começa quando o revisor cola no PR a saída do teste local. A saída colada inclui os nomes das linhas de falha fechada, para que uma leitura por cima fique óbvia. O tempo de reunião é para decisões de julgamento, não para a primeira execução dos testes.

45.3b SLOs de revisão

As revisões terminam dentro de um número acordado de dias úteis, ou a mudança expira automaticamente da fila de merge (sem merge automático). Pressão para carimbar sem olhar é um cheiro de problema de segurança. Expirar automaticamente sem merge automático remove a pressão para carimbar. Uma mudança que expira precisa ser atualizada e revisada de novo. A fila de Sam expirou um PR que tocava o escopo no quinto dia; o autor corrigiu as lacunas da lista de verificação antes que ele voltasse. Atualizar um PR expirado reinicia o relógio do SLO do zero. PRs expirados não podem ser forçados a verde com push sem a designação de um novo revisor.

45.1b Revisores externos

Uma vez por período, convide um engenheiro de fora do esquadrão para revisar um PR crítico para a segurança. Olhos novos pegam o desvio normalizado ("sempre pulamos esse teste"). O desvio normalizado, como "sempre pulamos esse teste", precisa de um estranho para ser ouvido. Uma revisão externa por período num PR crítico para a segurança é o mínimo. O revisor externo de Sam pegou um teste de invalidação ausente no cache de política que a revisão interna tinha deixado passar. A lacuna de invalidação virou um caso do Laboratório II na semana seguinte.

Nota de prática

A cultura de revisão proíbe merges na sexta à noite antes de fins de semana de engajamento, a menos que a mudança seja um hotfix de segurança com evidência do Laboratório I anexada. O calendário faz parte do desenho do controle; merges heroicos tardios são um cheiro de problema, não uma medalha.

Faça rodízio dos donos da lista de verificação todo mês, para que a qualidade da revisão não dependa de um único engenheiro consciencioso.

Comentários bloqueantes precisam citar um id de requisito ou o número de um item da lista de verificação.

Os números dos itens da lista de verificação aparecem no modelo de PR como uma lista de preenchimento obrigatório.

Pulos repetidos da lista de verificação pelo mesmo revisor disparam uma conversa de orientação, não uma redesignação silenciosa para sempre.

45.4b Encerrar comentários de revisão

Todo comentário de revisão termina em um de três estados: corrigido, com link para a mudança; recusado, com um motivo que o revisor aceita; ou carregado como risco conhecido, com um dono. O desenho de Sam só é aprovado quando nenhum comentário permanece aberto sem um desses estados. Riscos carregados precisam de donos. A aprovação de Sam para a interface honesta de cobertura esperou até que todo comentário relacionado ao selo estivesse corrigido ou recusado com um motivo que o revisor aceitou. Comentários mantidos como riscos conhecidos são copiados para o registro de riscos com seu dono e uma data de revisão.

Exercícios

Síntese

Revisões que podem dizer não, com uma lista de verificação e uma memória.

Continue estudando — capítulo 45 de 50

← Capítulo 44 (rascunho) · Índice de capítulos do curso · Capítulo 46 (rascunho) →