deploy em um sistema financeiro legado, sem quebrar nada

o pedido

Adicionar sete funcionalidades a um sistema de carteiras digitais em operação: perfis com permissões diferenciadas, painel de controle, busca sobre o cadastro de contas, edição auditada de titulares, relatórios ampliados, comprovantes com dados do titular e devolução total de fundos. O sistema estava em produção, movia dinheiro real e estava sujeito a auditoria de um órgão público.

o que tornava isso difícil

O sistema veio de outro fornecedor.

• Não existia ambiente de testes: o que todos chamavam de "staging" era produção.
• O código chegou sem histórico: sete componentes entregues como pastas de arquivos.
• A aplicação web era construída a partir de um repositório ao qual o cliente não tinha acesso.
• A documentação não batia com a realidade: o manual declarava uma versão do framework e em produção rodava outra, duas versões maiores mais nova, porque as dependências não estavam fixadas.
• A plataforma de contêineres está descontinuada: um serviço apagado não pode ser recriado.

Margem zero para erro.

como resolvi

Reconstruí o sistema completo na minha máquina com o volume real: as imagens exatas de produção contra uma base com 1.500 contas, o mesmo montante total e 131.000 transações. Não uma maquete: uma réplica.

Ensaiei o deploy inteiro quatro vezes, verificando em cada ensaio três coisas: que a versão anterior funcionasse igual à de produção, que as atualizações de banco de dados fossem aplicadas sem mover dinheiro, e que a versão anterior continuasse funcionando contra a base já atualizada. Esse terceiro ponto torna toda a operação segura: se algo falha, volta-se atrás em segundos sem tocar na base.

O ensaio encontrou um problema real antes da produção: a versão anterior não teria conseguido criar usuários contra a base já migrada. Escrevi uma migração específica e ensaiei de novo até fechar a questão.

Defini uma medida de verdade antes de começar: o total de dinheiro nas contas, a quantidade de contas, o saldo retido, o número de transações e o timestamp da última. Cinco medidas, tomadas minutos antes e repetidas ao terminar.

Deixei três caminhos de reversão verificados antes de tocar em qualquer coisa: cópias das bases, as versões anteriores de cada serviço marcadas do lado do servidor, e o artefato web baixado. Nenhum dependia de o meu computador continuar ligado.

o resultado

Também verifiquei que o que foi publicado era exatamente o que foi testado: os arquivos que o site serve têm a mesma impressão digital criptográfica dos que gerei localmente. Não uma versão equivalente, o mesmo artefato.

o que o cliente levou

• Seus repositórios de código, com histórico e análise automática de credenciais vazadas, e um caminho claro para que fiquem sob uma conta própria.
• Um relatório de 31 achados ordenados por gravidade, com impacto e recomendação em cada um.
• Um procedimento de deploy documentado e testado, para que da próxima vez não dependa de mim.
• Seis correções de segurança que estavam em produção, entre elas uma página sem verificação de permissões e uma exportação que permitia baixar os dados pessoais de todo o cadastro em uma única operação.

como eu trabalho

Ensaio antes de tocar em produção: reproduzo o sistema com dados no volume real e executo o procedimento completo, incluindo a reversão, até sair igual várias vezes seguidas.

Verifico o artefato, não o processo: um comando ter saído bem não prova que o resultado está correto; reviso o que ficou dentro da imagem, da base e do servidor.

Defino a medida de verdade antes de começar: em um sistema com dinheiro, essa medida é o dinheiro. Se não posso provar que ele não se moveu, não posso dizer que o deploy saiu bem.