O que é deploy e como publicar software sem derrubar a produção

Deploy costuma dar errado por um motivo que não é técnico, é de calendário: publicar uma mudança grande na sexta às 18h, sem plano de volta, e descobrir o bug quando metade do time já saiu. O custo vem em forma de fim de semana perdido, clientes sem acesso e, às vezes, dados corrompidos que nenhum rollback desfaz.

Deploy é o ato de levar uma versão do software do ambiente de quem desenvolve para o ambiente onde ele vai rodar de verdade, normalmente chamado de produção. Pode ser subir um site novo, atualizar uma API ou publicar a nova versão de um app. A palavra vem do inglês deploy, posicionar, e no Brasil virou verbo: “deployar”, “fazer o deploy”.

• Deploy é colocar o código em execução num ambiente.
• Release é liberar a funcionalidade para o usuário, o que pode acontecer depois do deploy.
• Rollback é voltar para a versão anterior quando algo dá errado.

Separar deploy de release é o detalhe que muda tudo. Dá para publicar o código com a função nova desligada e ligá-la depois, para poucos usuários, sem novo deploy. O passo a passo abaixo mostra como montar um processo que aguenta erro sem derrubar ninguém.

Deploy começa antes do código sair da sua máquina

1. Versione tudo no Git. Só vai para produção o que está numa branch revisada, nunca um arquivo copiado por FTP do seu computador.
2. Rode os testes automáticos. Se não existem, comece pelos fluxos que dão dinheiro ou dor de cabeça: login, cadastro, pagamento.
3. Gere um artefato único. O mesmo pacote (imagem Docker, arquivo .jar, pasta de build) deve passar por todos os ambientes. Recompilar para cada ambiente abre espaço para “na homologação funcionava”.

Onde costuma dar errado aqui: configurações escritas dentro do código. Senha do banco, endereço da API e chaves devem vir de variáveis de ambiente, como recomenda a metodologia Twelve-Factor App. Assim o mesmo artefato roda em teste e em produção trocando só a configuração.

Ambientes de deploy: desenvolvimento, homologação e produção

A maioria das empresas trabalha com pelo menos três ambientes. Em desenvolvimento, cada dev testa o próprio código. Em homologação (ou staging), a versão candidata roda num ambiente parecido com o real, com dados de teste. Em produção, estão os usuários.

O problema mais frequente é a homologação ficar diferente da produção: outra versão do banco, outra versão do Node, uma variável faltando. Quanto mais parecidos os dois, menos surpresa. Containers ajudaram muito nisso, porque a imagem que roda em um é a mesma que roda no outro.

Estratégias para publicar sem tirar o sistema do ar

Desligar tudo, trocar e religar ainda é o jeito mais simples, e serve para sistemas internos usados em horário comercial. Para o resto, existem estratégias que trocam a versão com o sistema funcionando.

Martin Fowler descreve as duas mais citadas em entrevistas: o deploy blue-green e o canary release. O nome do canário vem dos mineiros, que levavam o pássaro para a mina como alarme de gás. No deploy, os primeiros 5% dos usuários fazem o papel do pássaro, com bem menos drama.

O banco de dados é onde o rollback falha

Voltar o código é fácil. Voltar o banco, nem sempre.

Se a versão nova apagou uma coluna ou converteu dados para outro formato, reinstalar a versão antiga não traz nada de volta. Por isso, times experientes fazem mudanças de banco em etapas compatíveis:

1. Primeiro deploy: adiciona a coluna nova, sem remover a antiga. O código grava nas duas.
2. Copia os dados antigos para a coluna nova.
3. Segundo deploy: o código passa a ler só a coluna nova.
4. Dias depois, um terceiro deploy remove a coluna antiga.

Parece burocrático, mas cada etapa pode ser desfeita sem perda. E faça backup antes de qualquer migração que apague algo, sempre testando se o backup restaura.

Feature flag: o interruptor que separa deploy de release

Uma feature flag é uma condição no código que liga ou desliga uma função sem publicar de novo. Algo tão simples quanto if (config.novoCheckout) { ... }, com o valor vindo de um painel ou de uma variável de ambiente. O código novo vai para produção desligado, o time liga para os funcionários, depois para 10% dos clientes, e só então para todos. Se der problema, desliga em segundos. O cuidado é remover a flag quando a função se estabiliza; código cheio de interruptores velhos vira um labirinto.

Automatizar o deploy com CI/CD

Deploy manual, com alguém digitando comandos no servidor, funciona até o dia em que a pessoa pula um passo. A saída é um pipeline de CI/CD (integração e entrega contínuas): a cada merge na branch principal, uma ferramenta como GitHub Actions ou GitLab CI roda os testes, gera o artefato e publica.

Um pipeline mínimo em GitHub Actions cabe em poucas linhas:

on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
      - run: ./scripts/publicar.sh

Repare que o deploy só roda se o npm test passar. Esse é o ponto: o pipeline vira um porteiro que não deixa código quebrado chegar à produção, sem depender da memória de ninguém. Em projetos maiores, entre o teste e a publicação entra uma etapa de homologação com aprovação manual.

O ganho real não é velocidade. É que o processo fica igual toda vez, registrado e revisável. Quem quiser ver como plataformas tratam versões imutáveis e retorno planejado pode ler sobre versões e aliases no Amazon Connect, um exemplo concreto da mesma ideia aplicada a fluxos de atendimento.

Os primeiros 30 minutos depois de publicar

O deploy não acaba quando o comando termina. Ele acaba quando você confirma que nada piorou.

• A taxa de erros 5xx subiu em relação à hora anterior?
• O tempo de resposta das rotas principais mudou?
• Os logs mostram exceções novas?
• Um fluxo crítico (login, compra) funciona quando você mesmo testa em produção?
• As filas e tarefas agendadas continuam rodando?

Se a resposta a qualquer pergunta for ruim e a causa não ficar clara em poucos minutos, volte primeiro e investigue depois. Investigar com o sistema quebrado e clientes reclamando é o jeito mais estressante e menos eficiente de achar bug.

Para desfazer de verdade, o rollback precisa ter sido ensaiado. Rode uma vez, num dia calmo, o processo de voltar uma versão em homologação e cronometre. Se levar mais de dez minutos ou depender de comandos que ninguém lembra, escreva o roteiro e automatize antes de precisar dele com pressa.

E o deploy de sexta-feira, pode ou não pode?

A piada é antiga, mas a lógica é séria: o problema não é o dia, é a falta de gente para reagir. Times com deploy automatizado, testes e rollback em um clique publicam qualquer dia, porque o risco de cada deploy é pequeno. Se o seu time ainda depende de uma pessoa específica para desfazer um erro, evite publicar quando essa pessoa vai sumir por dois dias.

Esse e outros termos do ciclo de entrega (pipeline, artefato, homologação) estão resumidos no glossário de programação, útil para consultar quando aparecerem numa daily.