Pular para o conteúdo

Exija aprovação para mudanças em produção

Mudanças em produção merecem um segundo par de olhos. Isso já vem embutido: Developers não podem escrever diretamente em ambientes de classe de produção, mas também não abrem tickets — eles propõem a mudança ali mesmo, e qualquer segundo colega a aplica.

Não há nada para ligar. Se o seu ambiente é de classe de produção e o seu time tem Developers, é assim que já funciona.

Como Developer, faça a mudança que você quer em um ambiente de produção — um toggle, uma edição de regras — e o painel oferece propor em vez de aplicar. Acrescente a sua justificativa se precisar de uma, e envie. A flag em si ainda não se move.

Qualquer colega que seja Developer ou acima — exceto a pessoa que propôs — revisa a proposta pendente e a aprova, o que a aplica na hora. Propostas pendentes aparecem na caixa de aprovações do painel, então fique de olho no sino; a caixa é a notificação (não há lembrete por e-mail).

Duas regras valem, sempre:

  • Ninguém aprova a própria proposta. Isso é aplicado por pessoa, não por papel — um Admin também não pode se autoaprovar.
  • O registro de auditoria nomeia as duas pessoas em toda proposta aplicada: quem propôs, quem aprovou, e o que mudou.

É revisão por pares, não revisão hierárquica: dois Developers juntos podem mudar produção, e esse é o ponto — nenhuma pessoa sozinha a muda, abaixo de Admin. Vale saber ao alinhar expectativas:

  • Admins e Owners ainda escrevem em produção diretamente. O caminho da proposta é a rota de entrada dos Developers, não um portão para todo mundo. Hoje não existe configuração que force aprovações também para Admins.
  • A aprovação é de uma pessoa, não de um quórum.

Se uma proposta estiver errada, o revisor simplesmente não a aprova — e quem propôs pode fazer uma nova quando a forma estiver certa.