O time levou meses para aprontar o produto, mas finalmente está tudo pronto. Você faz aquela pergunta final: “Vamos colocar em produção?”. Você achava até que a pergunta era retórica, afinal, estava tudo certo. Entretanto, a resposta é: “não! Falta …”
Você fica com aquela cara de técnico que vê seu atacante avançar para o gol sem goleiro e perde o gol debaixo da trave. Começa uma misselânea de desculpas e um monte de falta: isso, aquilo…
Então, um tanto incrédulo, você pergunta: “Dá para colocar no ar sem isso?” A resposta é sempre um “dá, mas…”.
Se você já passou por isso, seu time provavelmente não tem um problema técnico a resolver. Normalmente, é falta de confiança e medo de entregar o produto nas mãos do cliente. Afinal, depois que o produto sai do desenvolvimento e vai para produção, todos se tornam responsáveis, pais e mães dele. Aqui vão seis motivos que fazem com que o time tenha medo de disponibilizar em produção:
Motivo Medo 1: Risco de quebrar algo em ambiente real
Em produção, qualquer bug afeta usuários reais, causando perdas financeiras, danos à reputação da empresa ou frustração dos clientes. Diferentemente dos ambientes de teste, a produção tem tráfego real, dados reais e integrações imprevisíveis. Afinal, como disse Didi: “treino é treino, jogo é jogo”.
Motivo Medo 2: Dificuldade de rollback
Muitos sistemas não têm mecanismos simples e rápidos para reverter uma mudança negativa. Uma entrega problemática pode exigir horas ou dias para ser corrigida, gerando um tempo de queda (downtime) prolongado.
Motivo Medo 3: Processos manuais e propensos a erro
Quando a entrega depende de etapas manuais (SSH, scripts frágeis, aprovações lentas), o risco de erros humanos aumenta significativamente.
Motivo Medo 4: Testes insuficientes ou pouco confiáveis
Baixa cobertura de testes, testes que não refletem a realidade de produção ou a falta de testes de carga/integração deixa a equipe sem confiança de que o código está realmente pronto.
Motivo Medo 5: Cultura organizacional
Ambientes com “blame culture” (culpar alguém por falhas) tornam a entrega assustadora. Incidentes traumáticos passados reforçam o medo coletivo. Um tanto parecido com o Experimento dos 5 Macacos.
Motivo Medo 6: Complexidade do sistema
Microsserviços, dependências externas, bancos de dados com estado e configurações específicas de produção aumentam a percepção de risco. Quanto mais complexo, mais medo o time terá, pois não conseguirá garantir que tudo funcionará na produção.
Como combater esse medo?
A solução passa por uma combinação de práticas técnicas, processos e cultura, muito alinhada com DevOps. Aqui estão as estratégias mais eficazes:
Automatize tudo com Continuous Integration/Continuous Delivery (CI/CD)
Implemente pipelines automatizadas (GitHub Actions, GitLab CI, Jenkins, ArgoCD etc.) que executam testes e, automaticamente, entregam (deploy) a cada commit/merge ou quando alguém define que pode ir para produção. Isso reduz erros humanos e torna o deploy mais frequente e rotineiro
O ideal é realizar várias entregas por dia, pois você estará fatiando uma grande entrega em pequenininhas. Se não conseguir fazer isso, tente uma vez ao dia e, se nem isso for possível, uma vez por semana. Quanto maior o período, maior o medo.
Adote estratégias de deploy de baixo risco
Canary releases (Entrega Canário)
Libera a nova versão primeiro para uma pequena porcentagem de usuários. Por exemplo, apenas pessoas de Recife/PE. Ou então para clientes pessoas físicas de Sergipe.
O termo “canary” origina-se de uma prática histórica nas minas de carvão, em que os mineradores levavam canários em gaiolas, pois esses pássaros são extremamente sensíveis a gases tóxicos inodoros e incolores, como o monóxido de carbono e o metano. Quando os níveis de gás aumentavam, o canário morria primeiro (parava de cantar ou caía do poleiro), servindo como um alerta precoce que permitia aos mineradores evacuarem imediatamente e salvarem suas vidas.
Blue-green deployments
Mantém duas instâncias de produção e troca o tráfego entre elas instantaneamente. Você coloca a nova versão em produção (green) e o servidor vai trocando as pessoas da versão antiga (blue) para a nova. Caso dê algum problema, você pode retornar rapidamente todos para a antiga.
Feature flags/toggles
Meu favorito, embora dê algum trabalho. O time disponibiliza as funcionalidades novas em produção, porém, permite que elas possam ser desligadas se necessário e que as funcionalidades anteriores sejam religadas.
Invista pesado em testes automatizados
Eu não tenho como dizer o quanto isso aqui é importante. Se seu time não faz, está com um desenvolvimento atrasado há mais de três décadas. Já deveria ter começado há muito tempo.
Comece do mais simples e vá para os mais complexos:
- Unitários
- Integração e Banco de Dados
- Interface
- Segurança
- Carga
- Caos (Engenharia do Caos)
Melhore observabilidade e monitoramento
Ferramentas como Prometheus e Datadog permitem detectar problemas rapidamente. Elas dão alertas no momento em que o problema ocorre, logs estruturados e tracing. Isso aumenta muito a confiança para reverter ou corrigir esses problemas rapidamente.
Facilite rollbacks
A containerização (Docker + Kubernetes) torna rollbacks quase instantâneos. Se der problema, apenas suba novamente o container anterior.
Construa uma cultura de segurança psicológica
Apague, de uma vez por todas, a cultura de caça às bruxas na sua empresa. Se perdemos tempo procurando um culpado, teremos perdido tempo e oportunidade de aprendizado. Por exemplo, fizemos uma entrega e ela gerou um problema. Em vez de ficar tentando ver se o culpado foi João ou Maria, troque para: o que faremos para que esse problema nunca mais ocorra independentemente da pessoa que esteja trabalhando no produto.
Comece pequeno e evolua
Não tente mudar tudo de uma vez. Comece automatizando um serviço menos crítico, implemente feature flags em novas funcionalidades e vá expandindo. O sucesso inicial cria momentum e confiança.
Quando os deploys se tornam frequentes, pequenos e reversíveis, o medo desaparece naturalmente, pois vira apenas mais uma etapa rotineira do dia a dia. Logo, se sua equipe está enfrentando isso agora, recomendo começar pela avaliação do pipeline atual e escolher uma ou duas melhorias prioritárias. Geralmente, CI/CD + testes automatizados dão o maior retorno mais rápido.
