Princípio dos quatro olhos no deploy: impor aprovações por meio da ferramenta

Objetivo

Interceptar antes da produção os erros e abusos que uma única pessoa, ou um único agente com as permissões dela, poderia introduzir, sem apoiar o processo em confiança e memória.

Pré-requisitos

Um sistema de controle de versão e de CI que aceite regras por branch e por ambiente: o GitHub oferece branches protegidos e ambientes com «Required reviewers»; o GitLab oferece aprovações para deploys («Deployment approvals»). Pelo menos duas pessoas com permissão de revisão. Um deploy que ocorra exclusivamente a partir da CI e apenas a partir do branch principal.

Passos

1. Proteger o branch principal: proibir pushes diretos, exigir pelo menos uma aprovação, invalidar aprovações quando houver novos commits (GitHub: «Dismiss stale pull request approvals when new commits are pushed») e registrar as verificações de status da CI como obrigatórias.
2. Excluir a aprovação pelo próprio autor: quem cria a proposta de alteração não a aprova. Para caminhos sensíveis (scripts de deploy, infraestrutura, permissões), exigir, por meio de um arquivo de code owners, um segundo grupo nomeado.
3. Criar a produção como um ambiente próprio com aprovação obrigatória, de modo que o job de deploy espere até que uma pessoa autorizada o libere. Essa aprovação é separada da revisão de código, porque o momento e o contexto da entrega são uma decisão à parte.
4. Fechar os desvios: administradores estão sujeitos às mesmas regras («Do not allow bypassing the above settings»); as credenciais de deploy ficam apenas na CI, não nas máquinas de trabalho.
5. Definir uma via de emergência que desloque o princípio em vez de quebrá-lo: um deploy de emergência exige uma segunda pessoa ao telefone, é marcado como tal e é revisado posteriormente, o mais tardar no dia útil seguinte.
6. Verificar regularmente: quem tem permissão de revisão, quais regras foram contornadas segundo o log de auditoria e quais aprovações ocorreram tão rápido que ninguém pode tê-las lido.

Resultado esperado

Toda alteração em produção pode ser atribuída a duas pessoas: a autora e quem aprovou. Uma estação de trabalho comprometida ou um agente desgovernado não consegue, sozinho, entregar uma versão.

Limites e base de verificação

O princípio verifica que alguém olhou, não com que profundidade; revisões feitas apenas para carimbar o tornam inútil, e contra isso só ajudam uma cultura de revisão e amostragens, não ferramentas. Duas pessoas que atuem em conluio podem anulá-lo; contra isso ajudam registros e separação de papéis. As configurações citadas seguem a documentação do GitHub e do GitLab referenciada; nada se afirma sobre o efeito nas taxas de erro.